3.10 Оценка эффективности использования типовых решений. Основные черты ТПР: Типовые проектные решения ориентированы на автоматизацию деятельности множества однородных объектов (путем настройки под конкретные особенности каждого из них). Основная цель применения ТПР – уменьшение трудоемкости и стоимости проектирования и/или разработки ИС. Создание ТПР возможно только после тщательного и всестороннего изучения предметной области и предполагает обобщение накопленного в частных случаях опыта (путем классификации, типизации, абстрагирования, унификации и т.п.). Типовые решения бывают простыми или комбинированными. Простые ТПР охватывают только какой-либо один вид обеспечения ИС, комбинированные – два и более. Примеры простых ТПР: Классификаторы (ИО), прикладные программы общего и специального назначения (ПО), инструктирующие руководства по управлению бизнес-процессами (ОО), рекомендации по составлению ТЗ (МО) и т.п.^ 3.11 Типовое проектное решение (ТПР).Определение. Типовое проектное решение (ТПР) – это представленное в виде комплекта проектной документации и/или набора программных модулей проектное решение, пригодное к многократному использованию^ 3.12 Классы и структура ТПР Выделяются следующие классы ТПР: элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному); подсистемные ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей; объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС. Каждое типовое решение предполагает наличие, кроме собственно функциональных элементов (программных или аппаратных), документации с детальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы.^ 3.13 Состав и содержание операций типового элементного проектирования ИС.Элементное проектирование В качестве типового элемента используются простые ТПР, относящиеся к отдельной задаче ИС. В этом случае ИС комплектуется как множество ТПР по отдельным разрозненным задачам. Дополнительные элементы, для которых отсутствуют ТПР, разрабатываются вручную. Обычно рассматривают три группы ТПР: Типовые проектные решения, обеспечивающие оптимальный выбор и организацию технических средств; Типовые проектные решения, относящиеся к основным задачам ИС (алгоритмы решения задач, описание входных и выходных данных, программные модули общего и специального назначения и т.д.); Типовые проектные решения, описывающие должностные инструкции всех категорий работников, связанных с проектированием и функционированием ИС.Существенный недостаток метода: между отдельными ТПР, как правило, отсутствует информационная/техническая/программная совместимость (проблема «лоскутной автоматизации»).^ 3.14 Функциональные пакеты прикладных программ (ППП) как основа ТПР. Подсистемные ТПР Пакеты прикладных программ Подсистемное проектирование Типовыми элементами выступают пакеты прикладных программ (ППП), которые применяются для автоматизации отдельных функциональных подсистем ИС. ППП обладают следующими свойствами: Функциональная полнота; Минимизация внешних информационных связей; Параметрическая настраиваемость; Полная интеграция внутри ППП и более высокий (хотя и не полный) уровень интеграции с другими пакетами и отдельными программными продуктами. С точки зрения проектировщика ИС ППП представляет собой «черный ящик», который преобразует входные информационный и параметрический потоки в выходной поток результатов. В схеме ППП можно выделить следующие элементы:^ Информационный поток – исходные данные в электронном или бумажном виде, предназначенные для обработки пакетом;Результаты работы – представляются в виде отчетов, графиков или документов (в электронном или бумажном виде);^ Блок функционирования – обрабатывает исходные данные.Параметрический поток – содержит информацию, необходимую для настройки пакета на конкретные условия функционирования. Обычно параметрическая информация предоставляется пользователю в виде справочников и/или конфигурационных таблиц. В зависимости от принципа использования параметрического потока выделяют два способа привязки ППП к конкретным условиям системы: Принцип интерпретации (поглощается самим ППП); Принцип генерации (на его основе специальная программа-генератор генерирует ППП, настроенный под конкретные условия).^ Блок обработки параметров – интерпретирует значения параметров и переносит их непосредственно в прикладные программы.Блок адаптации – позволяет пользователю адаптировать существующие типовые решения путем доработки существующих или добавления новых модулей ИС. В блок адаптации обычно включаются такие средства как генераторы отчетов, генераторы форм, встроенные макроязыки и т.п.Пример ППП: «1С: Предприятие».Недостаток: недостаточный уровень совместимости различных ППП в рамках единой корпоративной ИС.^ 3.17 Каноническое проектирование ИС Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90. В зависимости от сложности объекта автоматизации и набора задач, требующих решения при создании конкретной ИС, стадии и этапы работ могут иметь различную трудоемкость. Допускается объединять последовательные этапы и даже исключать некоторые из них на любой стадии проекта. Допускается также начинать выполнение работ следующей стадии до окончания предыдущей.^ 10.3 Контроль качества Контроль качества включает отслеживание определенных результатов по проекту для установления той, соответствуют ли они определенным стандартам качества, и для определения путей устранения причин неудовлетворительного исполнения. Он должен осуществляться по всему проекту-Результаты по проекту включают результаты как по продукту (например, компоненты), так и по менеджменту (такие как показатели исполнения по стоимости по календарному плану). Контроль качества часто выполняется департаментом по контролю за качеством или организационной единицей с похожим названием, но это не является обязательным.Команда управления проектом должна иметь практические знания в области статистического контроля качества, особенно в моделировании и вероятности, для облегчения оценки результатов контроля качества. Среди других результатов члены команды должны обратить особое внимание на различие между:Команда управления проектом должна иметь практические знания в области статистического контроля качества, особенно в моделировании и вероятности, для облегчения оценки результатов контроля качества. Среди других результатов члены команды должны обратить особое внимание на различие между:• предотвращением (устранением ошибок из процесса) и инспекцией (устранением погрешностей для потребителя);• моделированием атрибутов (удовлетворяет результат или нет) и моделированием переменных (результат оценивается по непрерывной шкале, которая измеряет степень соответствия);• специальными (необычные события) и внезапными (отклонение от нормального процесса) случаями;• допущением (результат приемлем, если он находится в диапазоне, заданном допущением) и зоны контроля (процесс считается под контролем, если его результаты находятся в пределах последнего).^ 3.15 Адаптация типовой ИС.3.16 Методы и средства прототипного проектирования ИС. Модельно-ориентированное проектированиезаключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации. Технология проектирования в этом случае должна обеспечивать единые средства для работы как с моделью типовой ИС, так и с моделью конкретного предприятия. Типовая ИС в специальной базе метаинформации - репозитории - содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программного обеспечения. Таким образом, модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно также создание системы на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства. Репозиторий содержит базовую (ссылочную) модель ИС, типовые (референтные) модели определенных классов ИС, модели конкретных ИС предприятий. Базовая модель ИСв репозитории содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, бизнес-правил, организационной структуры, которые поддерживаются программными модулями типовой ИС. Типовые моделиописывают конфигурации информационной системы для определенных отраслей или типов производства. Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench). Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости может быть откорректирована. На основе этой модели автоматически осуществляется конфигурирование и настройка информационной системы. Бизнес-правила определяют условия корректности совместного применения различных компонентов ИС и используются для поддержания целостности создаваемой системы. Модель бизнес-функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия (подробное описание см. в разделе "Анализ и моделирование функциональной области внедрения ИС"). Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций (подробное описание см. в разделе "Спецификация функциональных требований к ИС"). Для отображения процессов используется модель управления событиями (ЕРС - Event-driven Process Chain). Именно модель бизнес-процессов позволяет выполнить настройку программных модулей - приложений информационной системы в соответствии с характерными особенностями конкретного предприятия. Модели бизнес-объектов используются для интеграции приложений, поддерживающих исполнение различных бизнес-процессов (подробное описание см. в разделе "Этапы проектирования ИС с применением UML"). Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала (подробное описание см. в разделе "Анализ и моделирование функциональной области внедрения ИС"). Внедрение типовой информационной системы начинается с анализа требований к конкретной ИС, которые выявляются на основе результатов предпроектного обследования объекта автоматизации (см. раздел "Анализ и моделирование функциональной области внедрения ИС"). Для оценки соответствия этим требованиям программных продуктов может использоваться описанная выше методика оценки ППП. После выбора программного продукта на базе имеющихся в нем референтных моделей строится предварительная модель ИС, в которой отражаются все особенности реализации ИС для конкретного предприятия. Предварительная модель является основой для выбора типовой модели системы и определения перечня компонентов, которые будут реализованы с использованием других программных средств или потребуют разработки с помощью имеющихся в составе типовой ИС инструментальных средств (например, ABAP в SAP, Tools в BAAN).3. 16 Реализация типового проекта предусматривает выполнение следующих операций: установку глобальных параметров системы; задание структуры объекта автоматизации; определение структуры основных данных; задание перечня реализуемых функций и процессов; описание интерфейсов; описание отчетов; настройку авторизации доступа; настройку системы архивирования.8Расчёт затрат на разработку ИС.8.1 Экономическое обоснование необходимости разработки ИС.Важнейшей задачей является анализ экономической эффективности внедряемой системы. Ее своевременное решение дает возможность сравнивать различные варианты автоматизации и установить оптимальный вариант, оценить его влияние на изменение показателей деятельности организации. Эффективность внедрения автоматизированной системы обуславливается действием ряда факторов организационного, информационного и экономического характера. Организационный эффект проявляется в освобождение работников от рутинных операций по систематизации и группировке учетных данных, записей в реестры и другую документацию. Информационный фактор эффективности выражается в повышение уровня информированности персонала. Экономический фактор проявляется в том, что учетная информация, имеющая целью полное и своевременное отражение и состояние объекта и причин, влияющих на его развитие, в конечном счете направлена на улучшение использование ресурсов. Опыт эксплуатации комплексов задач показал, что в процессе автоматизации достигается снижение трудоемкости отдельных операций, рост производительности и улучшений условий труда отдельных работников, повышение оперативности достоверности, включая подготовку отчетности при постоянно растущем объеме без увеличения численности персонала и т.д. 8.2 Состав работ при реализации ИС.Итак, для обоснования экономической эффективности разработки и внедрения ИС необходимо: Произвести расчет экономии труда за счет внедрения ИС и рост производительности труда. Произвести расчет затрат на разработку необходим для обоснования экономической эффективности системы Оценить срок окупаемости проекта8.3 Расчёт затрат на создание ИС, цены и прибыли от реализации ИСРасчет затрат на разработку необходим для обоснования экономической эффективности системы. Плановые затраты на разработку включают все расходы, связанные с ее выполнением, независимо от источника их финансирования. Определение затрат на разработку производится путем составления калькуляции плановой себестоимости. Она является основным документом, на основании которого осуществляется планирование и учет затрат на выполнение. Смета затрат включает следующие статьи: основная заработная плата разработчиков информационной системы; дополнительная заработная плата разработчиков информационной системы; отчисления на социальные страхования; расчет затрат на амортизацию ЭВМ; расходы на электроэнергию, используемую при разработку информационной системы; накладные расходы. Рассмотрим более подробно каждую из указанных статей затрат. В результате сделанных расчетов можно сделать вывод, что автоматизация повысит абсолютный показатель эффективности использования трудовых ресурсов на сколько то часов в месяц, показатель стоимости уменьшит во сколько то раз, окупаемость проекта около скольки то месяцев месяцев. 9 Расчёт затрат при внедрении ИС.^ 9.1 Расчёт затрат, связанных с покупкой, внедрением и использованием ИС. Внедрение информационной системы сопряжено с капитальными вложениями как на приобретение техники, так и на разработку проекта, выполнение подготовительных работ и подготовку кадров. Обобщенным критерием экономической эффективности является минимум затрат живого и овеществленного трудаЭкономический эффект от внедрения вычислительной и организационной техники подразделяется на прямой и косвенный. Под прямой экономической эффективностью понимают экономию материально-трудовых ресурсов и денежных средств, полученную в результате сокращения численности управленческого персонала, фонда заработной платы. Определим экономическую эффективность с помощью трудовых и стоимостных показателей. На составление отчетности и планов в месяц затрачивалось 80 чел. / ч (Т0) При использовании автоматизированной системы - 10 чел. / ч в месяц (Т1) Абсолютный показатель экономической эффективности Тэк составляет: Тэк = Т0 - Т1 (3.10) Тэк = 80 - 10=70 чел. / ч в месяцОтносительный индекс производительности труда вычисляется по формуле (3.11): J п. т. = Т1/Т0 (3.11) J п. т. =10/80=0,125Рассчитаем стоимостной показатель по формуле 3.12Сэк = С0 - С1 (3.12) Заработная плата менеджера составляет 50000 руб в месяц, прибавим к ней 26% начислений на зарплату итого получаем 50000 +13000= 63000 руб. Затраты на заработную плату менеджеров при прежней схеме работы составят 30000 руб (С0). При использовании ИС 3750 руб(С1). Сэк = 30000 - 3750 =750 р. Индекс стоимости затрат определяется по формуле 3.13J ст. затр. = С1/С0 (3.13) J ст. затр. = 3750/30000 =0,125^ 9.2 Срок окупаемости затрат вычисляется по формуле 3.14, где (3.14) З0 - затраты на техническое оборудование; П0 - затраты на программное обеспечение. Подставим имеющиеся данные в формулу 2.12, в результате получим: З0 - затрат на оборудование равны 0, т. к имеющееся оборудование возможно использовать и для новой системы; П0 - затраты на программное обеспечение вычисленные в п.3.3 равны 283837,76 руб.; месяцев. В результате сделанных расчетов можно сделать вывод, что автоматизация повысит абсолютный показатель эффективности использования трудовых ресурсов на 70 часов в месяц, показатель стоимости уменьшит в 0,125 раз, окупаемость проекта около 11 месяцев. Кроме того, будет достигнута и косвенная эффективность, а именно повысится качество работы, поэтому внедрение данного модуля является необходимым. 10.2 Контроль границ проекта Рамки продукта определяют спект свойств и функциональностей, которые должны поставляться, и ограничения, которые должны быть выполнены, чтобы контролировать выпуск или поставку продукта (что проект будет выполнять). Описание рамок продукта в Положении не определяет требования или спецификации продукта. Напротив, предполагается предложить лишь общее описание продукта и начальное понимание и соглашение о рамках продукта. Рамки проекта определяют работу, которая требуется, чтобы обеспечить соответствие проектного продукта целям проекта (как проект будет исполняться). Хотя рамки продукта и рамки проекта тесно связаны, остальные разделы Положения описывают лишь рамки проекта и процессы, необходимые для получения продукта. Фокус Положения дожен концентрироваться на процессах проекта. ^ 9.3 Совокупная стоимость владения (ТСO - Total Cost of Ownership) информационной системой - сравнительно новое понятие, которому в последнее время уделяется самое пристальное внимание в литературе. Под совокупной стоимостью владении понимается сумма прямых и косвенных затрат, которые несет владелец системы за период жизненного цикла последней.При анализе ТСО рассматривают жизненный цикл, включающий в себя время жизни существующей на предприятии системы, время, необходимое для проектирования нового альтернативного решения, срок эксплуатации альтернативной системы с учетом амортизации ее элементов и ориентировочного срока ожидания. Полсроком ожидания понимают время, необходимое для выхода системы на уровень доходности, при котором ее эксплуатация позволяет получить частичный (до 90%) возврат инвестиций, вложенных в систему.При выборе новой информационной системы между альтернативными существующему решению вариантами необходимо оценить совокупную стоимость владения для каждого предлагаемого варианта. При этом жизненный цикл, на котором оцениваются прямые и косвенные затраты, должен включать: время жизни существующей на предприятии системы; время проектирования новой системы; время на закупку и внедрение элементов новой системы; время эксплуатации новой системы, которое необходимо ограничить сроком возврата 90% вложенных инвестиций за счет прибыли от эксплуатации этой системы. Вариант информационной системы с более коротким жизненным циклом предпочтителен для дальнейшего использования.11. CASE-системы.11.1 Инструментальные средства разработки систем.Предлагаемая методология создания ИС поддерживается комплексом согласованных между собой инструментальных средств, который обеспечивает непрерывный цикл автоматизации процессов, выполняемых на всех этапах ЖЦ ИС.. Согласованность этих средств обеспечивается наличием интерфейсов для прямого взаимодействия и поддержкой общепринятых стандартов открытых систем. Комплекс средств такого рода позволяет строить модели, описывающие деятельность организации, формировать требования к ИС, быстро переходить от моделей требований к ИС к проекту приложений и баз данных. Он обеспечивает поддержку быстрой итеративной разработки приложений, их тестирование и интеграцию в систему. Заложенные в методологию и поддержанные этими инструментальными средствами принципы, основанные на использовании моделей и повторном использовании спецификаций, обеспечивают возможность быстрого внесения изменений как на стадиях создания ИС, так и на стадиях сопровождения и развития. Созданные на базе этого набора средств распределенные ИС (приложения и БД) могут быть реализованы как в двухзвенной, так и в трехзвенной архитектуре клиент-сервер. Этот же набор средств позволяет переносить приложения и базы данных на различные платформы без перепрограммирования. Приложения, созданные на базе этого набора средств, являются открытыми и масштабируемыми. В состав набора входят средства реинжиниринга, позволяющие автоматически восстанавливать модель существующей системы. В соответствии с проектом эта модель может быть использована для построения моделей новой системы. Методология и поддерживающий ее набор инструментальных средств обеспечивают полный контроль и гибкое управление ходом разработки, включая: поддержку коллективной разработки с возможностью параллельного и распределенного выполнения различных работ; возможность перехода к следующему этапу (шагу), не дожидаясь полного завершения предыдущего; применение методов контроля качества и постоянный контроль полученных результатов; поддержку итеративного характера разработки (возможность пересмотра полученных результатов и возврата на любой из предыдущих этапов; возможность быстрого внесения изменений в требования в процессе разработки; управление конфигурацией. ^ 10. Система показателей для проекта ИС.10.1 Классические показатели.Высшее руководство использует системы показателей проекта, также известные как системы сбалансированных показателей, чтобы удостовериться, что события проекта соответствуют стратегиям и концепциям организации. Между прочим, именно поэтому эти системы показателей чаще называются "системами сбалансированных показателей". До их появления исполнители имели представление только о финансовых показателях действий или проектов. Была обнаружена потребность в более "сбалансированном" представлении действий, которое включало бы в себя измерения других аспектов производительности работы.Системы показателей проекта должны удовлетворять два требования проекта: потребность в механизме передачи информации о результатах работы по проекту и о его состоянии занятым исполнителям и потребность в сравнении результатов работы по множеству проектов.^ Ключевые показатели эффективности (KPI) Ключевые показатели эффективности, или KPI, - это аббревиатура, часто используемая вместе с системами сбалансированных показателей. Системы сбалансированных показателей используют 5 или 6 показателей в каждой из 4 областей качества работы организации как системы мер. Эти 5 или 6 показателей могут быть любыми из тысяч, которые были измерены, но выбор ограничен природой области (финансы, заказчики, бизнес-процессы, обучение и рост), природой организации и природой процессов и средств, подходящих для измерения показателей. Эти показатели называются Ключевыми показателями эффективности, или KPI.Данная статья содержит в себе практические советы по составлению системы показателей вашего проекта и выбору сопровождающих ее показателей, а не теорию систем сбалансированных показателей и KPI. ^ 10.4 Система сбалансированных показателей (BSC) Системы сбалансированных показателей были предназначены для измерения качества работы во всех сферах организации, а не только качества работы по проекту. Проекты могут подпадать под любую из 4 областей качества работы, или даже под несколько, но учтен будет только один аспект качества работы организации. Использование организацией BSC определенно повлияет на разработку системы показателей проекта, но система показателей проекта не может дублировать формат BSC, потому что доступная информация не удовлетворяет требованиям BSC.Системы сбалансированных показателей, или BSC, были разработаны и представлены Дэвидом П. Нортоном и Робертом С. Капланом в 1992, чтобы дополнить ограниченное представление об эффективности работы организации, предоставляемое измерительными инструментами в прошлом. Производительность работы измерялась на основе финансов, и недостатком измерения финансовых показателей было то, что оно не учитывало другие элементы производительности работы.^ 11.2 CASE-системы как средства автоматизации разработки систем.В современных информационных технологиях важное место отводится инструментальным средствам и средам разработки ^ АИС и, в частности, системам разработки и сопровождения их ПО. Эти технологии и среды образуют системы, называемые CASE-системами.Используется двоякое толкование аббревиатуры CASE, соответствующее двум направлениям использования CASE-систем. Первое из них — Computer Aided Software Engineering — переводится как автоматизированное проектирование программного обеспечения, соответствующие CASE-системы часто называют инструментальными средами разработки ПО (RAD — Rapid Application Development). Второе — Computer Aided System Engineering — подчеркивает направленность на поддержку концептуального проектирования сложных систем, преимущественно слабоструктурированных. Такие CASE-системы часто называют системами BPR (Business Process Reengineering).11.2 Инструментальные системы разработки программного обеспечения. Среди систем RAD различают интегрированные комплексы инструментальных средств для автоматизации всех этапов жизненного цикла ПО (такие системы называют Workbench) и специализированные инструментальные средства для выполнения отдельных функций (Tools). Средства CASE по своему функциональному назначению принадлежат к одной из следующих групп: 1) средства программирования; 2) средства управления программным проектом; 3) средства верификации (анализа) программ; 4) средства документирования.Проектирование ПО с помощью CASE систем включает несколько этапов. Начальный этап — предварительное изучение проблемы. Результат представляется в виде исходной диаграммы потоков данных и согласуется с заказчиком. На следующем этапе выполняется детализация ограничений и функций программной системы, полученная логическая модель вновь согласуется с заказчиком. Далее разрабатывается физическая модель, т. е. определяется модульная структура программы, выполняется инфологическое проектирование базы данных, детализируются граф-схемы программной системы и ее модулей, проектируется пользовательских интерфейс.^ 11.3 Классификация CASE-систем Прежде всего, CASE-системы классифицируются по уровням или этапам разработки программ, которые они охватывают, то есть, по содержащимся в них средствам, служащим для работы над тем или иным этапом разработки. CASE-системы поддерживают работы по уточнению постановки задачи и анализу проектируемых систем, в ходе которых составляются, корректируются и анализируются спецификации систем. Так как эти системы соответствуют наиболее общим понятиям термина CASE, их называют еще нормальными. К таким системам можно отнести продукт BPWin фирмы ``Logic Works''. CASE-системы, напротив, поддерживают работы по непосредственному проектированию программ, следующие за системным анализом, а также в той или иной степени собственно построение программ, кодирование, генерацию кода. Особое распространение нижние CASE-системы получили в области разработки структур баз данных и визульных объектов приложений. Ярким примером нижней CASE-системы является ERWin фирмы ``Logic Works'', позволяющий разрабатывать модели баз данных, включающих таблицы, различного рода связи, внешние ссылки, индексы, триггерные процедуры и прочие объекты, для наиболее популярных серверов баз данных. Иногда выделяют границу между верхними и нижними системами, вводя ``'' CASE-системы, которые служат как бы связующим звеном между верхними и нижними системами. Другой мерой классификации CASE-систем может стать степень интегрированности в средства разработки и полнота. Здесь можно различить слабо интегрированные узко специальные CASE-системы, которые удачно можно обозначить термином toolkit, а так же сильно интегрированные и более полные системы - workbench. Как правило, CASE-средства разработки поставляются третьими фирмами в дополнение к пакетам разработки программ, поэтому речь и заходит о степени интегрированности. Особенно это заметно на примере Borland Delphi 2.0. ^ 11.4 Методы спецификации программ в CASE-системах Методологической основой верхних CASE-систем являются методы спецификации программ, то есть, описания задачи, которую должна решать программа. Для того, чтобы спецификация могла быть проанализирована системой, она должна иметь определенный язык, описание должно придерживаться определенных правил. Выше было много сказано о способах специфицирования. Рассмотрим средства спецификации, применяемые в CASE-системах. Кстати, эти средства могут применяться не только для специфицирования программ, но и описания и анализа таких отраслей деятельности, как бизнес (примером CASE-системы, ориентированной на анализ и оптимизацию бизнес-процессов, является BPWin). Для удобства и простоты работы, в CASE-системах используются графические языки спецификаций и описания процессов и структур данных. Наиболее распространенными являются: диаграммы потоков данных (data flow diagram); диаграммы объектов-связей, называемые еще диаграммами ``сущность-связь'' (ER-диаграммы, entity relation diagram); диаграммы переходов-состояний (state transition diagram). Для описания иерархических структур широко используются разнообразные деревья. Диаграмма потоков данных применяется, как правило, для описания систем обработки данных в бизнесе, ER-диаграммы используются при описании информационных структур баз данных, диаграммы переходов-состояний служат для описания систем реального времени. ^ 11.4 Диаграмма потоков данных Такая диаграмма состоит из трех типов узлов: узлов обработки данных, узлов хранения данных и внешних узлов, представляющих внешние, по отношению к используемой диаграмме, источники или потребители данных. Дуги в диаграмме соответствуют потокам данных, передаваемых от узла к узлу. Они помечены именами соответствующих данных. Описание процесса, функции или системы обработки данных, соответствующих узлу диаграммы, может быть представлено диаграммой следующего уровня детализации, если процесс достаточно сложен. Развертка диаграмм одного уровня детализации представляется в виде дерева разверток, напоминающего диаграмму Джексона. Другим аналогом дерева развертки является HIPO-технология. ^ Диаграмма сущностей-связей Такая диаграмма содержит узлы двух типов: для объектов (сущностей) и для связей. Дуги соединяют узел отношение с его аргументами. Классическим примером использования диаграмм сущностей-связей является описание концептуальных моделей в базах данных. Продемонстрируем потенциальные возможности использования ER-диаграмм в этом разрезе: Здесь схематично изображена модель базы данных больницы. Узлы-прямоугольники являются сущностями, а узлы со скругленными углами - связями. ^ Диаграмма переходов-состояний В диаграммах такого вида узлы соответствуют состояниям динамической системы, а дуги - переходу системы из одного состояния в другое. Узел, из которого выходит дуга, является начальным состоянием, узел, в который дуга входит - следующим. Дуга помечается именем входного сигнала или события, вызывающего переход, а так же сигналом или действием, сопровождающим переход. На рисунке приведен возможный пример состояний двигателя автомобиля в зависимости от состояния управления. ^ 11.5 Объектно-ориентированные CASE-средства (Rational Rose) Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации [21]. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и