Logo GenDocs.ru

Поиск по сайту:  


Загрузка...

CASE-технологии - файл 1.doc


CASE-технологии
скачать (211 kb.)

Доступные файлы (1):

1.doc211kb.16.11.2011 10:48скачать

содержание
Загрузка...

1.doc

Реклама MarketGid:
Загрузка...
Содержание

Введение 3

1. CASE-средство: определение и общая характеристика 5

2. Применение CASE-технологий: преимущества и недостатки 9

3. Внедрение CASE-технологий 12

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

3.2. Оценка и выбор CASE-средств 17

3.3. Выполнение пилотного проекта 20

3.4. Практическое внедрение CASE-средств 25

  1. Пример практического применения целостной

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

Заключение 40

Список литературы 42


Введение

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

  • подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;

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

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

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

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

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


^ 1. CASE-средства: определение и общая характеристика.

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

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

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

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

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

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

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

  3. использование специальным образом организованного хранилища проектных метаданных (репозитория). [10]

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты:

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

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

  • средства разработки приложений, включая языки 4GL и генераторы кодов;

  • средства конфигурационного управления;

  • средства документирования;

  • средства тестирования;

  • средства управления проектом;

  • средства реинжиниринга. [14]

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:

  • применяемым методологиям и моделям систем и БД;

  • степени интегрированности с СУБД;

  • доступным платформам.

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

  • средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

  • средства анализа и проектирования (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)). [4]



^ 2. Применение CASE-технологий: преимущества и недостатки.

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

  • CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

  • реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

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

  • широкое разнообразие качества и возможностей CASE-средств;

  • относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

  • широкое разнообразие в практике внедрения различных организаций;

  • отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

  • широкий диапазон предметных областей проектов;

  • различная степень интеграции CASE-средств в различных проектах.

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

  • Технология: понимание ограниченности существующих возможностей и способность принять новую технологию;

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

  • Управление: четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения. [10]

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

  • высокий уровень технологической поддержки процессов разработки и сопровождения ПО;

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

  • приемлемый уровень отдачи от инвестиций в CASE-средства.

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

  • методология (MethodDiagrams), которая задает единый графический язык и правила работы с ним.

  • графические редакторы (GraphicEditors), которые помогают рисовать диаграммы; возникли с распространением PC и GUI, так называемых «uppercase технологий

  • генератор: по графическому представлению модели можно сгенерировать исходный код для различных платформ (так называемая lowcase часть CASE-технологии).

  • репозиторий, своеобразная база данных для хранения результатов работы программистов. [11]



^ 3. Внедрение CASE-технологий.

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

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

  • оценка и выбор CASE-средств;

  • выполнение пилотного проекта;

  • практическое внедрение CASE-средств. [6]

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

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

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

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


Анализ возможностей

организации и ее готовности к внедрению

CASE-средств






Определение

организационных

потребностей

Обзор рынка

CASE-средств






Определение критериев

успешного внедрения







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

CASE-средств


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

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


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

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

Для получения информации относительно положения и потребностей организации могут использоваться неформальные оценки и анкетирование.
^

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


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

Цели организации играют главную роль в определении ее конкретных потребностей и ожидаемых результатов. [7]

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

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

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


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

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

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

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

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

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

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

  • организационные потребности;

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

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

  • подразделения организации, в которых должно выполняться внедрение CASE-средств;

  • влияние, оказываемое на другие подразделения организации;

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

  • основные факторы риска;

  • ориентировочный уровень расходов и источники финансирования процесса внедрения CASE-средств;

  • ключевой персонал и другие ресурсы. [12]

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

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

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

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

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

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

^ 3.2. Оценка и выбор CASE-средств

Модель процесса оценки и выбора [17], рассматриваемая ниже (рисунок 2), описывает наиболее общую ситуацию оценки и выбора, а также показывает зависимость между ними. Как можно видеть, оценка и выбор могут выполняться независимо друг от друга или вместе, каждый из этих процессов требует применения определенных критериев.

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

  • оценка нескольких CASE-средств и выбор одного или более из них;

  • оценка одного или более CASE-средств и сохранение результатов для последующего использования;

  • выбор одного или более CASE-средств с использованием результатов предыдущих оценок. [9]


Пользовательские

потребности

Цели, предположения


Уточнение

критериев
и ограничения

Список

критериев Потребность в

дополнительной

информации

Уточненный

список критериев

Оценка

CASE-средств

Доступные

CASE-средства



Выбор

CASE-средств

Результаты

оценки




Рекомендуемое

решение


Рис.2. Модель процесса оценки и выбора

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

Процесс оценки включает следующие действия:

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

  • определение критериев оценки, вытекающее из определения задачи;

  • определение средств-кандидатов путем просмотра списка кандидатов и анализа информации о конкретных средствах;

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

  • подготовка отчета по результатам оценки. [5]

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

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

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

  1. Поддержка полного жизненного цикла ИС с обеспечением эволюционности ее развития

  2. Обеспечение целостности проекта и контроля за его состоянием.

  3. Независимость от программно-аппаратной платформы и СУБД

  4. Поддержка одновременной работы групп разработчиков

  5. Возможность разработки приложений "клиент-сервер" требуемой конфигурации

  6. Открытая архитектура и возможности экспорта/импорта

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

  8. Простота освоения и использования

  9. Обеспечение качества проектной документации

  10. Использование общепринятых, стандартных нотаций и соглашений.

В результате выполненного анализа может оказаться, что ни одно доступное средство не удовлетворяет в нужной мере всем основным критериям и не покрывает все потребности проекта. В этом случае может применяться набор средств, позволяющий построить на их базе единую технологическую среду. [9]
    1. ^

      Выполнение пилотного проекта


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

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

  • подтвердить достоверность результатов оценки и выбора;

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

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

  • приобрести собственный опыт использования CASE-средства. [4]

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

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

Определение характеристик

пилотного проекта






Планирование

пилотного проекта



Выполнение

пилотного проекта



Оценка

пилотного проекта







Отказ от внедрения

Выполнение

дополнительного

пилотного проекта


Внедрение средства


Рис.3. Шаги пилотного проекта

Пилотный проект должен обладать следующими характеристиками:

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

  • Масштабируемость. Результаты, полученные в пилотном проекте, должны показать масштабируемость средства. Цель - получить четкое представление о масштабах проектов, для которых данное средство применимо.

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

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

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

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

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

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

В процессе оценки пилотного проекта организация должна определить свою позицию по следующим трем вопросам:

  • Целесообразно ли внедрять CASE-средство?

  • Какие конкретные особенности пилотного проекта привели к его успеху (или неудаче)?

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

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

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

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

Возможным решением должно быть одно из следующих:

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

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

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

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

Результатом данного этапа является документ, в котором обсуждаются результаты пилотного проекта и детализируются решения по внедрению.
    1. ^

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


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

План перехода должен включать следующее:

  • Информацию относительно целей, критериев оценки, графика и возможных рисков, связанных с реализацией плана.

  • Информацию относительно приобретения, установки и настройки CASE-средств.

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

  • Ожидаемые потребности в обучении и ресурсы, используемые в течение и после завершения процесса перехода.

  • Определение стандартных процедур использования средств.

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

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

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

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

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

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

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

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

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

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

  • Определения степени совершенствования процессов,

  • Упреждения возможных стратегических просчетов,

  • Своевременного отказа от использования устаревшей технологии.

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

  • Использованное время,

  • Время, выделенное персонально для конкретных специалистов,

  • Размер, сложность и качество ПО,

  • Удобство сопровождения.

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

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



  1. ^ Пример практического применения целостной CASE-технологии построения информационных систем

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

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

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

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

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

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

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

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

Для модели команды:

Microsoft Solution Framework (MSF).

Для модели процесса:

Unified Modeling Language (UML);

Object Modeling Technique (OMT);

Microsoft Solution Framework (MSF);

Rational Unified Process (RUP);

Objectory.

Для модели приложения:

Distributed Component Object Model (DCOM/COM+);

Microsoft Solution Framework (MSF);

Structured Query Language (SQL).

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

CASE-технология ИВС STORM2000 включает в себя все аспекты процесса производства информационных систем, а именно она позволяет:

  • автоматизировать создание ИС, наладить их производство;

  • эффективно задействовать команду разработчиков заказных ИС или отдел АСУ предприятия;

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


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

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

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

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

1)Модель команды

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


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


Сторона качества




Сторона заказчика Сторона разработчика


Рис. 4. Модель команды


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

Не вдаваясь в детали, заострим внимание на том, что команда определяется тремя независимыми сторонами (людьми или группами людей):

  • стороной заказчика;

  • стороной разработчика;

  • стороной качества.

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

Модель процесса

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

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

Укрупненно, процесс включает следующие этапы:

  • анализ системы «как есть»;

  • анализ системы «как требуется»;

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

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

  • реализация бизнес-логики системы;

  • тестирование системы;

  • сборка дистрибутива системы;

  • развертывание.

Основное внимание уделяется этапу анализа. Это очевидно: поскольку система должна автоматизировать предмет, ее необходимо предметно спроектировать. Аналитик создает модель системы в терминах предметной области. Используется язык UML, методология OMT и промышленная CASE-среда Telelogic Tau UML Suite.

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

Этапы анализа и объектного дизайна — самые продолжительные по времени. Генерация кода является самым коротким этапом. Экспериментально установлено, что на реальной системе (например, управление торговлей) методом генерации можно получить примерно 85% всего кода. Хотя это не определяет полностью реальную сложность и трудоемкость доработки системы, но характеризует, сколько времени разработчика экономит технология за счет стандарта на приложение. Генерируется код COM-компонентов для Microsoft Visual Basic и сценарии создания БД для СУБД Microsoft SQL Server или Oracle. Отметим, что генерируется код для всех уровней приложений ИС. Архитектура приложений задается моделью приложения, о которой речь пойдет ниже.

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

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

Следует заметить, что между этапами «Анализ системы ?как есть?» и «Анализ системы ?как требуется?» можно провести реинжиниринг бизнес-процессов, поручив этот этап консалтинговой компании и передав ей модель ИС в виде документов, содержащих текстовые описания, диаграммы UML, прототип системы.

Разумеется, наличие модели процесса повышает качество ИС.

Модель приложения

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

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

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

В результате применения этого стандарта прикладные ИС, создаваемые по CASE-технологии STORM2000, автоматически обладают следующими характеристиками:

  • Многопользовательская система.

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

  • Встроенные подсистемы полномочий (оперируют на уровне бизнес-объектов, то есть так, как нарисовано в CASE на диаграммах, а не на уровне СУБД или компонентной технологии), пользовательских настроек (обеспечивается независимость от рабочей станции), фильтров и отчетов (интегрировано с MS Office), удаленная установка и обновление рабочих мест, единая административная консоль.

  • Трехуровневая распределенная компонентная архитектура, включающая уровни хранения данных, бизнес-логики и представления. Система может быть реализована как в классической архитектуре с обычным клиентом, так и в архитектуре c Web-клиентом.

  • Управление транзакциями на уровне бизнес-сервера.

  • Многопоточное выполнение операций (не блокирующее конкретный экземпляр клиентского приложения).

  • Открытая система.

Компонентный подход, основанный на стандарте Microsoft DCOM/COM+, который используется при построении систем, позволяет независимо работать с компонентами, прозрачно заменять и повторно их использовать, распределять эффективно загрузку каждого слоя системы.

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

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

Преимущества от использования единой архитектуры приложения очевидны. Это:

  • одинаковая софтверная архитектура различных по предметной природе информационных систем;

  • легкость обучения пользователей;

  • одинаковое администрирование;

  • единые принципы разработки разных по предмету систем;

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

  • сокращение совокупной стоимости владения.

Кроме использования выстроенного комплекса стандартов в рамках компании «ИВС», ее вполне можно применять вне одной компании. CASE-технология STORM2000 ориентирована на использование:

  • ИТ-подразделениями предприятий и корпораций, ведущих крупные проекты построения ИС;

  • ИТ-компанией для построения заказных ИС.

Стремление или необходимость передавать технологию «внешним» заказчикам, отчуждать ее от себя влечет за собой необходимость наличия методики внедрения STORM2000. Такая методика имеется и включает следующие основные этапы внедрения технологии на предприятии:

  • подбор команды;

  • обучение команды;

  • совместный с ИВС пилотный проект построения «легко обозримой» системы;

  • дальнейший консалтинг и техническую поддержку.

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

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

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

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

Сегодня на базе CASE-технологии STORM2000 разработаны, разрабатываются, развиваются системы на следующих, предприятиях:

  • ОАО «Пермэнерго» (снабжение);

  • ОАО «Пермагроснаб» (торговля, бухучет, лизинговые операции);

  • ООО «ЛУКОЙЛ-Пермнефтеоргсинтез» (снабжение; бюджетирование);

  • ЗАО «ИВС-Сети» (торговля, производство, бухучет);

  • Департамент образования и науки Пермской области (система мониторинга образования);

  • ОАО «Пермский мукомольный завод» (бухучет, снабжение, сбыт, производство, ремонт, бюджетирование).

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

Положительные стороны:

  • высокая технологичность и автоматизация производства ИС (отсюда высокое качество систем, низкая стоимость);

  • высокое качество ведения проектов (отсюда укладывание в сроки, высокое качество процесса и систем, занятость персонала);

  • низкая совокупная стоимость владения ИС.

Отрицательные стороны:

  • повышение уровня требований к квалификации кадрового состава предприятия;

  • непонимание заказчиком диаграммных моделей;

  • «психологическая ломка» для разработчиков этого предприятия. [15]



Заключение

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

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

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

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

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

    • использование специальным образом организованного хранилища проектных метаданных (репозитория).

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


Список литературы

    1. Банк В.С., Зверев В.С. Информационные технологии в экономике, - М.: Экономистъ, 2008;

    2. Буч Г. Объектно-ориентированное проектирование с примерами применения. М., Конкорд, 2007;

    3. Грабауров В.А. Информационные технологии для менеджеров. - М.: Юнити, 2007;

    4. Зиндер Е.З. Бизнес-реинжиниринг и технологии системного проектирования. Учебное пособие. М.: Центр Информационных Технологий, 2007;

    5. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). М.: Лори, 2009:

    6. Климова Р.Н., Сорокина М.В., Хахаев И.А., Мошенский С.А. Информатика торговой фирмы. Учебное пособие. Для студентов всех специальностей всех форм обучения. - СПб.: СПбТЭИ, 2008;

    7. Компьютерные технологии обработки информации. Под ред. Назарова С.И. - М.: Финансы и статистика, 2007;

    8. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. М.: МетаТехнология, 2007;

    9. Международные стандарты, поддерживающие жизненный цикл программных средств. М.: МП «Экономика», 2008;

    10. Новоженов Ю.В. Объектно-ориентированные технологии разработки сложных программных систем. М.: Приор, 2007.

    11. Симионов Ю.Ф. Информационные технологии в экономике. - М.: Кнорус, 2009;

    12. Советов Я.Б. Информационные технологии: учебник для вузов. - М.: Ника-центр, 2007;

    13. Титоренко Г.А. Информационные технологии управления. - М.: Экономистъ, 2008;

    14. Фридланд А. Информатика - толковый словарь основных терминов. – М.:, Приор, 2007;

    15. Шафрин Ю. Информационные технологии, - М.: ООО «Лаборатория базовых знаний», 2008;

    16. www.osp.ru.





Скачать файл (211 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации
Рейтинг@Mail.ru