Технологии разработки программных систем на основе CASE средств

Автор работы: Пользователь скрыл имя, 24 Ноября 2011 в 11:21, реферат

Описание

Цель моего реферата – рассмотреть технологии разработки программных систем на основе CASE средств. В 70-х и 80-х годах при разработке ИС достаточно широко применялась структурная методология, предоставляющая в распоряжение разработчиков строгие формализованные методы описания ИС и принимаемых технических решений. На протяжении всей истории программирования программные проекты все более и более усложнялись, объем работ стремительно увеличивался, возникла потребность в универсальных средствах, которые могли бы помочь как-то структурировать создание ПО.

Работа состоит из  1 файл

Мой готовый реферат.docx

— 58.46 Кб (Скачать документ)

    3 Внедрение CASE-средств

     Процесс внедрения состоит из следующих  этапов:

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

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

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

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

     Определение потребностей в CASE-средствах можно  проиллюстрировать следующей диаграммой (см. рис. 1).

    

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

     Процесс оценки и выбора CASE-средств можно  рассмотреть в виде модели. Этот процесс может преследовать несколько целей и включать:

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

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

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

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

    

     Как видно из рисунка, входной информацией  для процесса оценки является:

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

     • цели и ограничения проекта;

     • данные о доступных CASE-средствах;

     • список критериев, используемых в процессе оценки.

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

     Элементы  процесса включают:

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

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

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

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

     • рекомендуемое решение (обычно либо решение о выборе, либо дальнейшая оценка).

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

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

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

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

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

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

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

    

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

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

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

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

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

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

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

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

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

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

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

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

     4 Примеры CASE-средств и их характеристики

     4.1 Silverrun

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

     4.2 JAM

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

  • Ядро системы;
  • JAM/DBi - специализированные модули интерфейса к СУБД (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC и т.д.);
  • JAM/RW - модуль генератора отчетов;
  • JAM/CASEi - специализированные модули интерфейса к CASE-средствам (JAM/CASE-TeamWork, JAM/CASE-Innovator и т.д.);
  • JAM/TPi - специализированные модули интерфейса к менеджерам транзакций (например, JAM/TPi-Server TUXEDO и т.д.);
  • Jterm - специализированный эмулятор X-терминала.

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

     4.3 Vantage Team Builder

     Vantage Team Builder представляет собой интегрированный  программный продукт, ориентированный  на реализацию каскадной модели  ЖЦ ПО и поддержку полного ЖЦ ПО. Наличие универсальной системы генерации кода, основанной на специфицированных средствах доступа к репозиторию проекта, позволяет поддерживать высокий уровень исполнения проектной дисциплины разработчиками: жесткий порядок формирования моделей; жесткая структура и содержимое документации; автоматическая генерация исходных кодов программ и т.д. - все это обеспечивает повышение качества и надежности разрабатываемых ИС.

     4.4 Локальные средства (ERwin, BPwin, S-Designor)

     ERwin - средство концептуального моделирования  БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД и реинжиниринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений. 

     BPwin - средство функционального моделирования,  реализующее методологию IDEF0. S-Designor представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству ERwin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др.   

     4.5 Объектно-ориентированные  CASE-средства (Rational Rose)

     Rational Rose - CASE-средство фирмы Rational Software Corporation - предназначено для автоматизации  этапов анализа и проектирования  ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

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

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

     Для решения задач КУ применяются методы и средства обеспечивающие идентификацию состояния компонент, учет номенклатуры всех компонент и модификаций системы в целом, контроль за вносимыми изменениями в компоненты, структуру системы и ее функции, а также координированное управление развитием функций и улучшением характеристик системы. Наиболее распространенным средством КУ является PVCS фирмы Intersolv (США), включающее ряд самостоятельных продуктов: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder и PVCS Notify.

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