CASE-технологии проектирования автоматизированных информационных систем

   Специалистами отмечаются следующие преимущества спиральной модели:

   ♦ накопление и повторное использование  программных средств, моделей и  прототипов;

   ♦ ориентация на развитие и модификацию  ПО в процессе его проектирования;

   ♦ анализ риска и издержек в процессе проектирования.

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

   2. RAD-технологии прототипного создания приложений 

   Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий три элемента:

   ♦ небольшую команду программистов (от 2 до 10 человек);

   ♦ короткий, но тщательно проработанный  производственный график (от 2 до б мес);

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

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

   Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

   ♦ фазы анализа и планирования требований;

   ♦ фазы проектирования;

   ♦ фазы построения;

   ♦ фазы внедрения.

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

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

   После детального определения состава  процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении АИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время — примерно 60—90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:

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

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

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

   ♦ построенные прототипы экранов, отчетов, диалогов.

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

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

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

   После окончания работ каждой отдельной  команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы:

   ♦ определяется необходимость распределения  данных;

   ♦ производится анализ использования  данных;

   ♦ производится физическое проектирование базы данных;

   ♦ определяются требования к аппаратным ресурсам;

   ♦ определяются способы увеличения производительности;

   ♦ завершается разработка документации проекта. Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

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

   Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т. е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.

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

   ♦ разработка приложений итерациями;

   ♦ необязательность полного завершения работ на каждом из этапов жизненного цикла;

   ♦ обязательное вовлечение пользователей  в процесс разработки АИС;

   ♦ необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

   ♦ необходимое использование генераторов  кода;

   ♦ использование прототипирования, позволяющего полнее выяснить и удовлетворить потребности конечного пользователя;

   ♦ тестирование и развитие проекта, осуществляемые одновременно с разработкой;

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

   ♦ грамотное руководство разработкой  системы, четкое планирование и контроль выполнения работ. 

   3. Структурный метод разработки программного обеспечения 

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

   Все методологии структурного анализа  базируются на ряде общих принципов, часть из которых регламентирует организацию работ на начальных  этапах ЖЦ, а часть используется при выработке рекомендаций по организации работ. В качестве двух базовых принципов используются следующие: принцип "разделяй и властвуй" и принцип иерархического упорядочивания. Первый является принципом решения трудных проблем путем разбиения их на множество меньших независимых задач, более легких для понимания и решения. Второй принцип декларирует, что устройство этих частей также существенно для понимания. Уровень уяснения проблемы резко повышается при представлении ее частей в виде древовидных иерархических структур, т. е. система может быть понята и построена по уровням, каждый из которых добавляет новые детали.

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

   1. Принцип абстрагирования — заключается  в выделении существенных с некоторых позиций аспектов системы и отвлечении от несущественных с целью представления проблемы в простом общем виде.

   2. Принцип формализации — заключается  в необходимости строгого методического подхода к решению проблемы.

   3. Принцип "упрятывания" —  заключается в упрятывании несущественной на конкретном этапе информации: каждая часть "знает" только необходимую ей информацию.