Главная страница
Навигация по странице:

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

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

  • Учебноисследовательская лаборатория Математические и программные технологии для современных


    Скачать 0.86 Mb.
    НазваниеУчебноисследовательская лаборатория Математические и программные технологии для современных
    Дата08.03.2023
    Размер0.86 Mb.
    Формат файлаpdf
    Имя файлаConspect.pdf
    ТипАнализ
    #975312
    страница1 из 5
      1   2   3   4   5

    Нижегородский государственный университет им. Н.И. Лобачевского
    Факультет вычислительной математики и кибернетики ННГУ
    Учебно-исследовательская лаборатория
    «Математические и программные технологии для современных
    компьютерных систем (Информационные технологии)»
    Инструментальные средства поддержки
    жизненного цикла программного обеспечения
    Куратор мини-проекта:
    Сысоев А.В.
    Составители:
    Стариков В.
    Зеленцова М.

    Содержание
    1
    CASE-средства. Общая характеристика и классификация..................................................... 3 2
    Методологии и технологии проектирования ИС .................................................................... 5 2.1
    Общие требования к методологии и технологии ............................................................ 5 3
    Методология RAD ...................................................................................................................... 6 4
    Сущность структурного подхода.............................................................................................. 9 4.1
    Методология функционального моделирования SADT ............................................... 10 4.2
    Моделирование потоков данных (процессов) ............................................................... 16 4.3 Case-метод Баркера.................................................................................................. 20 5
    Технология внедрения CASE-средств.................................................................................... 25 5.1
    Определение потребностей в CASE-средствах ............................................................. 25
    5.1.1
    Анализ возможностей организации ....................................................................... 26
    5.1.2
    Определение организационных потребностей...................................................... 27
    5.1.3
    Анализ рынка CASE-средств ................................................................................... 28
    5.1.4
    Определение критериев успешного внедрения ...................................................... 28
    5.1.5
    Разработка стратегии внедрения CASE-средств ............................................... 28 5.2
    Оценка и выбор CASE-средств ....................................................................................... 30
    5.2.1
    Общие сведения......................................................................................................... 30
    5.2.2
    Процесс оценки ......................................................................................................... 31
    5.2.3
    Процесс выбора ........................................................................................................ 31
    5.2.4
    Критерии оценки и выбора...................................................................................... 32 5.3
    Выполнение пилотного проекта...................................................................................... 33 5.3.1
    Определение характеристик пилотного проекта................................................... 34 5.3.2
    Планирование пилотного проекта .......................................................................... 35 5.3.3
    Выполнение пилотного проекта.............................................................................. 36 5.3.4
    Принятие решения о внедрении.............................................................................. 36 5.4
    Переход к практическому использованию CASE-средств ........................................... 37
    Литература: ....................................................................................................................................... 39

    1 CASE-средства. Общая характеристика и классификация
    Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
    Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
    Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:
    • мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;
    • интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;
    • использование специальным образом организованного хранилища проектных метаданных (репозитория).
    Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ
    ПО) содержит следующие компоненты;
    • репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
    • графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;
    • средства разработки приложений, включая языки 4GL и генераторы кодов;
    • средства конфигурационного управления;
    • средства документирования;
    • средства тестирования;
    • средства управления проектом;
    • средства реинжиниринга.
    Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства,
    решающие небольшие автономные задачи, набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого,
    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)).

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

    пошаговой процедуры, определяющей последовательность технологических операций проектирования;

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

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


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

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

    стандарт пользовательского интерфейса. Стандарт должен устанавливать: правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления; правила использования клавиатуры и мыши; правила оформления текстов помощи; перечень стандартных сообщений; правила обработки реакции пользователя.
    3 Методология RAD
    Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

    небольшую команду программистов (от 2 до 10 человек);

    короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

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

    фаза проектирования. Часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE- средства используются для быстрого получения работающих прототипов приложений.
    Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально.
    При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности.
    Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD- проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель).
    Результатом данной фазы должны быть: общая информационная модель системы, функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков, точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами, построенные прототипы экранов, отчетов, диалогов. Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности. В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы.
    Таким образом, на следующую фазу передается более полная и полезная информация.

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

      1   2   3   4   5


    написать администратору сайта