Раздел 7. Индустриальное проектирование программного обеспечения ИС

Тема 22. Прототипное проектирование ИС

План лекции

1. RAD-технология

2. Фазы RAD-разработки

3. Ограничения на применение RAD

4. Инструментальные средства RAD-технологии

 

RAD-технология

Историческая справка. Разработка многочисленных бизнес-приложений с базами данных и информационных систем с клиент-серверной архитектурой в 1980-х гг. выявили следующие особенности:

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

- функциональность и технические характеристики систем автоматизации бизнес-деятельности могут наращиваться и совершенствоваться постепенно; острой необходимости в полностьюзавершенной системе нетпоследовательное развитие системы даже целесообразно по тойпричине, что очень часто четко и исчерпывающе сформулироватьтребования к информационной системе за один раз оказываетсяневозможным, постоянно возникают новые задачи и уточнения(например, в связи с изменением экономической ситуации илизаконодательства;

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

- алгоритмическая сложность прикладных задач в бизнесе невелика.

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

Указанная специфика ИС для бизнеса явилась стимулом «революции» в информационных технологиях, так как выяснилось, чтокаскадная модель жизненного цикла программных систем (Waterfallmodel – водопадная модель) неприемлема для современных бизнес-приложений в связи с однократностью формулировки требованийи разработки системы до окончательного варианта. Для бизнеса такой подход был противоестествен: излишне строг, дорог, длителен иглавное, малоэффективен, так как не полностью и не точно (по объективным причинам) сформулированные требования к системе устаревали к моменту ее готовности. Более конструктивной оказалась спиральная модель Барри Боэма, получившаявоплощение во многих методологиях, в том числе и в RAD (RapidApplication Development) (быстрая разработка приложений).

Основателем RAD считается Джеймс Мартин – сотрудник IBM, сформулировавший в 1991 г. основные принципы RAD, основываясьна идеях Барри Боэма и Скотта Шульца. В настоящее время RAD является общепринятой схемой для создания средств разработки программных продуктов, нацеленных на ускоренную разработку приложений. Ее идеи образуют основу современных технологий, таких, какRUP, Oracle, Borland, ComputerAssociates, MSF.

Базовые принципы. Базовые принципы RAD заключаются в следующем:

1) разработка ПО осуществляется небольшой постоянной командой разработчиков за 3…4 мес; в команде разработчиков должна бытьобеспечена практически полная взаимозаменяемость участников(каждый член команды должен быть универсалом);

2) разработка осуществляется путем инкрементного прототипирования, т. е. посредством итераций, в каждой из которых создаютсяупрощенные образцы системы – прототипы с одновременным наращиванием функциональности и надежности в каждом последующем прототипе;

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

4) управление проектом должно быть предельно эффективными нацеленным на минимизацию длительности цикла разработкиза счет оперативности и квалифицированности принимаемых решений;

5) в процессе выполнения проекта осуществляется непрерывноетестирование проектных решений;

6) в разработке активно участвуют представители заказчика начиная с первых этапов – с обследования организации и выработкитребований к системе.

Число создаваемых прототипов определяется объемом реализуемой функциональности, предъявляемыми нефункциональнымитребованиями, потенциальными рисками. Для проектов ИС малойсложности обычно создаются три прототипа;

1) первый содержит только пользовательский интерфейс, практически без функциональности; он позволяет во взаимодействиис заказчиком сформировать основу наиболее важных экранных и отчетных форм;

2) второй дополняет созданный ранее пользовательский интерфейс функциональностью системы, реализованной на 70…80%;

3) третий содержит полностью реализованную требуемую функциональность.

В большинстве реальных проектов прототипов создается гораздобольше в связи с эволюцией требований заказчика в процессе создания системы, изменением видения проекта и его конечной цели.

Кроме того, реализация дополнительной функциональности частовыявляет существенные недостатки и упущения в предшествующихпроектных решениях, включая и пользовательский интерфейс. Возникает потребность не только в исправлении ошибок, но и в повышении эффективности программного кода. Если предметная область сложна, то для выполнения проекта может быть создано несколькоRAD-групп; каждое проектное решение каждой группы – это новыйпрототип системы.

Принципы технологии RAD направлены на обеспечение пятиосновных ее преимуществ: 1) высокая скорость разработки; 2) низкаястоимость разработки; 3) высокое качество создаваемого продукта; 4) низкая стоимость сопровождения; 5) лучшее удовлетворение требований пользователей.

Практически во всех источниках содержится символическое изображение достоинств технологии RAD, представленное на рис. 22.1.

Рис. 22.1. Достоинства технологии RAD

 

К сожалению, на рисунке представлены только первые три достоинства технологии RAD, но не сложно мысленно дорисоватьи четвертую, и пятую составляющие преимуществ RAD.

Достигнуть высокого качества создаваемой системы очень непросто. Одна из основных причин заключается в том, что разработчики заказчик видят предмет разработки по-разному. Это обусловливаетнеобходимость применения средств наглядного и однозначного представления, как требований, так и проектных решений. В настоящее время самым распространенным таким средством являетсяунифицированный язык графическогомоделирования UML.

Участие представителей заказчикав разработке (эти представители тестируют создаваемые прототипы, оперативно корректируют требования, участвуютв оформлении документации) обусловливает полное выполнение предъявляемых требований, как функциональных, так и нефункциональных, с учетом их возможных изменений в период разработки системы, а также получение качественнойдокументации, обеспечивающей удобство эксплуатации и сопровождения системы. Это означает, что дополнительные затраты на сопровождение сразу после поставки будут значительно меньше. Таким образом, полное время – от начала разработки до полученияприемлемого продукта – при использовании RAD значительно сокращается с одновременным повышением степени удовлетворениятребований пользователей.

 

Фазы RAD-разработки

Жизненный цикл ИС при использовании методологии RAD состоит из следующих фаз: 1) анализ и изложение требований; 2) проектирование; 3) запуск подсистем на синтез; 4) синтез; 5) вовлечениеподсистем в эксплуатацию; 6) эксплуатация с возможными возвратами на п. 3.

Схематично жизненный цикл ИС, создаваемой по RAD-методологии, показан на рис. 22.2.

 

Рис. 22.2. Жизненный цикл ИС, создаваемой по RAD-методологии

 

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

Нафазе проектирования часть пользователей принимает участиев техническом проектировании системы под руководством специалистов-разработчиков. На первом шаге предварительного проектирования используются CASE-средства для быстрого получения работающих прототипов приложений. Пользователи, непосредственновзаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробнорассматриваются процессы системы. Анализируется и при необходимости корректируется функциональная модель. Каждый процессрассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип (экран, диалог, отчет), устраняющий неясности или неоднозначности. Определяютсятребования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации.

Артефактами предварительного проектирования являются:

1) первый прототип пользовательского интерфейса:

2) уточненные функциональные требования:

3) требования к составу документации.

На втором шаге проектирования после детального определениясостава процессов принимаются решения по требованиям нефункционального характера, оценивается количество функциональныхэлементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время – около60 … 90 дней.

С использованием CASE-средств проект распределяется междуразличными командами (делится функциональная модель). Артефактами второго шага проектирования являются:

1) общая информационная модель системы;

2) функциональная модель системы в целом;

3) функциональные модели подсистем, реализуемых отдельнымикомандами разработчиков;

4) точно определенные с помощью CASE-средства интерфейсымежду автономно разрабатываемыми подсистемами;

5) практически окончательный вариант пользовательского интерфейса – построенные прототипы экранов, отчетов, диалогов;

6) требования к аппаратным ресурсам.

Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшемпри построении системы. Данное требование обусловлено тем, чтов традиционном подходе при передаче информации о проекте с этапа на этап может произойти неконтролируемое искажение данных.

Применение единой среды хранения информации о проекте позволяет избежать этой опасности.

В отличие от традиционного подхода, при котором использовалисьспецифические средства прототипирования, не предназначенныедля построения реальных приложений, а прототипы выбрасывалисьпосле того, как выполняли задачу устранения неясностей в проектев подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полнаяи полезная информация.

Нафазе запуска подсистем на синтез формируются командыразработчиков, устанавливаются сроки выполнения работ по созданию подсистем, определяется порядок взаимодействия командс руководством и друг с другом, издаются соответствующие распоряжения – приказы по учреждению. Эти распоряжения и являютсяартефактами фазы запуска подсистем на синтез.

Нафазе синтеза подсистем каждая команда осуществляет непосредственное создание порученной ей подсистемы, реализуя процессы проектирования, кодирования, тестирования, верификациии документирования. Эти процессы могут повторяться по требованиям конечных пользователей. Проектирование на фазе синтеза – это процессы предельной конкретизации функциональностиподлежащей реализации, и разработки ассоциированных структурданных и фрагментов базы данных, включая физическую генерацию базы.

Кодирование – это процесс составления программного кода. Частично программный код может формироваться при помощи автоматических генераторов, получающих информацию из репозитория.

CASE-средств. Тестирование – это проверка работоспособностикода. Верификация – это проверка и доказательство соответствиякода функциональным спецификациям. Конечные пользователина этой фазе синтеза оценивают получаемые результаты и вносяткоррективы, если в процессе разработки подсистемы перестаютудовлетворять определенным ранее или вновь появившимся требованиям. Главными артефактами фазы синтеза являются версииподсистем – файлы программного кода и баз данных. Ассоциированным артефактом является документация по отдельным подсистемам, включающая в себя, в частности, протоколы тестированияи верификации.

Фаза вовлечения подсистем в эксплуатацию начинается с момента завершения работ по синтезу первой подсистемы. Синтезированная подсистема образует текущее состояние создаваемой ИС.

По завершении синтеза следующей подсистемы она также немедленно вовлекается в эксплуатацию. Действительно, нет смысла ожидатьзавершения создания подсистемы складского учета, если уже готовк эксплуатации учет кадров. Каждая очередная подсистема интегрируется (объединяется) с уже функционирующими подсистемами.

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

Завершается фаза вовлечения подсистем в эксплуатацию в момент завершения синтеза последней подсистемы. Артефактами этойфазы являются:

1) последовательность частных версий ИС, формируемых в процессе вовлечения в эксплуатацию очередных подсистем;

2) финальная версия ИС, создаваемая в момент вовлечения в эксплуатацию последней подсистемы;

3) документация по системе, включающая в себя, в том числеуточненные требования к аппаратным ресурсам и предложения о путях увеличения производительности системы.

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

Изложенная схема разработки ИС – это некоторый образец, являющийся ориентиром. В конкретных ситуациях возможны многочисленные вариации, зависящие от условий, в которых ведется разработка. В частности, существенное значение имеют следующие вопросыразрабатывается ли совершенно новая система или на предприятииуже существует действующая ИС, которая может быть использованав качестве начального прототипа, и должна ли она быть интегрирована с новой системой; было ли ранее проведено обследованиепредприятия и существует ли модель его деятельности? Решающеезначение имеет общая изначальная сложность проекта.