38. Прототипирование в разработке проекта информационной системы. Виды прототипов и технологический переход от прототипа к промышленной системе.
Прототипирование (prototyping)— это наиболее часто используемый современный метод выявления требований.
Программные прототипы конструируются для визуализации системы или ее части для заказчиков с целью получения их отзывов.
Прототип представляет собой демонстрационную систему — "наскоро и грубо" сделанную рабочую модель решения, которая представляет пользовательский GUI-интерфейс и моделирует поведение системы при инициировании пользователем различных событий. Информационное наполнение экранов чаще жестко запрограммировано в программе прототипа, чем получается автоматически из базы данных.
Сложность (и растущие "аппетиты" заказчиков) современных GUI-интерфейсов делают прототипирование обязательным элементом разработки ПО.
Прототипы позволяют довольно неплохо оценить реализуемость и полезность системы до начала ее реализации.
В общем случае, прототип — это весьма эффективный способ выявления требований, которые трудно получить от заказчика с помощью других средств. Чаще всего такая ситуация встречается для систем, которые должны предоставить в распоряжение пользователей новые бизнес-функции. Подобная ситуация также характерна:
для случаев противоречивых требований
наличия проблем в кооперации между заказчиками и разработчиками.
Существуют две основные разновидности прототипов.
■ "Одноразовый"прототип ("throw-away"prototype), который после того, как выявление требований завершено, просто отбрасывается. Разработка "одноразового" прототипа нацелена только на этап установления требований ЖЦ ПО. Как правило, этот прототип концентрируется на наименее понятных требованиях.
■ Эволюционный прототип (evolutionary prototype), который сохраняется после выявления требований и используется для создания конечного программного продукта. Эволюционный прототип нацелен на ускорение поставки продукта. Как правило, он концентрируется на ясно изложенных требованиях, так что первую версию продукта можно предоставить заказчику довольно быстро (хотя ее функциональные возможности, как правило, неполны).
Дополнительным доводом в пользу использования именно "одноразового" прототипа может служить стремление избежать риска "консервации" скорых и грубых и, как следствие, неэффективных решений в конечном продукте.
Однако мощь и гибкость современных средств создания ПО ослабляют этот довод. Если управление проектом осуществляется надлежащим образом, то причины, по которой нельзя было бы избавиться от неэффективных предложенных для прототипа решений, не существует.
Совместная разработка приложений (JAD-метод)
JAD-метод полностью соответствует своему названию — это совместная разработка приложений (Joint Application Development), осуществляемая в ходе одного или нескольких совещаний с привлечением всех участников проекта (заказчиков и разработчиков). Хотя JAD-подход относится к современным методам выявления требований, этот метод был впервые введен в конце 1970-х годов компанией IBM.
Существует много разновидностей JAD-метода и много фирм, предлагающих услуги по организации и проведению JAD-совещаний. Проведение JAD-совещаний может занимать несколько часов, несколько дней или даже пару недель. Количество участников не должно превышать 25-30 человек. В совещании принимает участие следующий круг лиц.
■ Ведущий — человек, который проводит и модерирует встречу (поэтому иногда его называют модератором). Этот человек должен обладать исключительными способностями в области коммуникации, не должен относиться к числу участников проекта (несмотря на то, что он является лидером JAD-сессии), должен обладать основательным знанием проблемной области (однако не обязательно хорошо владеть проблемами разработки ПО).
■ Секретарь — человек, который фиксирует ход JAD-сессии с помощью компьютера. Этот человек должен уметь быстро вводить текст в компьютер и хорошо владеть вопросами разработки ПО. Для документальной фиксации хода сессии и разработки первоначальных моделей решений секретарь может использовать CASE-средства.
■ Заказчики (пользователи или руководители) — это основные участники, которые излагают и обсуждают требования, принимают решения, утверждают проектные цели и т.д.
■ Разработчики — бизнес-аналитики и другие члены проектной бригады. Эти участники больше слушают, чем говорят— они присутствуют на совещании для того, чтобы уяснить фактическую сторону дела и собрать информацию, а не занимать всецело внимание других участников в процессе совещания.
JAD-метод зиждется на групповой динамике. Групповые усилия более перспективны, с точки зрения получения лучших решений проблем. Группы способствуют повышению продуктивности, быстрее обучаются, склонны к более квалифицированным заключениям, позволяют исключить многие ошибки, принимают рискованные решения (иногда это может носить негативный характер!), концентрируют внимание участников на наиболее важных вопросах, объединяют людей и т.д.
Если JAD-сессия проводится в соответствии с правилами, можно добиться удивительно хороших результатов.
Хотя все время следует помнить – нет ничего абсолютного и безусловного при создании нового проекта.
Быстрая разработка приложений (RAD-метод).
Метод быстрой разработки приложений (Rapid Application Development— RAD) — это нечто большее, чем метод выявления требований — это целостный подход к разработке ПО. Как ясно из названия метода, он предполагает быструю поставку системных решений. Техническое превосходство отступает на второе место в сравнении со скоростью поставки.
Согласно Буду (Wood) и Сильверу (Silver) технология RAD сочетает в себе
пять методов, перечисленных ниже.
■ Эволюционное прототипирование
■ Использование CASE-средства с возможностями генерации программ и циклической разработкой с переходом от проектных моделей к программе и обратно.
■ Использование специалистов, владеющих развитыми инструментальными средствами (Specialists with Advanced Tools— SWAT) — RAD-бригада разработчиков. Лучшие аналитики, проектировщики и программисты, которых только может привлечь организация. Бригада работает в рамках строгого временного режима и размещается вместе с пользователями.
■ Интерактивный JAD-метод—JAD-сессии, во время которой секретарь заменяется бригадой SWAT, оснащенной CASE-средствами.
■ Жесткие временные рамки (timeboxing) — метод управления проектом, который отводит бригаде SWAT фиксированный период времени (timebox) для завершения проекта. Этот метод препятствует "расползанию рамок проекта". Если проект затягивается, то рамки решения сужаются, чтобы дать возможность завершить проект своевременно.
Использование RAD-подхода может оказаться привлекательным вариантом для многих проектов, в особенности, для небольших проектов, которые не затрагивают сферу ключевых бизнес-процессов организации, и которые, таким образом, не задают план решения для других проектов по разработке ПО. Маловероятно, чтобы быстрые решения были оптимальными или долговременными для ключевых сфер деятельности организации. С использованием RAD-метода может быть связан ряд проблем; некоторые из них перечислены ниже.
1. Несовместимый проект GUI-интерфейса.
2. Вместо общих решений, способствующих многократному использованию ПО, специализированные решения.
3. Неполная документация.
4. Трудное для поддержки и масштабирования ПО и т.д.
39.Методологии автоматизированного проектирования для анализа и синтеза систем и их применение на различных этапах создания программного проекта. Проектирование информационных систем с использованием структурного подхода.
Система автоматизации проектных работ (САПР) – это организационно-техническая система, состоящая из комплекса средств автоматизации проектирования, взаимосвязанного с необходимыми подразделениями проектной организации или коллективом специалистов (пользователей системы) и выполняющая автоматизированное проектирование.
Составными структурными частями САПР являются подсистемы, обладающие всеми свойствами систем и создаваемые как самостоятельные.
Подсистемой САПР называют выделенную по некоторым признакам часть САПР, обеспечивающую получение законченных проектных решений.
По назначению подсистемы САПР разделяют на проектирующие и обслуживающие.
К проектирующим относят подсистемы, выполняющие проектные процедуры и операции, например, подсистема логического проектирования, подсистема конструкторского проектирования, подсистема проектирования деталей и сборочных единиц и т.п.
К обслуживающим относят подсистемы, предназначенные для поддержания работоспособности проектирующих подсистем, например, подсистема информационного поиска, подсистема документирования проекта и т.п.
По отношению к объекту проектирования различают объектно-ориентированные (объектные) и объектно-независимые (инвариантные) подсистемы.
К объектным относят подсистемы, выполняющие одну или несколько проектных процедур или операций, непосредственно зависимых от конкретного объекта проектирования.
К инвариантным относят подсистемы, выполняющие унифицированные проектные процедуры и операции, например, функции отработки, не зависящие от особенностей проектируемого объекта.
Подсистемы состоят из компонентов, объединенных общей для данной подсистемы целевой функцией и обеспечивающих функционирование этой подсистемы.
Основное назначение САПР – получение оптимальных проектных решений. Проектирование в САПР осуществляется путем декомпозиции проектной задачи с последующим синтезом общего проектного решения. В процессе синтеза проекта используются информационные ресурсы базы данных в условиях диалогового взаимодействия проектировщиков с комплексом средств автоматизации.
Технологии проектирования в САПР базируются на следующих принципах:
использование комплексного моделирования;
интерактивное взаимодействие с математической моделью;
принятие проектных решений на основе математических моделей и проектных процедур, реализуемых средствами вычислительной техники;
обеспечение единства модели проекта на всех этапах и стадиях проектирования;
использование единой информационной базы для автоматизированных процедур синтеза и анализа проекта, а также для управления процессом проектирования;
проведение многовариантного проектирования и комплексной оценки проекта с применением методов оптимизации;
обеспечение максимальной инвариантности информационных ресурсов, их слабой зависимости от конкретной области применения, простоты настройки на отраслевую специфику.
Структурное проектирование
Технологии структурного подходаориентированы, в первую очередь, на процессы обработки данных с последующим установлением необходимых для этого данных и организации информационных процессов между связанными процессами.
Для таких методов характерно:
разбиение на уровни абстракции с ограничением числа элементов на каждом уровне (обычно от 3 до 6-7);
ограниченный контекст, включающий лишь существенные на каждом уровне детали;
дуальность (лат. – двойственность) данных и операций над ними;
использование строгих формальных правил записи;
последовательное приближение к конечному результату.
Жизненный цикл проекта укрупнено включает в себя три этапа:
Анализ (см. файл «Анализ ПдО»)
Проектирование
Реализация
Этап анализа концентрируется на системных требованиях. Требования определяются и специфицируются. Осуществляется разработка и интеграция функциональных моделей и моделей данных для системы. Кроме того, фиксируются нефункциональные требования и другие системные ограничения.
Результатом работ на этапе анализа является:
перечень недостатков ПдО
список специфицированных требований (техническое задание)
системный проект (см. файл «Анализ ПдО»)
предложения по повышению эффективности деятельности исследуемого объекта (технико-экономическое обоснование проведения работ или бизнес-план)
Структурным анализом принято называть метод исследования системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней.
Методы структурного анализа и проектирования стремятся преодолеть сложность систем путем деления системы на «черные ящики» и иерархической организации этих черных ящиков, при этом разбиение должно удовлетворять следующим критериям:
каждый черный ящик должен реализовывать единственную функцию системы;
функция каждого черного ящика должна быть легко понимаема независимо от сложности ее реализации
связь между черными ящиками должна вводится только при наличии связимеждусоответствующими функциями системы (например, размер заработной платы требуется для расчета налогов, значит, следует установить связь между ящиком расчета зарплаты и ящиком расчета налогов);
связи между черными ящиками должны быть простыми, для обеспечения независимости между ними.
Структурные методы широко используют графические нотации (лат. – записывание, обозначение) также служащие для облегчения понимаемости сложных систем.
В структурном подходе к анализу и проектированию используются в основном две группы средств, описывающих структуру системы и отношения между данными. Каждой группе соответствуют определенные виды моделей (диаграмм), наиболее распространенными из которых являются:
DFD (DataFlowDiagrams) – диаграммы потоков данных;
SADT (StructuredAnalysisandDesignTechnique) – модели и соответствующие функциональные диаграммы;
ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь».
Диаграммы потоков данных и диаграммы «сущность-связь» наиболее часто используемые виды моделей. Конкретный вид диаграмм и интерпретаций их конструкций зависят от жизненного цикла системы, на котором они применяются.
На стадии формирования требований SADT-модели и DFD используются, как правило, для моделирования бизнес – процессов (SADT- модели используются только на этой стадии). С помощью ERD выполняется описание данных на концептуальном уровне, не зависимом от средств реализации баз данных (СУБД). На стадии анализа и проектирования DFD используются для описания структуры проектируемой системы, при этом они могут уточняться, расширяться и дополняться новыми конструкциями. Аналогично ERD уточняются и дополняются новыми конструкциями, описывающими представление данных на логическом уровне, пригодном для последующей генерации схемы базы данных. Вышеперечисленные модели могут дополняться диаграммами, отражающими системную архитектуру, структурные схемы программ, иерархию экранных форм и меню и др. Состав диаграмм в каждом конкретном случае зависит от сложности системы и необходимой полноты ее описания.
Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований к проектируемой системе. С их помощью эти требования представляются в виде иерархии функциональных компонентов (процессов), связанных потоками данных. В состав DFD могут входить четыре графических символа, представляющих:
потоки данных;
процесс преобразования входных потоков данных в выходные;
внешние источники;
получатели данных, а также файлы и БД, требуемые процессами для своих операций.
Главная цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявит связи между процессами.
Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информации. К подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации. Основными компонентами диаграммы потоков данных являются: внешние сущности, системы и подсистемы, процессы, накопители данных, потоки данных.
Отметим, что DFD моделируют функции, которые система должна выполнять, но ничего (или почти ничего) не сообщают об отношениях между данными, а также о поведении системы в зависимости от времени – для этих целей методология использует диаграммы «сущность – связь» и диаграммы переходов состояний соответственно.
Диаграммы «сущность – связь» (ERD) обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).
SАDT (StructuredAnalysisandDesignTechnique) – одна из самых известных методологий анализа и проектирования систем. С точки зрения SADT модель может основываться либо на функциях системы, либо на ее предметах (планах, данных, оборудовании, информации и т.д.). Соответствующие модели принято называть активностными моделями и моделями данных.
Активностная модель представляет с нужной степенью подробности систему активностей, которые в свою очередь отражают свои взаимоотношения через предметы системы.
Модель SADT объединяет и организует диаграммы в иерархические древовидные структуры, при этом, чем выше уровень диаграммы, тем менее она детализирована. В состав диаграммы входят блоки, изображающие активности моделируемой системы, и дуги, связывающие блоки вместе и изображающие взаимодействие и взаимосвязи блоков.
В основе стандарта IDEF0 лежит три базовых принципа:
1. принцип функциональной декомпозиции — любая функция может быть декомпозирована (детализирована, разбита) на более простые функции;
2. принцип ограничения сложности — количество блоков на диаграмме должно быть 2...6 (условие удобочитаемости);
3. принцип контекста — моделирование делового процесса начинается с построения контекстной диаграммы, на которой отображается только один блок— главная функция моделирующей системы, ограничивающая область границы моделирующей системы (регламентирует начальный этап построения модели).
IDEF0-диаграммы строятся при помощи блоков. Каждый блок описывает какое-либо законченное действие (функцию).
Каждая сторона блока имеет особое назначение:
левая сторона предназначена для ВХОДОВ;
верхняя сторона – для УПРАВЛЕНИЯ;
правая – для ВЫХОДОВ;
нижняя – для ИСПОЛНИТЕЛЕЙ(механизмов).
Такое обозначение отражает определенные принципы активности: ВХОДЫ преобразуются в ВЫХОДЫ, УПРАВЛЕНИЕ ограничивают или предписывают условия выполнения, ИСПОЛНИТЕЛИ описывают, за счет чего выполняются преобразования
законы баланс
время
платежные документы деньги
сотрудники техника
.
Спецификации управления предназначены для моделирования и документирования аспектов систем, зависящих от времени или реакции на событие. Они позволяют осуществить декомпозицию управляющих процессов и описывают отношения между входными и выходными управляющими потоками на управляющем процессе-предке. Для этой цели используются диаграммы переходов состояний (STD – StateTransitionDiagrams).
С помощью STD можно моделировать последующее функционирование системы на основе ее предыдущего и текущего функционирования. Моделируемая система в любой заданный момент времени находится точно в одном из конечного множеств состояний. С течением времени она может изменить свое состояние, при этом переходы между состояниями должны быть точно определены.
STD состоит из следующих объектов:
состояние – может рассматриваться как условие устойчивости для системы. Находясь в определенном состоянии, мы имеем достаточно информации о прошлой истории системы, чтобы определить очередное состояние в зависимости от текущих входных событий. Имя состояния должно отражать реальную ситуацию, в которой находится система, например, НАГРЕВАНИЕ, ОХЛАЖДЕНИЕ и т.п.
начальное состояние – узел STD, являющийся стартовой точкой для начального системного перехода. STD имеет ровно одно начальное состояние и любое число завершающий состояний.
переход – определяет перемещение моделируемой системы из одного состояния в другое, при этом имя перехода идентифицирует событие, являющееся причиной перехода и управляющее им.
Диаграмма переходов состояний на примере банковской задачи имеет 2 состояния – ОЖИДАНИЕ и ОБРАБОТКА. Переход из состояния ОЖИДАНИЕ в состояние ОБРАБОТКА осуществляется при условии ввода кредитной карты. При этом выполняется действие по запуску процесса ПОЛУЧИТЬ ПАРОЛЬ.
Активизируется каждый раз
«Некорректный пароль» «введенная кредитная карта» «корректный пароль»
--------------------------------- ----------------------------------------- ----------------------------
удалить кред. Карту получить пароль обеспечить требуемый
сервис
Рис. STD для банковской задачи