Экономические информационные системы

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

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

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

- первый цикл, включающий блоки 1-12, - это цикл первичного проектирования ЭИС;

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

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

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

- пятый цикл (блоки: 12, 1-12) возникает, если проект системы совершенно не соответствует требованиям, предъявляемым к организационно-экономической системе ввиду того, что осуществляется моральное его старение и требуется полное перепроектирование системы.

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

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

- требования к ЭИС должны адекватно соответствовать целям и задачам эффективного функционирования экономического объекта;

- созданная ЭИС должна соответствовать сформулированным требованиям на момент окончания внедрения, а не на момент начала разработки;

- внедренная ЭИС должна развиваться и адаптироваться в соответствии с постоянно изменяющимися требованиями к ЭИС.

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

- каскадная модель (до 70-х годов) -- последовательный переход на следующий этап после завершения предыдущего;

- итерационная модель (70 - 80-е годы) - с итерационными возвратами на предыдущие этапы после выполнения очередного этапа;

- спиральная модель (80 - 90-е годы) - прототипная модель, предполагающая постепенное расширение прототипа ЭИС.

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

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

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

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

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

- анализ и планирование информационной стратегии. Пользователи вместе со специалистами-разработчиками участвуют в идентификации проблемной области;

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

- конструирование. Специалисты-разработчики проектируют рабочую версию ЭИС с использованием объектно-ориентированных языков;

- внедрение. Специалисты-разработчики обучают пользователей работе в среде новой ЭИС.

19. Известные модели ЖЦ

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

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

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

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

20. Формализация технологии проектирования

Основой формализации технологии проектирования ЭИС является формальное определение технологической операции (ТО).

Графическая интерпретация технологической операции представлена на рис. 2.3.

Графическая интерпретация технологической операции

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

В качестве компонентов входа и выхода используются множества документов D, параметров Р, программ G, универсальных множеств (универсумов) U. Для любых компонентов входа и выхода должны быть заданы формы их представления в виде твердой копии или электронном виде.

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

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

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

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

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

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

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

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

Ряс. 2.4. Технологическая сеть проектирования

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

Для укрупнения ТСП применяются технологические операции-агрегаты, которым соответствуют фрагменты канонической ТСП. Например, ТО «Проектирование схемы базы данных» декомпозируется на ряд взаимосвязанных ТО: «Нормализация таблиц», «Установление связей».

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

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

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

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

21.Состав стадий и этапов канонического проектирования

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

В основе канонического проектирования лежит каскадная модель жизненного цикла ЭИС. Процесс каскадного проектирования делится на следующие семь стадий:

- исследование и обоснование создания системы;

- разработка технического задания;

- создание эскизного проекта;

- техническое проектирование;

- рабочее проектирование;

- ввод в действие;

- функционирование, сопровождение, модернизация.

В целях изучения взаимосвязанных приемов и методов канонического проектирования ЭИС перечисленные стадии группируются в часто используемые на практике 4 стадии процесса разработки ЭИС (рис. 3.1):

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

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

- стадия внедрения;

- стадия эксплуатации и сопровождения.

Рис. 3.1. ТСП стадий и этапов канонического проектирования ЭИС:

Д 1.1 - предметная область; Д1.2 - материалы обследования; Д1.3 -ТЗ на проектирование; Д 1.4 -эскизный проект; Д2.1 - техно-рабочий проект (ТРП); Д3.1 - исправленный ТРП, переданный в эксплуатацию; Д3.2 - акт о приемке проекта в промышленную эксплуатацию; Д4,1 - модернизированный ТРП.

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

На первой «Предпроектной стадии» выделяют два основных этапа: сбор материалов обследования; анализ материалов обследования и разработка технико-экономического обоснования (ТЭО) и технического задания (ТЗ).

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

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

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

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

Вторая стадия «Техно-рабочее проектирование» выполняется в два этапа: техническое проектирование и рабочее проектирование.

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

Третья стадия «Внедрение проекта» включает в себя три этапа: подготовка объекта к внедрению проекта; опытное внедрение проекта и сдача его в промышленную эксплуатацию.

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

Четвертая стадия - «Эксплуатация и сопровождение проекта» включает этапы: эксплуатация проекта; сопровождение и модернизация проекта.

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

22. CASE-средства. Общая характеристика и классификация. CASE-технологии создания и сопровождения ЭИС

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

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

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

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

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

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

Интегрированное CASE-средство содержит следующие компоненты;

· репозиторий, являющийся основой CASE-средства;

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

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

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

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

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

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

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

Размещено на Allbest.ru