мдк. Автоматизированное проектирование ис

• Название: Автоматизированное проектирование ис
• Дата: 29.11.2022
• Размер: 0.63 Mb.
• Имя файла: lektsia_mdk_02_01.docx
• Тип: Документы; #818243

АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ ИС
Понятие CASE-технологии

Аббревиатура CASE (ComputerAidedSoftware/SystemEngineering) означает проектирование программного обеспечения или системы на основе компьютерной поддержки. Такое проектирование называется CASE-технологией проектирования.

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

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

CASE-технология – актуальное и интенсивно развивающееся на­правление создания САПР в области программных продуктов и ИС. Практически ни одна крупная ИС не создается в настоящее время без использования CASE-средств.

Область применения CASE-технологий относится к созданию, преж­де всего экономических ИС, что объясняется массовостью этих систем.

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

CASE-технологии применяются также там, где проблематика пред­метной области отличается большой сложностью, например в разра­ботке системного программного обеспечения.

Преимущества CASE-технологии по сравнению с традицион­ной технологией оригинального проектирования сводятся к сле­дующему:

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

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

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

Метод – это процедура или техника генерации описаний ком­понентов ИС (например, проектирование потоков и структур данных).

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

Инструментальные средства CASE – это специальные програм­мы, которые поддерживают одну или несколько методологий анализа и проектирования ИС.

Рассмотрим назначение компонентов CASE-средства (рис. 1.1).



Рисунок 1.1 – Взаимосвязь основных структурных компонентов CASE-средства

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

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

Графический редактор диаграмм предназначен для отображения в заданных нотациях всех диаграмм проектирования ИС. Редактор ди­аграмм может создавать элементы диаграмм и связи между ними.

Средства контроля и сбора статистики выполняют следующие функ­ции:

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

Генератор документов формирует выходные документы, содержащие диаграммы проекта в соответствии с запросом проектировщика.

Администратор проекта занимается административными функциями про­ектирования, в числе которых:

• 
  назначение и изменение прав доступа к репозиторию;
  
• 
  мониторинг процесса проектирования.
  

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

Генератор кодов программ на основе моделей проекта, хранящихся в репозиторий, создает код программы.
Принципы CASE-технологий

Существует несколько принципов CASE-технологий. Рассмотрим основные принципы:

1. 
   Принцип всесторонней компьютерной поддержки проектирования. CASE-технология – это разновидность САПРв области создания ИС.
   
2. 
   Принцип модельного подхода – это может быть методология функционально ориентированного подхода или методология объектно-ориентированного подхода.
   

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

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

Методология-Метод-Нотации-Средства

5. 
   Декомпозиция не только модели предметной области, но и самого процесса проектирования на стадии и этапы. Обычно выделяют следующие стадии проектирования: анализ, собственно проекти­рование, программирование (реализация), внедрение. Последовательность стадий и этапов создания ИС на основе CASE-технологии представлена на рис. 2.1. CASE-технология может быть распространена на все стадии жизненного цик­ла ИС.
   
6. 
   Перенесение трудоемкости разработки в большей степени на анализ и проектирование. Известно, что ошибки на последующих стадиях труднее исправить, причем трудности возрастают на порядок. Поэтому CASE-технологии проектирования предусматривают осо­бенно тщательную проработку стадии анализа и проектирования. Здесь строятся модели AS-IS и TO-BE.
   
7. 
   Отделение, независимость стадий проектирования от средств реализации, от программирования. Соблюдение этого принципа позволяет переносить проектные решения с одной программно-тех­нической платформы на другую, т. е. осуществлять миграцию ИС.
   
8. 
   Возможность как прямого, так и обратного проектирования (формирование моделей и спецификаций на основе анализа программных кодов и схем баз данных).
   
9. 
   Использование репозитория – хранилища проектных данных, представляющего собой центральный компонент CASE-средства.
   

Рисунок 2.1 – Последовательность стадий и этапов создания ИС на основе CASE-технологии

Помимо перечисленных принципов в основе построения CASE-средств лежат следующие положения:

1. Человеческий фактор, определяющий разработку ПО как легкий, удобный и экономичный процесс.

2. Широкое использование базовых программных средств, получивших массовое распространение в других приложениях (БД и СУБД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и базы знаний и другое).

3. Автоматизированная или автоматическая кодогенерация, выполняющая несколько видов генерации кодов: преобразования для получения документации, формирования БД, ввода/модификации данных, автоматической сборки модулей из словарей и моделей данных и повторно используемых программ.

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

5. Доступность для разных категорий пользователей.

6. Рентабельность.

7. Сопровождаемость, обеспечивающая способность адаптации при изменении требований и целей проекта.

Факторы эффективности CASE-технологий

Эффективность применения CASE-технологии проектирования ИС проявляется в улучшении качества создаваемого проекта, сокращении стоимостных и временных затрат на всех стадиях ЖЦ ИС (рис. 3.1).

Рассмотрим факторы эффективности CASE-технологии:

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

Рисунок 3.1 – Факторы эффективности CASE-технологии

2. 
   Доступная для понимания пользователей-непрограммистов гра­фическая форма представления модели позволяет следовать принципу пользовательского проектирования, предусматривающему участие пользователей в создании системы. CASE-модель способствует взаимопониманию между всеми участниками создания системы (заказчиками, пользователями, проектировщиками, программистами).
   
3. 
   Наличие формализованной модели системы создает возможность для многовариантного анализа с прототипированием и ориентировочной оценкой эффективности вариантов. CASE-модели позволяют осуществлять функционально-стоимостной анализ (Activity-BasedCosting – ABC) для выявления и исследования стоимости выпол­нения той или иной функции. Анализ прототипа системы позволя­ет скорректировать будущую систему до того, как она будет реали­зована в окончательном виде. Этот подход ускоряет и удешевляет создание системы.
   
4. 
   CASE-технология позволяет использовать концепцию сборочного проектирования, основанную на повторном использовании типовых проектных решений (компонентов) системы. Сборка прикладной программы из готовых компонентов позволяет значительно со­кратить стоимость и время разработки ИС.
   
5. 
   Закрепление в формализованном виде требований к системе избавляет проектировщиков от необходимости многочисленных корректировок в соответствии с новыми требованиями пользова­телей.
   
6. 
   Отделение проектирования системы от программирования со­здает устойчивость проектных решений для реализации на раз­ных программно-технических платформах.
   
7. 
   Наличие формализованной модели реализации системы и соот­ветствующих средств автоматизации позволяет осуществить ав­томатическую кодогенерацию программного обеспечения систе­мы и создать рациональную структуру базы данных.
   
8. 
   На стадии эксплуатации системы появляется возможность внесения изменений на уровне модели, не обращаясь к текстам программ, силами специалистов отдела автоматизации фирмы, т. е. осуществить модификацию проекта.
   
9. 
   Модель системы может использоваться не только как основа, но и в целях автоматизированного обучения персонала с использо­ванием диаграмм.
   
10. 
    На основе модели действующей системы может выполняться биз­нес-анализ для поддержки управленческих решений и бизнес-ре­инжиниринг при изменении направления деятельности фирмы.
    

Аспекты выбора CASE-технологий

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

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

При выборе CASE-системы необходимо учитывать следующие аспекты:

• 
  Наличие базы проектных данных, архива или словаря. СУБД и словари данных обеспечивают высокую степень интеграции данных и предоставляют широкие возможности для центра­лизованного сбора, хранения и распределения проектной ин­формации между различными этапами проекта и выполняе­мыми операциями.
  
• 
  Интерфейсы с другими CASE-системами. В процессе проек­тирования ИС могут использоваться различные методо­логии, поэтому важно, чтобы используемые CASE-системы
  предоставляли возможности для эффективного использо­вания нескольких методов. При этом должна быть обеспе­чена терминологическая совместимость различных методо­логий.
  
• 
  Возможности экспорта/импорта. Спецификации, полученные на этапах анализа, проектирования и кодирования для одной ИС, могут быть использованы для проектирования другой
  системы. Повторное проектирование и кодирование могут быть обеспечены при помощи средств экспорта/импорта спе­цификаций в различные CASE-системы.
  
• 
  Многопользовательский режим. Развитые CASE-системы должны обладать возможностями разделения полномочий пер­сонала разработчиков и объединения отдельных работ в об­щий проект.
  
• 
  Открытая архитектура. Открытая к доступу проектировщи­ков информация об используемых форматах файлов и интер­фейсах должна позволять безболезненно переходить от одной
  CASE-системы к другой.
  
• 
  Расширение новыми методологиями. Как и любое програм­мное средство, CASE-система должна обладать возможнос­тью совершенствоваться с учетом появления новых требова­ний или новых предметных областей.
  
• 
  Наличие графических средств поддержки методологий проек­тирования. Большинство CASE-систем базируется на графи­ческом отображении методологий. Графические элементы
  структурных диаграмм и объекты словаря должны позволять декомпозировать различные компоненты проекта и детали­зировать изображения с той степенью, с какой это необходи­мо для понимания проектных решений.
  
• 
  Обеспечение качества проектной документации. Это требова­ние относится к возможностям CASE-системы анализировать и проверять описания и документацию на полноту и непротиворечивость, а также на соответствие принятым в данной методологии стандартам и правилам. В результате анализа должна формироваться информация, указывающая на имеющиеся противоречия или неполноту проектной документации, находящейся в архиве или словаре.
  
• 
  Автоматическая генерация отчетов о проектных решениях. Решения (спецификации), созданные в процессе проектиро­вания, служат источником документирования системы. Часто возникает потребность получения твердой копии специфи­каций в текстовой или графической форме.
  
• 
  Генерация кодов программ. CASE-системы с жесткой ориента­цией на конкретные СУБД должны обеспечивать возможность генерации программ в среде этих СУБД.
  
• 
  Планирование и управление проектом. Использование CASE-систем не исключает потребности в эффективном управлении проектом. Многие развитые CASE-системы имеют в своем составе средства планирования и управления проектом. Спе­цификации, которые используются этими средствами, пред­ставляют собой опорные точки управления, позволяющие определять сроки разработки.
  

Классификация CASE-средств

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

• 
  локальные CASE-средства, служащие для анализа ИС и разработки автоматизированных рабочих мест (иногда такой подход называют «кусочной» автоматизацией), поддерживающие один-два типа моделей и методов. Примерами таких CASE-средств являются: Design/IDEF, CASE, Аналитик;
  
• 
  малые интегрированные CASE-средства, используемые для созда­ния небольших интегрированных ИС и поддерживающие несколь­ко типов моделей и методов. В эту категорию попадают: AllFusionErwinDataModeler(прежнее название Erwin), AllFusionModelManager(прежнее название Bpwin), Silverrun;
  
• 
  средние интегрированные CASE-средства, поддерживающие от 4 до 10-15 типов моделей и методов. К данному типу следует отнести: RationalRose, Designer/2000.
  

Помимо приведенной выше классификации возможны и другие клас­сификации, например по следующим признакам:

• 
  по поддерживаемым методологиям проектирования: функ­ционально (структурно)-ориентированные, объектно-ориентиро­ванные и комплексно-ориентированные (набор методологий про­ектирования);
  
• 
  по поддерживаемым графическим нотациям построения ди­аграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;
  
• 
  по степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватыва­ющих большинство этапов разработки ИС) и workbench (пол­ностью интегрированные средства, связанные общей базой про­ектных данных – репозиторием);
  
• 
  по типу и архитектуре вычислительной техники: ориенти­рованные на ПЭВМ, ориентированные на локальную вычисли­тельную сеть (ЛВС), ориентированные на глобальную вычисли­
  тельную сеть (ГВС) и смешанного типа;
  
• 
  по режиму коллективной разработки проекта: не поддер­живающие коллективную разработку, ориентированные на ре­жим реального времени разработки проекта, ориентированные на режим объединения подпроектов;
  
• 
  по типу операционной системы: работающие под уп­равлением WINDOWS; работающие под управле­нием UNIX и работающие под управлением различных ОС
  (WINDOWS, UNIX, OS/2 и др.).
  

В разряд CASE-систем попадают как относительно дешевые системы для ПК с ограниченными воз­можностями (такие, как редакторы диаграмм), так и дорогостоя­щие системы для больших ЭВМ.

Современные CASE-системы охватывают обширную область поддержки различных технологий проектирования и программи­рования: от простых средств анализа и документирования ИС до полномасштабных средств автоматизации, покрывающих весь ЖЦ ИС.

Помимо поддержки начальных этапов разработки, важное значение приобретают CASE-системы, ориентированные на про­ектирование и генерацию БД и пользовательских интер­фейсов.

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

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

RAD-технология (RapidApplicationDevelopment) – это технология бы­строго создания приложений на основе прототипирования и использо­вания графического пользовательского интерфейса GUI (GraphicalUserInterface).

RAD-технология не в состоянии обеспечивать разработку сложных продуктов, содержащих много фрагментов, программирование кото­рых занимает более двух недель. Эта технология ориентирована ско­рее на разработку достаточно простого заказного программного обес­печения, чем на индустриальное проектирование ИС.

Решения почти всех проблем, связанных с разработкой небольших ИС, достигаются с применением признанной во всем мире RAD-технологии. Она заключается в том, что организуется так называемая RAD-группа из 6-7 человек, состоящая из руководите­ля, системного аналитика и 4-5 программистов, которым даются четкие планы на весь период разработки проекта со сроками от 1 до 2 недель.

Основой этой технологии является спиральная модель создания ИС (рис. 6.1). Как видно на рисунке, разработка идет по спирали, проходя не­однократно все 4 стадии разработки ИС.



Рисунок 6.1 – Спиральная модель проектирования на основе RAD-технологии

На стадии анализа пользователи осуществляют следующие действия:

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

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

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

После детального определения состава процессов оценивается количество так называемых функциональных точек (function point) разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработ­чиков за приемлемое для RAD-проектов время (до 3 месяцев).

Функциональная точка – этолюбой из элемен­тов разрабатываемой системы:

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

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

В случае использования CASE-средств это означает деление функциональной модели системы (ди­аграммы потоков данных для структурного подхода или диаграммы вариантов использования для объектно-ориентированно­го подхода.

Результатом данной стадии должны быть:

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

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

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

На стадии реализации выполняется непосредственно сама быст­рая разработка приложения:

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

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

• 
  осуществляется анализ использования данных и определяется не­обходимость их распределения;
  
• 
  производится физическое проектирование базы данных;
  
• 
  формулируются требования к аппаратным ресурсам;
  
• 
  устанавливаются способы увеличения производительности;
  
• 
  завершается разработка документации проекта.
  

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

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

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

• 
  разрабатывается совершенно новая система;
  
• 
  уже было проведено обследование организации и существует мо­дель ее деятельности;
  
• 
  в организации уже существует некоторая ИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой системой.
  

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

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

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

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

• 
  менее 1 тыс. функциональных точек – один человек;
  
• 
  от 1 до 4 тыс. функциональных точек – одна команда разработ­чиков;
  
• 
  более 4 тыс. функциональных точек – одна команда разработчи­ков на 4 тыс. функциональных точек.
  

Итак, перечислим основные принципы подхода RAD:

• 
  разработка приложений итерациями;
  
• 
  необязательность полного завершения работ на каждой стадии ЖЦ ИС;
  
• 
  обязательность вовлечения пользователей в процесс разработки ИС;
  
• 
  целесообразность применения CASE-средств, обеспечивающих целостность проекта и генерацию кода приложений;
  
• 
  целесообразность применения средств управления конфигураци­ей, облегчающих внесение изменений в проект и сопровождение готовой системы;
  
• 
  использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности пользователей;
  
• 
  тестирование и развитие проекта, осуществляемые одновремен­но с разработкой;
  
• 
  ведение разработки немногочисленной хорошо управляемой ко­мандой профессионалов;
  
• 
  грамотное руководство разработкой системы, четкое планирова­ние и контроль выполнения работ.
  

Письменно ответить на вопросы:

1. 
   Понятие CASE-технологии.
   
2. 
   Принципы и положения CASE-технологий.
   
3. 
   Факторы эффективности CASE-технологий. Описать и
   
4. 
   Аспекты выбора CASE-технологий.
   
5. 
   Классификация CASE-средств.
   
6. 
   RAD-технология прототипного создания приложений.