RAD-технология (Rapid Application Development) – это технология быстрого создания приложений на основе прототипирования и использования графического пользовательского интерфейса GUI (Graphical User Interface).
RAD-технология не в состоянии обеспечивать разработку сложных продуктов, содержащих много фрагментов, программирование которых занимает более двух недель. Эта технология ориентирована скорее на разработку достаточно простого заказного программного обеспечения, чем на индустриальное проектирование ИС.
Решения почти всех проблем, связанных с разработкой небольших ИС, достигаются с применением признанной во всем мире RAD-технологии. Она заключается в том, что организуется так называемая RAD-группа из 6-7 человек, состоящая из руководителя, системного аналитика и 4-5 программистов, которым даются четкие планы на весь период разработки проекта со сроками от 1 до 2 недель.
Основой этой технологии является спиральная модель создания ИС (рис. 6.1). Как видно на рисунке, разработка идет по спирали, проходя неоднократно все 4 стадии разработки ИС.
Рисунок 6.1 – Спиральная модель проектирования на основе RAD-технологии
На стадии анализа пользователи осуществляют следующие действия:
· определяют функции, которые должна выполнять система;
· выделяют наиболее приоритетные функции, требующие проработки в первую очередь;
· описывают информационные потребности. Формулирование требований к системе осуществляется в основном силами пользователей под руководством специалистов-разработчиков. Кроме того, на данной стадии решаются следующие задачи:
· ограничивается масштаб проекта;
· устанавливаются временные рамки для каждой из последующих стадий;
· определяется сама возможность реализации проекта в заданных размерах финансирования, на имеющихся аппаратных средствах и т.п. Результатом стадии должны быть:
· список расставленных по приоритету функций будущего ПО ИС;
· предварительные модели ПО.
На стадии проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. Для быстрого получения работающих прототипов приложений используются соответствующие инструментальные средства (CASE-средства). Пользователи, непосредственно взаимодействуя с разработчиками, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей стадии. На данной стадии выполняются следующие действия:
· более детально рассматриваются процессы системы;
· при необходимости для каждого элементарного процесса создается частичный прототип: экранная форма, диалог, отчет, устраняющий неясности или неоднозначности;
· устанавливаются требования разграничения доступа к данным;
· определяется состав необходимой документации.
После детального определения состава процессов оценивается количество так называемых функциональных точек (functionpoint) разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время (до 3 месяцев).
Функциональная точка – этолюбой из элементов разрабатываемой системы:
· входной элемент приложения (входной документ или экранная форма);
· выходной элемент приложения (отчет, документ, экранная форма);
· запрос (пара «вопрос/ответ»);
· логический файл (совокупность записей данных, используемых внутри приложения);
· интерфейс приложения (совокупность записей данных, передаваемых другому приложению или получаемых от него).
Далее проект распределяется между различными командами разработчиков. Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций.
В случае использования CASE-средств это означает деление функциональной модели системы (диаграммы потоков данных для структурного подхода или диаграммы вариантов использования для объектно-ориентированного подхода.
Результатом данной стадии должны быть:
· общая информационная модель системы;
· функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
· точно определенные интерфейсы между автономно разрабатываемыми подсистемами;
· построенные прототипы экранных форм, отчетов, диалогов.
Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование обусловлено необходимостью избежать неконтролируемого искажения данных при передаче информации о проекте со стадии на стадию.
В отличие от имевшего место ранее подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую стадию передается более полная и полезная информация.
На стадии реализации выполняется непосредственно сама быстрая разработка приложения:
· разработчики производят итеративное построение реальной системы на основе полученных на предыдущей стадии моделей, а также требований нефункционального характера (требований к надежности, производительности и т.п.);
· пользователи оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется в процессе разработки.
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения, а затем тестирование системы в целом. Реализация системы завершается выполнением следующих работ:
· осуществляется анализ использования данных и определяется необходимость их распределения;
· производится физическое проектирование базы данных;
· формулируются требования к аппаратным ресурсам;
· устанавливаются способы увеличения производительности;
· завершается разработка документации проекта.
Содержание, состав методов и средств концепции оригинального проектирования ИС.
Цель методологии создания информационных систем (ИС) заключается в организации процесса построения ИС и обеспечении управления этим процессом для того, чтобы гарантировать выполнение требований как к самой ИС, так и к характеристикам процесса разработки.
Методология должна обеспечивать снижение сложности процесса создания ИС за счет полного и точного описания этого процесса и применения современных методов и технологий создания ИС на всем жизненном цикле ИС - от замысла до реализации.
Основные составляющие методологии Предлагаемая методология создания корпоративных ИС состоит из двух основных взаимосвязанных частей: методологии анализа ИС, включающей описание деятельности организации и формирование требований к ИС на основе бизнес-процессов, и методологии проектирования от данных, предназначенной для проектирования и быстрой разработки программного и информационного обеспечения ИС. Таким образом, фундамент предлагаемой методологии составляют:
· итерационная спиральная модель жизненного цикла ИС;
· комплекс развивающихся систем согласованных моделей;
· методология анализа ИС на основе бизнес-процессов;
· методология проектирования от данных;
· комплекс согласованных инструментальных средств
Основное содержание технологии проектирования составляют технологические инструкции, состоящие из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих
операций.
Технология проектирования может быть представлена как совокупность трех составляющих:
· заданной последовательности выполнения технологических операций проектирования;
· критериев и правил, используемых для оценки результатов выполнения технологических операций;
· графических и текстовых средств (нотаций), используемых для описания проектируемой системы.
Каждая технологическая операция должна обеспечиваться следующими материальными и информационными ресурсами:
· данными, полученными на предыдущей операции (или исходными данными), представленными в стандартном виде;
· методическими материалами, инструкциями, нормативами и стандартами;
· программными и техническими средствами;
· исполнителями.
Результаты выполнения операции должны представляться в некотором стандартном виде, обеспечивающем их адекватное восприятие при выполнении следующей технологической операции (на которой они будут использоваться в качестве исходных данных).
Содержание, состав методов и средств концепции типового проектирования ИС. Варианты и спользование типовых проектных решений в проекте ИС.
Типовое проектирование ИС предполагает создание системы из готовых типовых элементов. Основополагающим требованием для применения методов типового проектирования является возможность декомпозиции проектируемой ИС на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.). Для реализации выделенных компонентов выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия.
Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному использованию) проектное решение.
Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:
§ элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному);
§ подсистемные ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей;
§ объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.
Каждое типовое решение предполагает наличие, кроме собственно функциональных элементов (программных или аппаратных), документации с детальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы.
Для реализации типового проектирования используются два подхода: параметрически-ориентированное и модельно-ориентированное проектирование.
Состав и содержание работ на этапе предпроектного обследования. Методы организации проведения обследования, сбора и анализа материалов обследования.
Обследование – это изучение и диагностический анализ организационной структуры предприятия, его деятельности и существующей системы обработки информации. Материалы, полученные в результате обследования, используются для:
· обоснования разработки и поэтапного внедрения систем;
· составления технического задания на разработку систем;
· разработки технического и рабочего проектов систем.
На стадии обследования целесообразно выделить три этапа:
1. определение стратегии внедрения ИС,
2. сбор материалов обследования,
3. анализ материалов обследования.
Определение стратегии внедрения ИС. Основная задача первого этапа обследования – оценка реального объема проекта, его целей и задач на основе выявленных функций и информационных элементов автоматизируемого объекта высокого уровня. Эти задачи могут быть реализованы или заказчиком ИС самостоятельно, или с привлечением консалтинговых организаций.
2. Сбор материалов обследования. Все методы проведения обследования можно объединить в группы по следующим признакам:
1. по цели обследованиявыделяют:
· метод организациилокального проведения обследования, используемый для разработки проекта отдельной задачи или для комплекса задач;
· метод системного обследования объекта, применяемый для изучения всего объекта с целью разработки для него проекта ИС в целом;
2. по числу исполнителей, проводящих обследование, применяется:
· индивидуальное обследование, осуществляемое одним проектировщиком;
· бригадное с выделением ряда бригад-исполнителей, изучающих все подразделения предприятия, и одной координирующей бригады;
3. по степени охвата предметной областиприменяют:
· метод сплошного обследования, охватывающего все подразделения экономической системы;
· выборочное обследование, применяемое при наличии типовых по структуре подразделений (например, цехов или складов);
4. по степени одновременности выполнения работпервого и второго этапов предпроектной стадии выделяют:
· метод последовательного проведения работ, при котором проектировщики сначала собирают данные о предметной области, а затем их изучают (часто применяют при отсутствии опыта в выполнении такого рода работ);
· метод параллельного выполнения работ, когда одновременно со сбором происходит изучение полученных материалов обследования, что значительно сокращает время на проведение работ на предпроектной стадии и повышает качество получаемых результатов.
3. Анализ материалов обследования. На основе формализованного описания предметной области выполняется анализ материалов обследования. Здесь изучаются задачи, обеспечивающие реализацию функций управления, организационная структура, штаты и содержание работ по управлению предприятием, а также характер подчиненности вышестоящим органам управления. На этом этапе должны быть выявлены:
· инструктивно-методические и директивные материалы, на основании которых определяются состав подсистем и перечень задач;
· возможности применения новых методов решения задач.
Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:
· функции – информация о событиях и процессах, которые происходят в бизнесе;
· сущности – информация о вещах, имеющих значение для организации и о которых что-то известно.
При изучении каждой функциональной задачи управления определяются:
· наименование задачи;
· сроки и периодичность ее решения;
· степень формализуемости задачи;
· источники информации, необходимые для решения задачи;
· показатели и их количественные характеристики;
· порядок корректировки информации;
· действующие алгоритмы расчета показателей и возможные методы контроля;
· действующие средства сбора, передачи и обработки информации;
· действующие средства связи;
· принятая точность решения задачи;
· трудоемкость решения задачи;
· действующие формы представления исходных данных и результатов их обработки в виде документов;
· потребители результатной информации по задаче.