Расширенный анализ требований прототипирование Цели прототипирования

Расширенный анализ требований: прототипирование

Цели прототипирования • прояснить неясные требования к системе; • выбрать одно из различных концептуальных решений; • проанализировать осуществимость

Классификация прототипов Горизонтальный прототип Вертикальный прототип Одноразовый прототип Эволюционный прототип (поведенческий) (исследовательский) Бумажный прототип (структурный) Раскадровка Иллюстративные сценарии прецедентов

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

Вертикальный прототип • Не ограничивается только пользовательским интерфейсом • реализует вертикальный "срез" системы, затрагивая все уровни ее реализации. • Основная цель - анализ применимости, проверка архитектурных концепций

Одноразовый прототип • Для быстрого макетирования аспектов ИС • При разработке не уделяется внимание повторного использования кода, качества, быстродействия, технологичности и т. п.

Эволюционный прототип • первое приближение системы, призванное стать впоследствии самой системой • Код эволюционного прототипа должен последовательно, в течении одной или более итераций, перерасти в код целевого приложения

Горизонтальные Одноразовые Прояснение и уточнение примеров использования и функциональных требований Выявление пропущенных требований Исследование возможных вариантов интерфейса пользователя Вертикальные Демонстрация технической осуществимости Эволюционные Реализация базовых вариантов использования Реализация дополнительных вариантов использования по приоритетам Реализация и доработка web -сайтов Адаптация системы к быстро меняющимся требованиям бизнеса Реализация и наращивание ключевой клиент-серверной функциональности и уровней коммуникации Реализация и оптимизация основных алгоритмов Тестирование и настройка производительности

Бумажный прототип Достоинства: • Заказчик не станет акцентировать внимание на цветовом решении, форме кнопок и т. п. , отвлекаясь от анализа функциональности. • Заказчик никогда не скажет, глядя на бумажный интерфейс: "Да вы, я вижу, уже создали систему на 85%! Давайте закончим ее в течении недели"

• Раскадровка с использованием Microsoft Visio и/или Microsoft Power. Point • Иллюстрированные сценарии прецедентов (ИСП) содержат дополнительные сведения, помогающие Разработчику лучше понять специфику проблемной области и, тем самым, лучше отразить ее в интерфейсе пользователя • Основная идея ИСП - "разбавить" текст описания сценария варианта использования аспектами применимости

• Аспект применимости - информация, позволяющая расширить описание прецедента описаниями, конкретизирующими те или иные его особенности и, в конечном итоге, повысить степень комфортности пользователя • Аспекты применимости: üориентиры, üсредние значения атрибутов и объемы объектов, üсредняя интенсивность использования

Ориентиры - описание опциональных функциональных возможностей системы. Пример. В процессе выполнения варианта использования расчета З/П преподавателя система автоматически рассчитывает сумму, исходя из тарифа и количества отработанных часов. [Сотрудник ЦЭУП должен видеть значения тарифов и количество часов, кроме итогового значения ЗП]

Средние значения атрибутов и объемы объектов позволяет оптимальнее построить пользовательский интерфейс и оценить на ранних стадиях проекта "узкие места" в обработке данных, которые могут повлиять на производительность системы Пример. В процессе работы варианта использования по вводу данных о студенте сотрудник ЦЭУП выбирает из списка направлений подготовки соответствующее название {до 60} …

Средняя интенсивность использования • позволяет выделить сценарии "массового" использования, в которых все должно быть идеально (быстродействие, удобство использования, минимум действий на выполнение операций) • позволяет, структурировать подачу информации, убрать из "главных" интерфейсов редко используемые опции и т. п.

Пример В процессе выполнения варианта использования «ввод данных о студенте» сотрудник ЦЭУП выбирает факультет из списка факультетов (в 100% случаев), направление обучения (в 20% случаев), …

Этап проектирования

Этап проектирования Стадии и этапы создания (ГОСТ 34. 601 -90) 4. Эскизный проект. 4. 1. Разработка предварительных проектных решений по системе и её частям. 4. 2. Разработка документации на АС и её части. 5. Технический проект. 5. 1. Разработка проектных решений по системе и её частям. 5. 2. Разработка документации на АС и её части. 5. 3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку. 5. 4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

4. 1. Разработка предварительных проектных решений по системе и её частям функции АС; функции подсистем, их цели и эффекты; состав комплексов задач и отдельных задач; концепция информационной базы, её укрупнённая структура; • функции системы управления базой данных; • состав вычислительной системы; • функции и параметры основных программных средств • •

5. 1. Разработка проектных решений по системе и её частям разработка общих решений: • по системе и её частям, • функционально-алгоритмической структуре системы, • по функциям персонала и организационной структуре, • по структуре технических средств, • по алгоритмам решения задач и применяемым языкам, • по организации и ведению информационной базы, системе классификации и кодирования информации, • по программному обеспечению

Этапы разработки ПО Проектирование: формирование моделей данных, процессов. Отображение функций на этапе анализа в модули ИС, разработка архитектуры ИС. Конечными продуктами этапа проектирования являются: • схема базы данных; • набор спецификаций модулей системы (они строятся на базе моделей функций); • Проект архитектуры ИС

Разработка архитектуры: • Выбор типа архитектуры • Выбор типа БД (централизрванная/ распределенная/ однородная) • Использование параллельных серверов БД Результат проектирования: технический проект

Разработка архитектуры • Выбор платформы и ОС • Определение характеристик архитектуры: ü "файл-сервер" или "клиент-сервер «? ü 3 -уровневая архитектура? ü база данных централизованная или распределенная? ü база данных однородная по производителям? ü используются параллельные серверы баз данных?

Области проектирования: • проектирование объектов данных; • проектирование программ, экранных форм, отчетов • учет конкретной среды или технологии

Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС.

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

Технология проектирования ИС • пошаговая процедура, определяющая последовательность технологических операций • критерии и правила, используемые для оценки результатов выполнения технологических операций проектирования • нотации, используемые для описания проектируемой системы

Пример технологической операции проектирования

Требования к технологии проектирования, разработки и сопровождения ИС • Поддержка полного ЖЦ • Обеспечение гарантированного достижения целей создания ИС • Обеспечение возможностей разработки проектов в виде подсистем • Обеспечение ведение разработки несколькими небольшими группами разработчиков • Обеспечение создания ИС в минимальные сроки • Предусматривать возможность управления конфигурацией • Независимость проектных решений от средств реализации • Поддержка CASE-средствами разработки

Стандарты (правила, соглашения) при создании ИС: • стандарт проектирования; • стандарт оформления проектной документации; • стандарт пользовательского интерфейса

Стандарт проектирования • набор необходимых моделей • правила фиксации проектных решений на диаграммах • требования к конфигурации рабочих мест разработчиков • механизм обеспечения совместной работы над проектом

Стандарт оформления проектной документации • комплектность, состав и структуру документации на каждой стадии проектирования; • требования к ее оформлению, • правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии; • требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации; • требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя • правила оформления экранов; • правила использования клавиатуры и мыши; • правила оформления текстов помощи; • перечень стандартных сообщений; • правила обработки реакции пользователя

Методологии • На основе бизнес-процессов предприятия: üСтратегическая система моделей üУкрупненная система моделей üДетальная система моделей • Проектирование от данных

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

Укрупненная система моделей • Задачи: отображение основных бизнеспроцессов, описанных на стратегическом уровне, на реальную иерархическифункциональную структуру организации, выделение основных функций подразделения, уточнение состава и характеристик бизнес-процессов • Обследуются подрпзделения

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

Подходы проектирования • Структурная • Объектно-ориентированная • Комбинированная

Структурная методология Сущность: декомпозиция на автоматизируемые функции Принципы: • "разделяй и властвуй" • иерархического упорядочивания • абстрагирования • формализации • непротиворечивости • структурирования данных

CASE-средства • SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы; • DFD (Data Flow Diagrams) диаграммы потоков данных; • ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь» .

ОО методология Гради Буч: "ООП - это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования".

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

• ОО методология : логическая структура отражается в виде классов и объектов • Структурная методология: логическая структура представляется алгоритмами

Составные части ООМ • • Основные: абстрагирование, инкапсуляция, модульность, Иерархия.

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

Инкапсуляция • это процесс отделения друг от друга элементов объекта, определяющих его устройство и поведение • абстрагирование направлено на наблюдаемое поведение объекта, а инкапсуляция занимается внутренним устройством

Модульность Модули – физическая реализация логической структуры системы 1. 2. 3. 4. Правила составления модулей Интерфейсная часть должна быть «узкой» Особенности системы, подверженные изменениям, следует скрывать в отдельных модулях Все структуры данных должны быть обособлены в модуле, доступ к ним будет возможен для всех процедур этого модуля и закрыт для всех других Доступ к данным их модуля должен осуществляться только через процедуры данного модуля

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

CASE-средства UML (Unified Modeling Language ) Ration Rose

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

Проектирование подсистем • Структурный подход. Диаграмма сущностьсвязь, структурные карты, диаграммы деятельности, блок-схемы, схемы экранов, псевдокод • ОО: диаграммы коопераций, компонентов, развертывания.

Методы анализа и построения спецификаций • Структурный подход: диаграммы потоков данных, управления, таблицы решений, сети Петри, диаграммы зависимостей, декомпозиции, функционального моделирования. • ОО: ДВИ, классов, состояний, деятельности, последовательности