«система». Лекция автоматизированные экономические информационные системы

• Название: Лекция автоматизированные экономические информационные системы
• Дата: 11.10.2019
• Размер: 0.87 Mb.
• Имя файла: «система».doc
• Тип: Лекция; #89613
• страница: 18 из 18

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

Общая характеристика и классификация CASE-средств.

В области автоматизации проектирования АЭИС за последнее десятилетие сформировалось новое направление – CASE (Computer-Aided Software/System Engineering). Лавинообразное расширение областей применения вычислительной техники, возрастающая сложность информационных систем, повышающиеся к ним требования привели к необходимости индустриализации технологий их создания. Важное направление в развитии технологий составили разработки интегрированных инструментальных средств, базирующихся на концепции жизненного цикла и управления качеством АИС. Дальнейшее развитие работ в этом направлении привело к созданию ряда концептуально целостных, оснащенных высокоуровневыми средствами проектирования и реализации вариантов, доведенных по качеству и легкости тиражирования до уровня программных продуктов технологических систем, которые получили название CASE-систем или CASE-технологий.

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

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

Помимо принципов графической ориентации, интеграции и локализации всей проектной информации в репозитарии в основе построения CASE-средств лежат следующие положения:

1. 
   Человеческий фактор, определяющий разработку ПО как легкий, удобный и экономичный процесс.
   
2. 
   Широкое использование базовых программных средств, получивших массовое распространение в других приложениях (БД и СУБД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и базы знаний и др).
   
3. 
   Автоматизированная или автоматическая кодогенерация, выполняющая несколько видов генерации кодов: преобразования для получения документации, формирования БД, ввода/модификации данных, автоматической сборки модулей из словарей и моделей данных и повторно используемых программ.
   
4. 
   Ограничение сложности, позволяющее получать компоненты, поддающиеся управлению, обозримые и доступные для понимания, а также обладающие простой и ясной структурой.
   
5. 
   Доступность для разных категорий пользователей.
   
6. 
   Рентабельность.
   
7. 
   Сопровождаемость, обеспечивающая способность адаптации при изменении требований и целей проекта.
   

В табл. 1 приведены основные изменения жизненного цикла приложения при использовании CASE-технологий по сравнению с традиционной технологией разработки.

Таблица 1

Традиционная технология разработки	Разработка с помощью CASE-технологии
Основные усилия - на кодирование и тестирование	Основные усилия - на анализ и проектирование
"Бумажные" спецификации	Быстрое итеративное макетирование
Ручное кодирование	Автоматическая генерация машинного кода
Тестирование ПО	Автоматический контроль проекта
Сопровождение программного кода	Сопровождение проекта

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

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

В табл. 2 приведены оценки трудозатрат по фазам жизненного цикла приложения.

Таблица 2

Технологии / Этапы	Анализ	Проектирование	Разработка	Тестирование
Традиционная технология разработки	20%	15%	20%	45%
Разработка с использованием структурных методологий вручную	30%	30%	15%	25%
Разработка с использованием CASE-технологий	40%	40%	5%	15%

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

Интегрированный CASE-пакет содержит четыре основных компонента:

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

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

2. Графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС, их описание и анализ.

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

4. Средства документирования, управления проектом и реинжиниринга.

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям.

Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

• 
  средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Computer Associates)));
  
• 
  средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
  
• 
  средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
  
• 
  средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;
  
• 
  средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).
  

Вспомогательные типы включают:

• 
  средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
  
• 
  средства конфигурационного управления (PVCS (Intersolv));
  
• 
  средства тестирования (Quality Works (Segue Software));
  
• 
  средства документирования (SoDA (Rational Software)).
  

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

• 
  Vantage Team Builder (Westmount I-CASE);
  
• 
  Designer/2000;
  
• 
  Silverrun;
  
• 
  ERwin+BPwin;
  
• 
  S-Designor;
  
• 
  CASE.Аналитик.
  

Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы (например, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так и новые версии и модификации перечисленных систем.

Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает:

• 
  отдельные локальные средства, решающие небольшие автономные задачи (tools);
  
• 
  набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit);
  
• 
  полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием.
  

Помимо этого, CASE-средства можно классифицировать по следующим признакам:

• 
  применяемым методологиям и моделям систем и БД;
  
• 
  степени интегрированности с СУБД;
  
• 
  доступным платформам.
  

Технология внедрения CASE-средств

Технология внедрения CASE-средств базируется в основном на стандартах IEEE (Institute of Electrical and Electronics Engineers - Институт инженеров по электротехнике и электронике). Термин «внедрение» используется в широком смысле и включает все действия от оценки первоначальных потребностей до полномасштабного использования CASE-средств в различных подразделениях организации-пользователя. Процесс внедрения CASE-средств состоит из следующих этапов:

• 
  определение потребностей в CASE-средствах;
  
• 
  оценка и выбор CASE-средств;
  
• 
  выполнение пилотного проекта;
  
• 
  практическое внедрение CASE-средств.
  

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

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

Определение потребностей в CASE-средствах

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



Рис. 4.1. Определение потребностей в CASE-средствах

4.1.1. Анализ возможностей организации

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

Формальные подходы определяются моделью оценки зрелости технологических процессов организации CMM (Capability Maturity Model), разработанной SEI (Software Engineering Institute), а также стандартами ISO 9001: 1994, ISO 9003-3: 1991 и ISO 9004-2:1991. В центре внимания этих подходов находится анализ различных аспектов происходящих в организации процессов.

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

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

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

Общие вопросы

• 
  используемая модель ЖЦ (каскадная или спиральная);
  
• 
  используемые методы (структурные, объектно-ориентированные). Степень адаптации метода к потребностям организации; квалификация сотрудников;
  
• 
  наличие документированных стандартов (формальных или неформальных) по анализу требований, спецификациям и проектированию, кодированию и тестированию;
  
• 
  количественные метрики, используемые в процессе разработки ПО, их использование;
  
• 
  виды документации, выпускаемой в процессе ЖЦ ПО;
  
• 
  наличие группы поддержки средств проектирования.
  

Проекты, ведущиеся в организации

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

Технологическая база

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

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

Персонал

Главной целью оценки персонала является определение его отношения к возможным изменениям (позитивного, нейтрального или негативного). Вопросы, касающиеся оценки персонала, включают следующие:

• 
  реакция сотрудников организации (как отдельных людей, так и коллективов) на внедрение новой технологии. Наличие опыта успешных или безуспешных внедрений;
  
• 
  наличие лидеров, способных серьезно повлиять на отношение к новым средствам;
  
• 
  наличие стремления "снизу" к совершенствованию средств и технологии;
  
• 
  объем обучения, необходимого для ориентации пользователей в новой технологии;
  
• 
  стабильность и уровень текучести кадров.
  

Готовность

Целью оценки готовности организации является определение того, насколько она способна воспринять как немедленные, так и долгосрочные последствия внедрения CASE-средств. Вопросы, касающиеся оценки готовности, включают следующие:

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

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

4.1.2. Определение организационных потребностей

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

Цели организации

Цели организации играют главную роль в определении ее конкретных потребностей и ожидаемых результатов. Для их понимания необходимо ответить на следующие вопросы:

• 
  намерение организации использовать CASE-технологию для помощи в достижении определенных целей или ожиданий (например, определенного уровня CMM или сертификации в соответствии с ISO 9001);
  
• 
  восприятие CASE-технологии как фактора, способствующего достижению стратегических целей организации;
  
• 
  наличие у организации собственной программы совершенствования процесса разработки ПО;
  
• 
  восприятие инициативы внедрения CASE-технологии как части более широкомасштабного проекта по созданию среды разработки ПО.
  

Потребности организации

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

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

Определению потребностей организации могут помочь ответы на следующие вопросы:

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

Ожидаемые результаты

С внедрением CASE-средств обычно связывают большие ожидания. В ряде случаев эти ожидания оказываются нереалистичными и приводят к неудаче при внедрении.

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

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

Реалистичные ожидания:

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

Нереалистичные ожидания:

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

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

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

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

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

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

4.1.3. Анализ рынка CASE-средств

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

4.1.4. Определение критериев успешного внедрения

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

Как правило, большинство организаций осуществляет внедрение CASE-средств для того, чтобы повысить продуктивность процессов разработки и сопровождения ПО, а также качество результатов разработки. Однако, ряд организаций не занимаются и не занимались ранее сбором количественных данных по указанным параметрам. Отсутствие таких данных затрудняет количественную оценку воздействия, оказываемого внедрением CASE-средств. В этом случае рекомендуется разработка соответствующих метрик. Информация о таких метриках приведена в стандартах IEEE Std 1045-1992 (IEEE Standard for Software Productivity Metrics) и IEEE Std 1061-1992 (IEEE Standard for a Software Quality Metrics Methodology).

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

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

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

4.1.5. Разработка стратегии внедрения CASE-средств

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

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

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

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

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

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

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

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

Недостатки данного подхода заключаются в следующем:

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

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

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

Преимущества данного подхода заключаются в следующем:

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

Недостатки данного подхода заключаются в следующем:

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

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

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


ЛЕКЦИЯ 4.

СОВРЕМЕННЫЕ МЕТОДОЛОГИИ ПРОЕКТИРОВАНИЯ ПРИЛОЖЕНИЙ.

На современном этапе развития существуют два подхода к проектированию и построению приложений: методология структурного анализа и методология объектно-ориентированного подхода.

Методологии структурные анализа и проектирования основаны на модели ВХОД-ОБРАБОТКА-ВЫХОД: данные входят в систему, обрабатываются или преобразуются и выходят из системы. При этом важен порядок построения модели. Процедурно-ориентированный подход регламентирует первичность проектирования функциональных компонентов по отношению к проектированию структур данных. При информационно-ориентированном подходе вход и выход являются наиболее важными - структуры данных определяются первыми, а процедурные компоненты являются производными от данных.

Одной из структурных методологий, основанных на информационно-ориентированном подходе, является информационная инженерия.

Информационная инженерия

Информационная инженерия вращается вокруг двух основных концепций.

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

2. Направленность на моделирование данных, а затем - на функциональное моделирование.

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

В информационной инженерии конкретные решения этих проблем начинаются с разработки плана некоторой информационной системы (Information System Plan - ISP), как указано на рисунке 1 (модель информационной инженерии).


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

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

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

Далее, выбираются отдельные приложения для проектирования деловой системы (Business System Design - BSD) и ее последующего конструирования (Business System Construction - BSC). Фактически информационная инженерия затем переходит к предписанным отдельным, более многочисленным, стадиям для завершения управляемого методологией процесса, включающего подходы для тестирования, выпуска продукции и сопровождения приложений.

Таким образом, ядром информационной инженерии является обоснованный набор шагов для планирования и построения по методу сверху вниз. Информационная инженерия также предписывает набор моделей и стратегий проектирования для моделирования приложений.

Недостатки моделирования данных

1. На общем уровне БД и модель данных рассматриваются как центральные понятия в планировании и проектировании приложений.

2. Фактические вычисления, работа пользователя и правила бизнеса рассматриваются как некоторое дополнение к БД исходя из ориентированных на задачи перспектив.

Но этот подход имел несколько недостатков:

1. Разработка полной корпоративной модели данных дорогая и сложная. Многие организации решились построить такие модели, но после заполнения 30 или 40 томов документации за период в 2 - 3 года они пришли к заключению, что могут никогда не закончить эту работу.

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

3. Основательная модель данных является важной, но далеко не достаточной.

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

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

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

Стадии проектирования приложений

	Концептуальная	Логическая	Физическая
Документы	Поток работ	Поток форм	Формы
Правила бизнеса	Поток процессов	Модель компонентов	Программы
База данных	Модель данных	Схема БД	Таблицы, индексы

Рассмотрим более детально эти стадии.

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

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

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

Таким образом, при последовательном прохождении всех трех стадий проектирования ищутся ответы на вопросы о будущем приложении клиент/сервер.

Концептуальная модель отвечает на три вопроса: Как будет выглядеть новое приложение? Как изменится данный бизнес? Как будут отображены требования к новым процессам бизнеса?

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

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

Теперь рассмотрим три вида моделей, которые соответствуют трем слоям архитектуры приложений.

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

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

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

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