Цель case технологии. Стандарты ISO, SW-CMM. CASE-технологии

29.04.2019

CASE - технологии

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

CASE (Computer Aided Software Engeneering)-технологии являются естественным продолжением эволюции всей отрасли разработки ПО.

CASE-1: анализ требований, проектирование спецификаций и структуры, редактирования интерфейсов.

CASE-2: генерации исходных текстов и реализация интегрированного окружения поддержки полного ЖЦ разработки ПО.

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

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

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

· поддержка разработки моделей анализа и проектирования ПО;

· автоматизация процесса построения ПО;

· обеспечение функций реверсивного проектирования;

· обеспечение функций сопровождения ПО.

Реверсивное программирование : от текста программы или структуры БД к проекту и идее используется для модификации программ.

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

Основными задачами , решаемыми с помощью CASE-систем, являются следующие:

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

2. Хранение моделей в единой базе данных – репозитории, доступном всем участникам разработки.

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

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

5. Автоматизированная генерация документации на программные системы.

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

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

В методологии структурного анализа наиболее часто и эффективно используются следующие средства:

DFD (Data Flow Diagrams ) - диаграммы потоков данных;

ERD (Entity-Relationship Diagrams ) - диаграммы ‘сущность - связь’;

STD (State Transition Diagrams ) - диаграммы переходов состояний.

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

· по отношению к школам - Software Engineering (SE ) и Information Engineering (IE );

· по порядку построения моделей - процедурно-ориентированные, ориентированные на данные и информационно-ориентированные;

· по типу целевых систем - для систем реального времени и для информационных систем .

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

IE - более новая дисциплина. Она имеет более широкую область применения, поскольку является дисциплиной построения систем вообще, а не только систем ПО. Включает этапы более высокого уровня (например, стратегическое планирование).

Во всех структурных методологиях используется одна и та же концепция: данные входят в систему, обрабатываются и выходят из системы (вход – обработка - выход). Отличаются технологии порядком построения модели ПО (как бы по разному решается вопрос: что раньше яйцо или курица?). Традиционный процедурно-ориентированный подход регламентирует первичность проектирования функциональных компонентов по отношению к проектированию структур данных: требования к данным раскрываются через функциональные требования. При подходе, ориентированном на данные, вход и выход являются наиболее важными - структуры данных определяются первыми, а процедурные компоненты являются производными от данных. Информационно-ориентированный подход, как часть IE-дисциплины, отличается от предыдущего подхода тем, что позволяет работать с неиерархическими структурами данных.

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

Типовая CASE-система включает в свой состав средства разработки различных моделей:

Диаграммеры,

Средства для конструирования пользовательского интерфейса,

Генераторы приложений,

Генераторы документации,

Систему программирования,

Центральную базу данных проекта – репозиторий

ERD-диаграммер - средство построения диаграмм «сущность – связь», генерирует SQL-скрипты и экранные формы.

Репозиторий – БД, в которой содержится информация о проекте

DFD-диаграммер – графическое средство построения диаграмм потоковых данных.

SQL – язык управления данными, определяет структуру и операции, выполняемые над реляционными БД (БД табличного типа).

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

Технология	Этапы разработки
Анализ	Проектирование	Кодирование	Тестирование
Традиционная

Основные CASE-средства:

ERWIN (разработка ER-моделей), BPWIN (разработка диаграмм потоков данных), POWER DESIGNER, DESIGNER 2000, RATIONAL ROSE, PARADIGM+

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

Анализ и проектирование . Средства данной группы применяют для создания спецификаций системы и ее проектирования, они поддерживают методологии SE и IE:

CASE - аналитик (Эйтекс);

POSE (Computer Systems Advisers);

Design/IDEF (Meta Software);

BPWin (Logic Works);

SELECT (Select Software Tools);

CASE/4/0 (micro TOOl GmbH)

и ряд других средств.

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

ERWin (Logic Works);

S-Designor (SPD);

Designtr/2000 (Oracle);

Sillverrun (Computer Systems Advisers)/

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

COBOL 2/Workbench (Mikro Focus);

NETRON/CAP (Netron);

APS (Sage Softwfre).

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

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

Adpac CASE Tools (Adpac);

Scan/COBOL и SuperStructure (Computer Data Systems):

Inshtctor/Recoder (language Tecnologe).

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

Обзор CASE- средств

Фирма Computer Associated

CASE-средства:

AllFusion Process Modeler

AllFusion

ERwin

Data

Modeler

AllFusion Data Model Validator

AllFusion Model Manager

AllFusion Saphir Option

AllFusion Component Modeler

Поскольку генерация кода реализована на основе знаний предметной области, а не на основе реляционной структуры данных, полученный код более полно отражает бизнес-логику. Rational Rose и Paradigm Plus поддерживают не только прямую генерацию кода, но и обратное проектирование, т. е. создание объектной модели по исходному коду приложения.

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

Документирование модели. Многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов - пробела и т. п.). Зачастую разработчики ИС имеют дело с нелокализованными версиями СУБД. Это означает, что объекты БД могут называться короткими словами, только латинскими символами и без использования специальных символов (т. е. нельзя назвать таблицу предложением - только одним словом). Кроме того, проектировщики БД нередко злоупотребляют "техническими" наименованиями, в результате таблица и колонки получают наименования типа RTD_324 или CUST_A12 и т. д. Полученную в результате структуру могут понять только специалисты (а чаще всего только авторы модели), ее невозможно обсуждать с экспертами предметной области. Разделение модели на логическую и физическую позволяет решить эту проблему. На физическом уровне объекты БД могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы - имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Например, таблице CUST_A12 может соответствовать сущность Постоянный клиент. Такое соответствие позволяет лучше задокументировать модель и дает возможность обсуждать структуру данных с экспертами предметной области.

Масштабирование. Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость - создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать физическую и логическую модель данных (Reverse Engineering). На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем сгенерировать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой. Например, можно перенести структуру данных с Oracle на Informix (или наоборот) или перенести структуру dbf-файлов в реляционную СУБД, тем самым облегчив решение по переходу от файл-серверной к клиент-серверной ИС.

Наиболее удобным языком моделирования бизнес-процессов является IDEF0 , предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT - Structured Analysis and Design Technique. (Подробно методология SADT излагается в книге Дэвида А. Марка и Клемента Мак-Гоуэна "Методология структурного анализа и проектирования SADT" M.:Meтaтexнoлoгия, 1993.) В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов , для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF0 .

Альтернативой структурному подходу стали объектно-ориентированные методы разработки ИС. В первой половине 90-х годов был предложен разработанный на основе наиболее популярных объектных методов ОМТ (Rumbaudh), Booch и OOSE (Jacobsom) универсальный язык объектного проектирования - Unified Modeling Language, UML (The Unified Method, Draft Edition (0.8). Rational Software Corporation, October 1995).

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

CASE-средства, поддерживающие UML:

1. Paradigm Plus фирмы PLATINUM technology (Computer Associated).

2. Rational Rose фирмы Rational Software.

3. SELECT фирмы SELECT Software

Фирмы

Platinum Technology Incorporated (Платинум Текнолоджи Инкорпорейтед) - американская корпорация, разработчик программ для управления и усовершенствования информационных корпоративных систем. Кроме того, Platinum Technology занимается программами управления базами данных и информационными системами, построением хранилищ данных, разработкой аналитических средств и инструментария для разработчиков. Штаб-квартира корпорации находится в Экбрук-Террас (Иллинойс). Компания была основана в 1987 году в Чикаго. К концу 1990-х годов компания по объемам продаж занимала седьмое место в мире среди компаний-разработчиков компьютерного обеспечения.

Своей основной задачей Platinum Technology считает предоставление полного спектра программного обеспечения для нужд крупного предприятия . Компания активно взаимодействует с крупными разработчиками программного обеспечения - компаниями Oracle, Microsoft , Informix, Sybase, производителями аппаратных средств - IBM, Hewlett-Packard, Sun Microsystems, Digital Equipments. В 1997 году доходы корпорации составили 749 млн. долларов. Офисы Platinum Technology находятся в 40 странах мира, в 1995 году компания начала свою деятельность на территории России. В 1999 году компания была полностью приобретена корпорацией Computer Assotiations.

Computer Associates. (CA) (Компьютер Ассошиэйтс) - американский софтвер, лидер в области СУБД и т. п. Американская компания, специализирующаяся в области программного обеспечения (выпуск программных продуктов в области системного управления, СУБД, средств экономического и финансового управления). Основана в 1976 году Чарлзом Вонгом и Руссом Артцем. Штаб-квартира находится в г. Айсландия (шт. Нью-Йорк). CA, являясь крупнейшей (второй после Microsoft) компанией в мире по созданию программного обеспечения, осуществляет разработку, лицензирование и поддержку более 500 интегрированных продуктов, включающих системы управления информационными и вычислительными сетями предприятий, инструментальные средства, приложения финансового и производственного назначения. Первым успешным продуктом компании была программа сортировки данных (СA Sort). Тонко уловив конъюнктуру (пользователям приходилось около 25% времени тратить на сортировку), СА приобрела права на эту программу у швейцарской фирмы и осуществила ее выгодные продажи. Благодаря своим первым удачным шагам Computer Associates завоевала репутацию одного из ведущих участников рынка софтверной продукции. После удачных первых шагов фирма во главе с удачливым, но жестким исполнительным директором Вонгом стала интенсивно расширять поле своей деятельности. За более чем двадцатилетнюю историю своего существования CA приобрела свыше 60 компаний, сотрудники которых были безжалостно уволены - такова кадровая стратегия компании. Подбору персонала уделяется огромное внимание. С начала 1990-х годов компания становится лидером в области управления хранением и резервным копированием данных. Последним достижением в этой области является продукт ARCserve. Принадлежащая CA технология ARCserve обеспечивает сквозное управление средствами хранения данных для всех ресурсов информационных технологий , включая рабочие станции, серверы, базы данных, системы групповой работы и web-серверы. Эта технология позволяет осуществлять целостное управление хранилищами на любых платформах - от настольных ПК до мейнфреймов. Играя роль всеобъемлющего интегрированного решения по управлению средствами хранения, ARCserve обеспечивает не только простое резервное копирование, но также архивирование, восстановление после сбоев, сетевую миграцию данных, реплицирование и управление носителями и устройствами.

Начиная с 1996 года, продукция ARC-serve неоднократно отмечалась почетными наградами ведущих компьютерных изданий. В 1998 году в штате компании насчитывалось более 13 тыс. сотрудников, совокупный доход компании составил 4,7 млрд. долларов. Продукция CA распространяется в более чем 100 странах мира, в 40 странах функционируют зарубежные представительства СА. К 2002 году планируется, что годовой доход компании составит около $1,5 млрд., что превысит показагода более чем в три раза. Computer Associates сегодня является наиболее динамично развивающейся компьютерной компанией в мире.

В связи с развитием CASE-технологий в рамках спиральной модели жизненного цикла ПО широкое распространение получила методология быстрой разработки приложений RAD (Rapid Application Development). Процесс разработки при этом содержит три элемента:

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

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

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

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

· анализа и планирования требований;

· проектирования;

· реализации;

· внедрения.

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

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

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

По результатам анализа процессов принимается решение о количестве, составляющих ИС подсистем, поддающихся разработке одной командой разработчиков за приемлемое для RAD-проектов время - порядка 2-3 мес.

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

· общая информационная модель системы;

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

· точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

· построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

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

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

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

Принципы организации RAD

Главная идея RAD технологии состоит в том, чтобы как можно быстрее донести до заказчика результаты разработки, пусть и не в полном виде. Например, реализация только пользовательского интерфейса и предъявление его заказчику позволяет уже на ранней стадии разработки получить замечания по экранным и отчетным формам и внести необходимые коррективы. В этом случае значительно возрастает вероятность успеха проекта, то есть возникает уверенность в том, что конечный продукт будет делать именно то, что ожидает заказчик. Кроме того, не следует забывать и тот факт, что разница стоимости ошибки определения требований в начале проекта и в конце равна 1:200.

Основные принципы RAD можно сформулировать следующим образом:

Обязательное использование инструментальных средств

Тесное взаимодействие между разработчиками и заказчиком

Работа ведется немногочисленными хорошо управляемыми группами профессионалов.

Итерационное прототипирование.

Замечания заказчика

Детализация.

Анализ результатов программирования.

RAD группа всегда работает только над одним прототипом

Большие системы разбиваются на подсистемы.

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

Гибкое проектирование и XP

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

Гибкое моделирование (Adile Modeling - AM) – это упорядочивающая, основанная на практическом опыте методология эффективного моделирования и документирования программных систем.

Четыре базовых положения манифеста.

1. Люди и контакты важнее процессов и средств.

2. Работающие программы важнее идеальной документации.

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

4. Готовность к изменениям важнее соблюдения планов.

Принципы гибкой разработки ПО:

1. Мы придаем первоочередное значение удовлетворению заказчика, быстро и постоянно предоставляя нужное ему программное обеспечение.

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

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

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

5. Проекты строятся мотивированными индивидуалами. Создайте им условия, удовлетворяйте их требования и доверяйте им в том, что касается выполнения работы .

6. Наиболее производительный и эффективный способ передачи информации рабочей группе и внутри нее – это разговор лицом к лицу.

7. Работающее программное обеспечение – это основной показатель прогресса.

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

9. Непрерывное внимание к техническому качеству и хорошему проектированию улучшает гибкость.

10. Простота – искусство минимизировать количество ненужной работы – исключительно важна.

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

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

t Going to Need It» - «Это вам не понадобится»). Оба они олицетворяют собой одну из практик ХР под названием Простой дизайн.

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

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

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

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

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

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

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

В книге Extreme Programming Explained Кент приводит четыре критерия простой системы. Вот они в порядке убывания важности:

· Система успешно проходит все тесты;

· Код системы ясно раскрывает все изначальные замыслы;

· В ней отсутствует дублирование кода;

· Используется минимально возможное количество классов и методов.

Успешное тестирование системы - довольно простой критерий. Отсутствие дублирования кода тоже вполне четкое требование, хотя большинство разработчиков нужно учить, как этого достичь. Самое сложное скрывается в словах «раскрывает изначальные замыслы». Что это значит?

Основное достоинство программного кода в данном случае - его ясность. ХР всячески подчеркивает, что хороший код - это код, который можно легко прочесть. Скажите ХР-шнику, что он пишет «заумный код», и будьте уверены, что обругали этого человека. Но понимание замыслов программиста, написавшего код, зависит также и от опыта и ума того, кто этот код пытается прочесть. Однако отметим, что не стоит думать над вопросом, как сделать дизайн максимально простым.

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

Рефакторинг и принцип YAGNI. Эта тема сравнительно недавно всплыла в списке рассылки, посвященном ХР, и, коль скоро мы заговорили о роли проектирования, нам стоит ее обсудить. Дело в том, что процесс рефакторинга требует времени, но не добавляет новой функциональности. С другой стороны, принцип YAGNI гласит, что надо проектировать только для текущей функциональности, а не для того, что понадобится в будущем. Не сталкиваемся ли мы здесь с противоречием?

Принцип YAGNI состоит в том, чтобы не делать систему более сложной, чем того требует реализация текущих задач. Это является частью практики «Простой дизайн». Рефакторинг же необходим для поддержания системы в максимально простом состоянии. Его нужно проводить сразу же, как только вы обнаружите, что можете что-либо упростить.

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

Наращивание архитектуры . Термин «архитектура» передает идею основных элементов системы, тех ее частей, которые трудно изменить. Они являются фундаментом, на котором можно построить все остальное. Какую роль играет архитектура в эволюционном проектировании? Критики ХР считают, что эта методология вообще не признает работы над архитектурой, что вся суть ХР - сразу садиться за написание кода и уповать на то, что рефакторинг решит все проблемы с проектированием. Они правы, и, может быть, в этом заключается некоторая слабость ХР Приверженцы ХР - Кент Бек (Kent Beck), Рон Джеффриз (Ron Jeffries) и Боб Мартин (Bob Martin) - прикладывают очень много сил, чтобы вообще избежать любого предварительного проектирования архитектуры. Не добавляйте в систему базу данных, пока она вам действительно не понадобилась. Работайте поначалу с файлами, а база данных появится в следующей итерации, в результате рефакторинга.

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

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

Советы тем, кто хочет правильно использовать диаграммы.

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

Чаще всего диаграммы используются для того, чтобы проанализировать проектные решения еще до написания кода. Нередко при этом возникает чувство, что в ХР этого делать нельзя. Это совсем не так. Многие полагают, что перед разработкой сложной задачи стоит ненадолго собраться всей командой для ее предварительного проектирования. Тем не менее, когда проводите такие собрания, не забывайте, что:

они должны быть действительно недолгими;

не нужно обсуждать все подробности (только самое важное);

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

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

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

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

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

используйте только те диаграммы, которые вы можете поддерживать без особых усилий;

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

посмотрите, обращают ли ваши разработчики на диаграммы хоть какое-то внимание, и если нет, выбросите их.

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

Проектирование в ХР требует от человека следующих качеств :

· постоянного желания сохранять программный код простым и понятным насколько это возможно;

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

· хорошего знания паттернов: рассматривать их не просто как готовые решения, а оценивать своевременность и использовать постепенно, от простого к сложному;

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

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

· мы знаем простой способ заставить его работать, и мы действуем этим способом;

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

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

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

CASE- технологии CASE (Computer Aided Software Engeneering) Эти технологии являются естественным продолжением эволюции всей отрасли разработки ПО. CASE-1: анализ требований, проектирование спецификаций и структуры, редактирование интерфейсов. CASE-2: генерация исходных текстов и реализация интегрированного окружения поддержки полного ЖЦ разработки ПО.

Основные задачи CASE-систем 1.Разработка моделей предметной области, функциональной структуры системы, структур данных на графических языках. 2.Хранение моделей в единой базе данных – репозитории, доступном всем участникам разработки. 3.Формальный анализ разрабатываемых моделей, позволяющий избегать некоторых семантических ошибок. 4.Автоматизированная генерация структур баз данных, приложений, текстов программ. 5.Автоматизированная генерация документации на программные системы. 6.Обеспечение повторного использования наработок при модернизации, перепроектировании системы.

Методологии структурного анализа классифицируются по признакам: по отношению к школам - Software Engineering (SE) и Information Engineering (IE); по порядку построения моделей - процедурно-ориентированные, ориентированные на данные и информационно-ориентированные; по типу целевых систем - для систем реального времени и для информационных систем.

Классификация по функциональной ориентации Анализ и проектирование. CASE- аналитик (Эйтекс); POSE (Computer Systems Advisers); Design/IDEF (Meta Software); BPWin (Logic Works); SELECT (Select Software Tools); CASE/4/0 (micro TOOl GmbH) Проектирование баз данных и файлов. ERWin (Logic Works); S-Designor (SPD); Designtr/2000 (Oracle); Sillverrun (Computer Systems Advisers)/ Программирование. COBOL 2/Workbench (Mikro Focus); DECASE (DEC); NETRON/CAP (Netron); APS (Sage Softwfre). Сопровождение и реинжениринг Adpac CASE Tools (Adpac); Scan/COBOL и SuperStructure (Computer Data Systems): Inshtctor/Recoder (language Tecnologe).

CASE-средства фирмы Computer Associated AllFusion Process Modeler (ранее:BPwin) - моделирование бизнес-процессовAllFusion Process Modeler (ранее:BPwin) AllFusion ERwin Data Modeler (ранее: ERwin) - моделирование данныхAllFusion ERwin Data Modeler (ранее: ERwin) AllFusion Data Model Validator (ранее: ERwin Examiner) - проверка моделей данных.AllFusion Data Model Validator (ранее: ERwin Examiner) AllFusion Model Manager (ранее: ModelMart) - сервер для совместной работы пользователей ERwin и/или BpwinAllFusion Model Manager (ранее: ModelMart) AllFusion Saphir Option - – средство просмотра структур данных широкого набора корпоративных информационных систем.AllFusion Saphir Option AllFusion Component Modeler (Paradigm Plus) - моделирование компонентов ПОAllFusion Component Modeler (Paradigm Plus)

Альтернативой структурному подходу стали объектно-ориентированные методы разработки ИС. В первой половине 90-х годов был предложен универсальный язык объектного проектирования - Unified Modeling Language, UML (The Unified Method, Draft Edition (0.8). Rational Software Corporation, October 1995). Существует несколько CASE-средств, поддерживающих язык UML. Наиболее известными являются: CASE-средства, поддерживающие UML: Paradigm Plus фирмы PLATINUM technology (Computer Associated). Rational Rose фирмы Rational Software. SELECT фирмы SELECT Software

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

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

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

Принципы организации RAD: Обязательное использование инструментальных средств. Тесное взаимодействие между разработчиками и заказчиком. Работа ведется немногочисленными хорошо управляемыми группами профессионалов. Разработка базируется на моделях. Итерационное прототипирование (традиционно 3 прототипа). RAD группа всегда работает только над одним прототипом. Большие системы разбиваются на подсистемы и для него выделяется несколько RAD групп.

Манифест альянса гибкой разработки ПО (февраль 2001 года) 1.Люди и контакты важнее процессов и средств. 2.Работающие программы важнее идеальной документации. 3.Сотрудничество с заказчиком важнее переговоров по условиям контракта. 4.Готовность к изменениям важнее соблюдения планов.

Принципы гибкой разработки ПО: 1. Мы придаем первоочередное значение удовлетворению заказчика, быстро и постоянно предоставляя нужное ему программное обеспечение. 2.Мы приветствуем изменения требований даже на поздних этапах разработки. Гибкие процессы позволяют поддерживать изменения, обеспечивая заказчику конкурентное преимущество. 3.Новые версии работающего ПО поставляются часто, с регулярностью от нескольких недель до нескольких месяцев, причем более предпочтительны короткие временные периоды. 4.В ходе проекта бизнесмены и разработчики должны постоянно работать вместе. 5.Проекты строятся мотивированными индивидуалами. Создайте им условия, удовлетворяйте их требования и доверяйте им в том, что касается выполнения работы. 6.Наиболее производительный и эффективный способ передачи информации рабочей группе и внутри нее – это разговор лицом к лицу. 7.Работающее ПО – это основной показатель прогресса. 8.Гибкие процессы стимулируют устойчивую работу. Спонсоры, разработчики и пользователи должны быть в состоянии неограниченно долго поддерживать постоянный ритм работы. 9.Непрерывное внимание к техническому качеству и хорошему проектированию улучшает гибкость. 10.Простота – искусство минимизировать количество ненужной работы – исключительно важна. 11.Наилучшим образом архитектура, требования и проектирование формируются и выполняются самоорганизующимися командами. 12.Команда должна регулярно обсуждать, как повысить эффективность своей работы, после чего изменять и согласовывать рабочий процесс с результатами этих обсуждений.

Экстремальное программирование (XP) Ghbywbgs: Ищите самое простое решение, которое может сработать. Это вам не понадобится (не делать ничеговпрок). программный код должен быть максимально прост: –Система успешно проходит все тесты; –Код системы ясно раскрывает все изначальные замыслы; –В ней отсутствует дублирование кода; –Используется минимально возможное количество классов и методов

Расшифровка аббревиатуры CASE: Computer Aided Software Engineering, что можно перевести на русский, примерно, как разработка программного обеспечения с помощью компьютера .

В соответствии с ГОСТ 19781-90 Программное обеспечение (ПО) – совокупность программ системы обработки информации и программных документов, необходимых для их эксплуатации.

Очевидно, что программное обеспечение бывает разное. В частности, оно может быть прикладным и системным.

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

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

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

Ø неадекватная спецификация требований;

Ø неспособность обнаруживать ошибки в проектных решениях;

Ø низкое качество документации, снижающее эксплуатационные качества;

Ø затяжной цикл и неудовлетворительные результаты тестирования.

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

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

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

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

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

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

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

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

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

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

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

3. Анализ производится сверху вниз, проектирование производится сверху вниз, разработка производится сверху вниз и тестирование производится сверху вниз.

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

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

МИНИСТЕРСТВО КУЛЬТУРЫ РОССИЙСКОЙ ФЕДЕРАЦИИ

ТАМБОВСКИЙ ФИЛИАЛ

федерального государственного образовательного учреждения

высшего профессионального образования

«Московский государственный университет культуры и искусств»

Кафедра прикладной информатики

Алексей Сергеевич Боярский

CASE-технологии

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

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

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

· неадекватная спецификация требований;

· неспособность обнаруживать ошибки в проектных решениях;

· низкое качество документации, снижающее эксплуатационные качества;

· затяжной цикл и неудовлетворительные результаты тестирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· средства реинжиниринга.

Все современные 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)).

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

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

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

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

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

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

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

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

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

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

· Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

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

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

Достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 1 – Схема определения потребностей в CASE-средствах

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

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

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

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

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

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

Рисунок 2 – Схема оценки и выбора CASE-средств

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

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

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

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

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

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

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

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

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

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

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

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

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

Определение списка критериев основано на пользовательских требованиях и включает:

· выбор критериев для использования из приведенного далее перечня;

· определение дополнительных критериев;

· определение области использования каждого критерия (оценка, выбор или оба процесса);

· определение одной или более метрик для каждого критерия оценки;

· назначение веса каждому критерию при выборе.

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

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

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

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

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

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

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

Рисунок 3 – Схема реализации пилотного проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

· использованное время;

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

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

· удобство сопровождения.

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

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

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

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

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

1. Вендров А.М. Один из подходов к выбору средств проектирования баз данных и приложений. - "СУБД", 2006, № 3.

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

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

4. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. М., "МетаТехнология", 2003.

5. Создание информационной системы предприятия. "Computer Direct", 2007, № 2.

6. Горин С.В., Тандоев А.Ю. Применение CASE-средства для информационного моделирования в системах обработки данных. – СПб, 2005, № 3.

7. Горин С.В., Тандоев А.Ю. CASE-средства для разработки структуры базы данных. - СПб, 2006, № 1.

CASE-технологии. Современные методы и средства проектирования информационных систем

Введение

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

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

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

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

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

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

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

необходимость интеграции существующих и вновь разрабатываемых приложений;

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

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

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

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

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

неадекватная спецификация требований;

неспособность обнаруживать ошибки в проектных решениях;

низкое качество документации, снижающее эксплуатационные качества;

затяжной цикл и неудовлетворительные результаты тестирования.

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

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

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

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

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

Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

приемлемый уровень отдачи от инвестиций в CASE-средства. 1. Основы методологии проектирования ИС 1.1. Жизненный цикл по ИС

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

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

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

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

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

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

каскадная модель (70-85 г.г.);

спиральная модель (86-90 г.г.).

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

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

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

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

Рис. 1.1. Каскадная схема разработки ПО

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

Рис. 1.2. Реальный процесс разработки ПО по каскадной схеме

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ (рис. 1.3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

Рис 1.3. Спиральная модель ЖЦ 1.3. Методологии и технологии проектирования ИС 1.3.1. Общие требования к методологии и технологии

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

Технология проектирования определяется как совокупность трех составляющих:

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

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

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

Рис. 1.4. Представление технологической операции проектирования

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованям:

технология должна поддерживать полный ЖЦ ПО;

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

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

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

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

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

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

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

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

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

стандарт оформления проектной документации;

стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

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

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

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

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

Стандарт оформления проектной документации должен устанавливать:

комплектность, состав и структуру документации на каждой стадии проектирования;

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

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

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

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

Стандарт интерфейса пользователя должен устанавливать:

правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

правила использования клавиатуры и мыши;

правила оформления текстов помощи;

перечень стандартных сообщений;

правила обработки реакции пользователя. 1.3.2. Методология RAD

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

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

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

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

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

фаза анализа и планирования требований;

фаза проектирования;

фаза построения;

фаза внедрения.

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

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

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

общая информационная модель системы;

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

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

построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

определяется необходимость распределения данных;

производится анализ использования данных;

производится физическое проектирование базы данных;

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

определяются способы увеличения производительности;

завершается разработка документации проекта.

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

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

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

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

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

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

Цель case технологии. Стандарты ISO, SW-CMM. CASE-технологии

Этапы разработки

Анализ

Кодирование

Тестирование

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам:

Ваш комментарий (необязательно):