Ограничения методологии RAD

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

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

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

Лекция 16

Стандарты и методики

Одним из важных условий эффективного использования информационных тех­нологий является внедрение корпоративных стандартов. Корпоративные стандарты представляет собой соглашение о единых правилах организации технологии или управления. При этом за основу корпоративных могут приниматься отраслевое, национальные и даже международные стандарты.

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

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

· стандарты на продукты и услуги;

· стандарты на процессы и технологии;

· стандарты на формы коллективной деятельности, или управленческие стандарты.

Виды стандартов

Существующие на сегодняшний день стандарты можно несколько условно разде­лить на несколько групп по следующим признакам:

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

· по утверждающей организации. Здесь можно выделить официальные международные, официальные национальные или национальные ведомственные стандар­ты (например, ГОСТы, ANSI, IDEFO/i), стандарты международных консорциу­мов и комитетов по стандартизации (например, консорциума OMG), стандарты «де-факто» — официально никем не утвержденные, но фактически действующие (например, стандартом «де-факто» долгое время были язык взаимодействия с реляционными базами данных SQL и язык программирования С), фирменные стандарты (например, Microsoft ODBC);

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

Примечание

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

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

· методика Oracle CDM (Custom Development Method) no разработке прикладных информационных систем под заказ;

· международный стандарт ISO/IEC 12207:1995-08-01 на организацию жизненного цикла продуктов программного обеспечения;

· отечественный комплекс стандартов ГОСТ 34.

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

Методика Oracle CDM

Одним из уже сложившихся направлений деятельности фирмы ORACLE стала разработка методологических основ и производство инструментальных средств для автоматизации процессов разработки сложных прикладных систем, ориентирован­ных на интенсивное использование баз данных. Методика Oracle CDM является развитием давно разработанной версии Oracle CASE-Method, применяемой в CASE-средстве Oracle CASE (в новых версиях - Designer/2000).

Основу CASE-технологии и инструментальной среды фирмы ORACLE составляют:

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

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

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

· наличие централизованной базы данных, репозитария, для хранения спецификаций проекта прикладной системы на всех этапах ее разработки. Такой репозитарий представляет собой базу данных специальной структуры, работающую под управлением СУБД ORACLE;

· возможность одновременной работы с репозитарием многих пользователей. Такой многопользовательский режим почти автоматически обеспечивается стандартными средствами СУБД ORACLE. Централизованное хранение проекта системы и управление одновременным доступом к нему всех участников разработки поддерживают согласованность действий разработчиков и не допускают ситуацию, когда каждый проектировщик или программист работает со своей версией проекта и модифицирует ее независимо от дру­гих;

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

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

Общая структура

Жизненный цикл формируется из определенных этапов (фаз) проекта и процес­сов, каждый из которых выполняется в течение нескольких этапов, Методика Oracle CDM определяет следующие фазы жизненного цикла информа­ционной системы:

· стратегия (определение требований);

· анализ (формулирование детальных требований к прикладной системе);

· проектирование (преобразование требований в детальные спецификации сис­темы);

· реализация (написание и тестирование приложений);

· внедрение (установка новой прикладной системы, подготовка к началу эксплуа­тации);

· эксплуатация (поддержка приложения и слежение за ним, планирование буду­щих функциональных расширений).

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

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

· информационные, отражающие структуру и общие закономерности предметной области;

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

Примечание

Использование генераторов приложений, входящих в состав DESIGNER/2000, позво­ляет полностью автоматизировать этот этап, существенно сократить сроки разработки системы и повысить ее качество и надежность.

Методика Oracle CDM выделяет следующие процессы, протекающие на протяже­нии жизненного цикла информационной системы;

· определение производственных требований;

· исследование существующих систем;

· определение технической архитектуры;

· проектирование и построение базы данных;

· проектирование и реализация модулей;

· конвертирование данных;

· документирование;

· тестирование;

· обучение;

· переход к новой системе;

· поддержка и сопровождение.

Процессы состоят из последовательностей задач, задачи разных процессов взаи­мосвязаны с помощью явных ссылок.