ЭЛЕКТРОННЫЙ КОНСПЕКТ ЛЕКЦИЙ
ПО ДИСЦИПЛИНЕ
«ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ»
© Захарченков Константин Васильевич
Жизненный цикл программного обеспечения 6
Модели жизненного цикла программного обеспечения 7
Макетирование 10
Спиральная модель жизненного цикла 11
Компонентно-ориентированная модель 13
Тема 2. Структурный анализ и проектирование 15
Определение структурного анализа 15
Средства структурного анализа 17
Моделирование потоков данных 18
Контекстная диаграмма 20
Построение иерархии диаграмм потоков данных 21
Методология функционально стоимостного анализа 21
Методология функционального моделирования SADT (Structured Analysis AND Design Technique) 22
Состав функциональной модели SADT 23
Иерархия диаграмм 24
Словарь данных 26
Тема 3. Построение информационной модели системы. Проектирование баз данных 28
Диаграммы сущность-связь (ERD) 28
Сущности, отношения и связи в нотации Чена 28
Типы связей в нотации Чена 30
Ассоциативная связь 30
Диаграммы атрибутов в классической модели Чена 31
Нотация Баркера. Модель сущность- связь в нотации Баркера 32
Методология IDEF1X 34
Тема 4. Методика построения информационной модели данных (модели «сущность-связь») 37
Идентификация отношений между сущностями 38
Разрешение неспецифических отношений 38
Использование средств и техники структурного системного анализа 38
Подход Мартина (IE–методология) 41
Тема 5. Методология RAD (Rapid Application Development) 43
Основные принципы методологии RAD 45
Состав, структура и функциональные особенности case-средств 46
Поддержка графических моделей 47
Требования к современному диаграммеру 47
Тема 6. Структурное тестирование программного обеспечения 49
Основные понятия и принципы тестирования программного обеспечения 49
Особенности тестирования белого ящика 52
Способ тестирования базового пути 53
Потоковый граф 53
Цикломатическая сложность 54
Шаги способа тестирования базового пути 55
Способы тестирования условий 55
Тестирование ветвей и операторов отношения 56
Способ тестирования потоков данных 57
Тестирование циклов 59
Тема 7. Функциональное тестирование программного обеспечения 64
Особенности тестирования черного ящика 64
Способы разбиения на эквивалентности 65
Способ анализа граничных значений 66
Способ диаграмм причин–следствий 67
Тема 8. Организация процесса тестирования программного обеспечения 70
Методика тестирования программных систем 70
Тестирование элементов 71
Тестирование итераций 73
Восходящее тестирование интеграции 75
Тестирование правильности 75
Системное тестирование 77
Тема 1. Введение. Основы методологии проектирования информационных систем
Тенденция развития информационных систем приводит к возрастанию их сложности. Современные крупные проекты характеризуются следующими особенностями:
сложность описания, требующая тщательного моделирования и анализа данных и процессов;
наличие тесно взаимодействующих компонентов;
отсутствие прямых аналогов ограничивает возможность использования типовых решений;
необходимость интеграций существующих и разрабатываемых приложений;
функционирование в неоднородной среде различных аппаратных программных платформ;
разнородность отдельных групп разработчиков по уровню квалификации и традициям использования тех или иных инструментальных средств;
существенная временная протяженность проекта, которая обусловлена, во-первых, ограниченными возможностями коллектива разработчиков, во-вторых, степенью готовности подразделений и организаций к внедрению информационной системы.
Для успешной реализации проекта информационной системы объект проектирования должен быть адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели системы.
До недавнего времени проектирование информационных систем выполнялось на интуитивном уровне с использованием неформализованных методов, то есть методов, основанных на практическом опыте, экспертных оценках и дорогостоящих экспериментальных проектах качества информационных систем.
В процессе создания информационных систем потребности пользователей могут изменяться, что значительно усложняет разработку.
В 70-80-х годах при разработке информационных систем применялась структурная методология, для описания разных моделей информационных систем использовались различные схемы и диаграммы. Однако широкое применение этой методологии встречалось достаточно редко, поскольку вручную очень трудно разработать и графически представить спецификации системы, проверить их на полноту и противоречивость и тем более сложно вносить в эти спецификации изменения.
Ручная разработка приводила к следующим проблемам:
сложно обнаруживать ошибки в проектных решениях;
документация имеет низкое качество;
тестирование требует длительного времени и часто дает неудовлетворительные результаты.
В настоящее время снято большинство аппаратных ограничений на решение задач. Оставшиеся ограничения приходятся на долю программного обеспечения.
Чрезвычайно актуальными в последнее время стали следующие проблемы:
аппаратная сложность значительно опережает умения разработчиков строить программное обеспечение, использующее потенциальные возможности аппаратуры;
умение разработчиков строить новые программы отстает от требований к новым программам;
возможности пользователей эксплуатировать существующие программы угрожает низкое качество их разработки.
Ключом решения этих проблем является грамотная организация процесса создания программного обеспечения, реализация технологических принципов промышленного конструирования информационных систем. Эти же проблемы способствовали появлению программных технологических средств социального класса, так называемых case(Computer Aided Software Engineering)-средств.
Case-средства реализует case-технология создания и сопровождения информационных систем.
Под термином case -средства понимают программные средства, поддерживающие этапы анализа и формулировки требований к системе, проектирование прикладного программного обеспечения и баз данных, автоматическую генерацию кода, тестирование, документирование, управление конфигурацией информационной системы и управление проектом.
Case -технология представляет собой методологию проектирования информационных систем, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область. Она также позволяет анализировать эту модель на всех этапах разработки и разрабатывать приложения в соответствии с потребностями пользователей.
Большинство существующих case-средств основано на методологиях структурного анализа и проектирования, которые используют спецификации в виде диаграмм для описания внешних требований, связи между моделями, динамики поведения системы и архитектуры программных средств.
Использование case-средств дает разработчику следующие преимущества:
улучшается качество программного обеспечения за счет средств автоматического контроля проекта;
за короткое время можно получить прототип создаваемой системы. Это позволяет на ранних этапах проектирования оценить ожидаемый результат;
освобождение разработчика от рутинной работы;
поддержка сопровождения программного обеспечения.
Процесс моделирования предметной области при проектировании ИС может быть реализован в рамках различных методологий, отличающихся подходом к тому, что представляет собой моделируемая область. В соответствии с различными представлениями методологии принято делить на объектные и функциональные (структурные).
Объектные методологии рассматривают моделируемую предметную область как набор взаимодействующих объектов – производственных единиц. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Целью применения данной методологии является выделение объектов, составляющих организацию, и распределение между ними ответственностей за выполняемые действия. Объектно-ориентированная методология описывает предметную область в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Концептуальной основой объектно-ориентированного подхода является объектная модель, которая строится с учетом следующих принципов: абстрагирование; инкапсуляция; модульность; иерархия; типизация; параллелизм; устойчивость. Основными понятиями объектно-ориентированного подхода являются объект и класс. Объект – предмет или явление, имеющее четко определенное поведение и обладающий состоянием, поведением и индивидуальностью. Структура и поведение схожих объектов определяют общий для них класс. Класс – это множество объектов, связанных общностью структуры и поведения. Понятие полиморфизм может быть интерпретировано, как способность класса принадлежать более чем одному типу. Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов.
Важным качеством объектного подхода является согласованность моделей деятельности организации и моделей проектируемой информационной системы от стадии формирования требований до стадии реализации. По объектным моделям может быть прослежено отображение реальных сущностей моделируемой предметной области (организации) в объекты и классы информационной системы. Большинство существующих методов объектно-ориентированного подхода включают язык моделирования и описание процесса моделирования. Процесс – это описание шагов, которые необходимо выполнить при разработке проекта. В качестве языка моделирования объектного подхода используется унифицированный язык моделирования UML, который содержит стандартный набор диаграмм для моделирования.
Диаграмма (Diagram) – это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями) и представляет собой некоторую проекцию системы (рис.4).
Объектно-ориентированный подход обладает следующими преимуществами:
Дает возможность создавать модели меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств;
Позволяет избежать создания сложных моделей;
Ориентирован на человеческое восприятие мира.
Рис.4
К недостаткам объектно-ориентированного подхода относятся высокие затраты, т.к. подход не дает немедленной отдачи. Эффект от его применения сказывается после разработки двух-трех проектов и накопления повторно используемых компонентов. Диаграммы, отражающие специфику объектного подхода, менее наглядны.
Функциональные методологии , наиболее известной из которых является методика IDEF, рассматривают предметную область как набор функций , преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методологии заключается в четком отделении функций от самих данных.
Каждый из подходов обладает своими преимуществами. Объектный подход позволяет построить более устойчивую к изменениям систему, лучше соответствует существующим структурам организации. Функциональное моделирование хорошо показывает себя в тех случаях, когда организационная структура находится в процессе изменения или вообще слабо оформлена. Подход от выполняемых функций интуитивно лучше понимается исполнителями при получении от них информации об их текущей работе.
Функциональная методика IDEF0
Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST). Целью методики является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы. В основе методологии лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий.
Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении. На диаграмме функциональный блок изображается прямоугольником (рис. 5). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:
Верхняя сторона имеет значение «Управление» (Control);
Левая сторона имеет значение «Вход» (Input);
Правая сторона имеет значение «Выход» (Output);
Нижняя сторона имеет значение «Механизм» (Mechanism).
Рис. 5. Функциональный блок
Интерфейсная дуга (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию , представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками. С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального или потоки данных и информации (документы, данные, инструкции и т.д.). В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей».
Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Т.к. каждый процесс должен происходить по каким-то правилам и должен выдавать некоторый результат, иначе его рассмотрение не имеет никакого смысла. Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).
Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции . При этом уровень детализации процесса определяется непосредственно разработчиком модели. Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой (рис. 6)
В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы, и называется дочерней (Child Diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком – Child Box).
Рис.6
В свою очередь, функциональный блок – предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0-модели (рис. 7).
Рис.7
Обычно IDEF0-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в стандарте приняты соответствующие ограничения сложности. Рекомендуется представлять на диаграмме от трех до шести функциональных блоков, при этом количество подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг предполагается не более четырех.
Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее создания, а также эффективной для проведения показов и презентаций. В дальнейшем на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений в модели.
Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram – DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы). Диаграммы потоков данных являются одним из основных инструментов структурного анализа и проектирования информационных систем, моделирования функциональных требований к проектируемой системе.
При создании диаграммы потоков данных используются четыре основных понятия: потоки данных, процессы (работы) преобразования входных потоков данных в выходные, внешние сущности, накопители данных (хранилища).
Потоки данных являются абстракциями, использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации.
Назначение процесса (работы) состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением. Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.
Хранилище (накопитель) данных позволяет на указанных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть существительным.
Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником системных данных. Ее имя должно содержать существительное. Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке (рис. 8).
Рис.8
Кроме основных элементов, в состав DFD входят словари данных и спецификации. Словари данных являются каталогами всех элементов данных, присутствующих в DFD, включая групповые и индивидуальные потоки данных, хранилища и процессы, а также все их атрибуты. Спецификации обработки – описывают DFD-процессы. Фактически спецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех спецификаций является полной спецификацией системы.
Процесс построения DFD начинается с создания так называемой основной диаграммы типа «звезда», на которой представлен моделируемый процесс и все внешние сущности, с которыми он взаимодействует. В случае сложного основного процесса он сразу представляется в виде декомпозиции на ряд взаимодействующих процессов. Декомпозиция завершается, когда процесс становится простым, т.е. процесс:
1) имеет два-три входных и выходных потока;
2) может быть описан в виде преобразования входных данных в выходные;
3) может быть описан в виде последовательного алгоритма.
Для простых процессов строится спецификация – формальное описание алгоритма преобразования входных данных в выходные. Спецификация удовлетворяет следующим требованиям: для каждого процесса строится одна спецификация; спецификация однозначно определяет входные и выходные потоки для данного процесса; спецификация не определяет способ преобразования входных потоков в выходные; спецификация ссылается на имеющиеся элементы, не вводя новые; спецификация по возможности использует стандартные подходы и операции .
После построения диаграмма должна быть проверена на полноту и непротиворечивость. Полнота диаграммы обеспечивается, если в системе нет «повисших» процессов, не используемых в процессе преобразования входных потоков в выходные. Непротиворечивость системы обеспечивается выполнением наборов формальных правил о возможных типах процессов: на диаграмме не может быть потока, связывающего две внешние сущности – это взаимодействие удаляется из рассмотрения; ни одна сущность не может непосредственно получать или отдавать информацию в хранилище данных – хранилище данных является пассивным элементом, управляемым с помощью интерфейсного процесса; два хранилища данных не могут непосредственно обмениваться информацией – эти хранилища должны быть объединены.
К преимуществам методики DFD относятся:
Возможность проектирования сверху вниз, что облегчает построение модели «как должно быть»;
Наличие спецификаций процессов нижнего уровня позволяет преодолеть логическую незавершенность функциональной модели и построить полную функциональную спецификацию разрабатываемой системы.
Функциональная методика ERD
Диаграммы «сущность-связь» (ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).
Сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр Т.е. сущности представляют собой базовые типы информации, хранимой в базе данных.
Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Сущность должна обладать некоторыми свойствами:
Каждая сущность должна иметь уникальное имя, к одному имени должна применяться только одна интерпретация. Одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;
Сущность обладает атрибутами, которые принадлежат сущности, либо наследуются через связь;
Сущность обладает атрибутами, которые однозначно идентифицируют каждый экземпляр сущности;
Каждая сущность может обладать любым количеством связей с другими сущностями модели.
Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются Связи . Каждая связь соединяет сущности, при этом каждый экземпляр одной сущности ассоциирован с произвольным количеством экземпляров второй сущности, и наоборот. Пара значений связей, принадлежащих одному и тому же отношению, определяет тип этого отношения. Практика показала, что для большинства приложений достаточно использовать следующие типы отношений:
1) 1*1 (один-к-одному). Используются, как правило, на верхних уровнях иерархии модели данных.
2) 1*n (один-к-многим). Являются наиболее часто используемыми.
3) n*m (многие-к-многим). Используются на ранних этапах проектирования с целью прояснения ситуации.
В некоторых нотациях отношения именуются. Именование связей осуществляется с помощью грамматического оборота глагола (имеет, определяет и т.п.). Введение подобных отношений преследует две основополагающие цели:
Обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях);
Использование этой информации различными приложениями.
Рис. 9
Каждая сущность обладает одним или несколькими атрибутами , которые однозначно идентифицируют каждый экземпляр сущности. Атрибут определяет тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов (людей, мест, событий, предметов и т.д.). Экземпляр атрибута – это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характристики и ее значением – значением атрибута. При этом любой атрибут может быть определен как ключевой.
Детализация сущности осуществляется с использованием диаграмм атрибутов, которые раскрывают ассоциированные сущностью атрибуты. Диаграмма атрибутов состоит из детализируемой сущности, соответствующих атрибутов и доменов, описывающих области значений атрибутов. На диаграмме каждый атрибут представляется в виде связи между сущностью и соответствующим доменом, являющимся графическим представлением множества возможных значений атрибута. Все атрибутные связи имеют значения на своем окончании (рис.9).
Методология составляет основу проекта любой информационной системы. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые позволяют выполнять все процессы жизненного цикла.
Существует две основных методологии проектирования:
Методология структурного проектирования;
Методология объектно-ориентированного проектирования.
Структурный подход. Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов .
Все компоненты информационной системы взаимосвязаны, система разрабатывается сверху вниз. При разработке системы снизу - вверх целостность теряется, возникают проблемы состыковки компонентов.
Наиболее распространенные модели структурного подхода:
SADT - Structured Analysis and Design Techniques - описывает модели и функциональные диаграммы;
DFD - Data Flow Diagrams - диаграммы потоков данных;
ERD - Entity Relationship Diagrams - диаграммы «сущность - связь».
На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм .
Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.
Объектно-ориентированный подход. Центральным понятием объектно-ориентированного подхода к проектированию является класс. Класс - это выделение из окружающего мира некой сущности, для которой определены атрибуты (свойства) и операции (действия, которые сущность производит над окружающими объектами).
Объект - это конкретная реализация некоторой сущности. В объекте инкапсулируется некоторая часть приложения, которая может представлять собой процесс, группу данных или какую-либо более сложную сущность .
Для реализации проекта был выбран объектно-ориентированный подход в силу следующих факторов:
Возможность повторного использования кода;
Повышение безопасности кода за счет инкапсуляции;
Гибкость при модификации и расширении системы;
Отсутствие необходимости разработки классов с нуля, за счет наследования;
Общая ориентированность объектно-ориентированной технологии на разработку информационных систем, как класса программного обеспечения и т.д.
Индустрия разработки автоматизированных информационных систем управления зародилась в 1950-х - 1960-х годах и к концу века приобрела вполне законченные формы.
На первом этапе основным подходом в проектировании ИС был метод "снизу-вверх ", когда система создавалась как набор приложений, наиболее важных в данный момент для поддержки деятельности предприятия. Основной целью этих проектов было не создание тиражируемых продуктов, а обслуживание текущих потребностей конкретного учреждения. Такой подход отчасти сохраняется и сегодня. В рамках "лоскутной автоматизации" достаточно хорошо обеспечивается поддержка отдельных функций, но практически полностью отсутствует стратегия развития комплексной системы автоматизации, а объединение функциональных подсистем превращается в самостоятельную и достаточно сложную проблему.
Создавая свои отделы и управления автоматизации, предприятия пытались "обустроиться" своими силами. Однако периодические изменения технологий работы и должностных инструкций, сложности, связанные с разными представлениями пользователей об одних и тех же данных, приводили к непрерывным доработкам программных продуктов для удовлетворения все новых и новых пожеланий отдельных работников. Как следствие - и работа программистов, и создаваемые ИС вызывали недовольство руководителей и пользователей системы.
Следующий этап связан с осознанием того факта, что существует потребность в достаточно стандартных программных средствах автоматизации деятельности различных учреждений и предприятий. Из всего спектра проблем разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов. Системы начали проектироваться "сверху-вниз", т.е. в предположении, что одна программа должна удовлетворять потребности многих пользователей.
Сама идея использования универсальной программы накладывает существенные ограничения на возможности разработчиков по формированию структуры базы данных, экранных форм, по выбору алгоритмов расчета. Заложенные "сверху" жесткие рамки не дают возможности гибко адаптировать систему к специфике деятельности конкретного предприятия: учесть необходимую глубину аналитического и производственно-технологического учета, включить необходимые процедуры обработки данных, обеспечить интерфейс каждого рабочего места с учетом функций и технологии работы конкретного пользователя. Решение этих задач требует серьезных доработок системы. Таким образом, материальные и временные затраты на внедрение системы и ее доводку под требования заказчика обычно значительно превышают запланированные показатели.
Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.
В то же время, заказчики ИС стали выдвигать все больше требований, направленных на обеспечение возможности комплексного использования корпоративных данных в управлении и планировании своей деятельности.
Таким образом, возникла насущная необходимость формирования новой методологии построения информационных систем.
Цель такой методологии заключается в регламентации процесса проектирования ИС и обеспечении управления этим процессом с тем, чтобы гарантировать выполнение требований как к самой ИС, так и к характеристикам процесса разработки . Основными задачами, решению которых должна способствовать методология проектирования корпоративных ИС, являются следующие:
Внедрение методологии должно приводить к снижению сложности процесса создания ИС за счет полного и точного описания этого процесса, а также применения современных методов и технологий создания ИС на всем жизненном цикле ИС - от замысла до реализации
Проектирование ИС охватывает три основные области:
Проектирование информационных систем всегда начинается с определения цели проекта . В общем виде цель проекта можно определить как решение ряда взаимосвязанных задач, включающих в себя обеспечение на момент запуска системы и в течение всего времени ее эксплуатации:
Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются специфичные для него модели - организации, требований к ИС, проекта ИС, требований к приложениям и т.д. Модели формируются рабочими группами команды проекта, сохраняются и накапливаются в репозитории проекта. Создание моделей, их контроль, преобразование и предоставление в коллективное пользование осуществляется с использованием специальных программных инструментов - CASE-средств.
Процесс создания ИС делится на ряд этапов (стадий ), ограниченных некоторыми временными рамками и заканчивающихся выпуском конкретного продукта (моделей, программных продуктов, документации и пр.).
Обычно выделяют следующие этапы создания ИС : формирование требований к системе, проектирование, реализация, тестирование, ввод в действие, эксплуатация и сопровождение . (Последние два этапа далее не рассматриваются, поскольку выходят за рамки тематики книги.)
Начальным этапом процесса создания ИС является моделирование бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Модель организации, описанная в терминах бизнес-процессов и бизнес-функций, позволяет сформулировать основные требования к ИС. Это фундаментальное положение методологии обеспечивает объективность в выработке требований к проектированию системы. Множество моделей описания требований к ИС затем преобразуется в систему моделей, описывающих концептуальный проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция.
Целью начальных этапов создания ИС , выполняемых на стадии анализа деятельности организации , является формирование требований к ИС, корректно и точно отражающих цели и задачи организации-заказчика. Чтобы специфицировать процесс создания ИС, отвечающей потребностям организации, нужно выяснить и четко сформулировать, в чем заключаются эти потребности. Для этого необходимо определить требования заказчиков к ИС и отобразить их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и задачам организации.
Задача формирования требований к ИС является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. Современные инструментальные средства и программные продукты позволяют достаточно быстро создавать ИС по готовым требованиям. Но зачастую эти системы не удовлетворяют заказчиков, требуют многочисленных доработок, что приводит к резкому удорожанию фактической стоимости ИС. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС на этапе анализа.
На этапе проектирования прежде всего формируются модели данных. Проектировщики в качестве исходной информации получают результаты анализа. Построение логической и физической моделей данных является основной частью проектирования базы данных. Полученная в процессе анализа информационная модель сначала преобразуется в логическую, а затем в физическую модель данных.
Параллельно с проектированием схемы базы данных выполняется проектирование процессов, чтобы получить спецификации (описания) всех модулей ИС. Оба эти процесса проектирования тесно связаны, поскольку часть бизнес-логики обычно реализуется в базе данных (ограничения, триггеры, хранимые процедуры). Главная цель проектирования процессов заключается в отображении функций, полученных на этапе анализа, в модули информационной системы. При проектировании модулей определяют интерфейсы программ: разметку меню, вид окон, горячие клавиши и связанные с ними вызовы.
Конечными продуктами этапа проектирования являются:
Кроме того, на этапе проектирования осуществляется также разработка архитектуры ИС, включающая в себя выбор платформы (платформ) и операционной системы (операционных систем). В неоднородной ИС могут работать несколько компьютеров на разных аппаратных платформах и под управлением различных операционных систем. Кроме выбора платформы, на этапе проектирования определяются следующие характеристики архитектуры:
Этап проектирования завершается разработкой технического проекта ИС.
На этапе реализации осуществляется создание программного обеспечения системы, установка технических средств, разработка эксплуатационной документации.
Этап тестирования обычно оказывается распределенным во времени.
После завершения разработки отдельного модуля системы выполняют автономный тест, который преследует две основные цели:
После того как автономный тест успешно пройдет, модуль включается в состав разработанной части системы и группа сгенерированных модулей проходит тесты связей, которые должны отследить их взаимное влияние.
Далее группа модулей тестируется на надежность работы, то есть проходят, во-первых, тесты имитации отказов системы, а во-вторых, тесты наработки на отказ. Первая группа тестов показывает, насколько хорошо система восстанавливается после сбоев программного обеспечения, отказов аппаратного обеспечения. Вторая группа тестов определяет степень устойчивости системы при штатной работе и позволяет оценить время безотказной работы системы. В комплект тестов устойчивости должны входить тесты, имитирующие пиковую нагрузку на систему.
Затем весь комплект модулей проходит системный тест - тест внутренней приемки продукта, показывающий уровень его качества. Сюда входят тесты функциональности и тесты надежности системы.
Последний тест информационной системы - приемо-сдаточные испытания. Такой тест предусматривает показ информационной системы заказчику и должен содержать группу тестов, моделирующих реальные бизнес-процессы, чтобы показать соответствие реализации требованиям заказчика.
Необходимость контролировать процесс создания ИС, гарантировать достижение целей разработки и соблюдение различных ограничений (бюджетных, временных и пр.) привело к широкому использованию в этой сфере методов и средств программной инженерии: структурного анализа, объектно-ориентированного моделирования, CASE-систем.
На рынке автоматизированных систем для крупных корпораций и финансово-промышленных групп на сегодня можно выделить два основных субъекта: это ранок автоматизированных банковских систем (АБС) и рынок корпоративных информационных систем промышленных предприятий. Не смотря на сильную взаимосвязь этих двух рынков систем автоматизации, предлагаемые на них решения пока еще не достаточно интегрированы между собой, чего следует ожидать в недалеком будущем.
В дальнейшем под Автоматизированной Банковской Системой (АБС) будем понимать комплекс аппаратно-программных средств реализующих мультивалютную информационную систему, обеспечивающую современные финансовые и управленческие технологии в режиме реального времени при транзакционной обработке данных.
Под Автоматизированной Информационной Системой промышленного предприятия (АСУ КТП) будем понимать комплекс аппаратно-программных средств реализующих мультикомпонентную информационную систему, обеспечивающую современное управление процессами принятия решений, проектирования, производства и сбыта в режиме реального времени при транзакционной обработке данных.
Как вы видите, оба определения достаточно схожи. На сегодня существования нескольких методов построения автоматизированных информационных систем (АИС), среди которых можно выделить следующие:
Метод "снизу-вверх". Менталитет российских программистов сформировался именно в крупных вычислительных центрах (ВЦ), основной целью которых было не создание тиражируемых продуктов, а обслуживание сотрудников конкретного учреждения. Этот подход во многом сохранялся и при автоматизации и сегодня. В условиях постоянно изменяющихся законодательства, правил ведения производственной, финансово-хозяйственной деятельности и бухгалтерского учета руководителю удобно иметь рядом посредника между спущенной сверху новой инструкцией и компьютером. С другой стороны, программистов, зараженных "вирусом самодеятельности", оказалось предостаточно, тем более что за такую работу предлагалось вполне приличное вознаграждение. Создавая свои отделы и управления автоматизации, предприятия и банки пытались обустроиться своими силами. Однако периодическое "перетряхивание" инструкций, сложности, связанные с разными представлениями пользователей об одних и тех же данных, непрерывная работа программистов по удовлетворению все новых и новых пожеланий отдельных работников и как следствие – недовольство руководителей своими программистами несколько остудило пыл как тех, так и других. Итак, первый подход сводился к проектированию "снизу-вверх" . В этом случае, при наличии квалифицированного штата программистов, вполне сносно были автоматизированы отдельные, важные с точки зрения руководства рабочие места. Общая же картина "автоматизированного предприятия" просматривалась недостаточно хорошо, особенно в перспективе.
Метод "сверху-вниз". Быстрый рост числа акционерных и частных предприятий и банков позволил некоторым компаниям увидеть здесь будущий рынок и инвестировать средства в создание программного аппарата для этого растущего рынка. Из всего спектра проблем разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов (для банков это в основном – расчетно-кассовое обслуживание, для промышленных предприятий – автоматизация процессов проектирования и производства, имеется в виду не конкретных станков и т. п., а информационных потоков). Учитывая тот факт, что ядром АИС безусловно является аппарат, обеспечивающий автоматизированное ведение аналитического учета, большинство фирм начали с детальной проработки данной проблемы. Системы были спроектированы "сверху", т.е. в предположении что одна программа должна удовлетворять потребности всех пользователей.
Сама идея использования "одной программы для всех" резко ограничила возможности разработчиков в структуре информационных множеств базы данных, использовании вариантов экранных форм, алгоритмов расчета и, следовательно, лишила возможности принципиально расширить круг решаемых задач – автоматизировать повседневную деятельность каждого работника. Заложенные "сверху" жесткие рамки ("общие для всех") ограничивали возможности таких систем по ведению глубокого, часто специфического аналитического и производственно – технологического учета. Работники проводили эту работу вручную, а результаты вводили в компьютер. При этом интерфейс каждого рабочего места не мог быть определен функциями, возложенными на пользователя, и принятой технологией работы. Стало очевидно, что для успешной реализации задачи полной автоматизации банка следует изменить идеологию построения АИС.
Принципы "дуализма" и многокомпонентности. Развитие банковских структур и промышленных предприятий, увеличение числа филиалов, рост количества клиентов, необходимость повышения качества обслуживания предъявляли к автоматизированным системам новые требования. Новый подход к проектированию АИС заключается в сбалансированном сочетании двух предыдущих. В первую очередь это относилось к идеологии построения ядра системы: "Автоматизированная бухгалтерия – аналитический учет".
Для банковских структур это дало: с одной стороны, в ядре системы сохранялась возможность работы "от лицевого счета", с автоматическим формированием соответствующих бухгалтерских проводок, с другой стороны, отменялись жесткие требования работы только с лицевыми счетами. Появилась возможность ведения бухгалтерского учета по балансовым счетам любого порядка без углубления до уровня лицевых счетов клиентов. При этом ведение аналитического учета по лицевым счетам клиентов опускалось на уровень специализированного программного обеспечения (СПО), установленного на рабочих местах банковских работников (контролеров, кредитных бухгалтеров, инспекторов и т. д.). Таким образом, принципиальное отличие нового подхода к созданию АБС заключается в идее распределения плана счетов по уровням экспертизы. При этом и сам справочник плана счетов с соответствующими описаниями, и информационное множество клиентов проектировались по принципу распределенной базы данных. Результатом этого явилось:
· формирование всех необходимых бухгалтерских проводок, уже агрегированных по балансовым счетам, и автоматическая их передача в базу данных "Автоматизированной бухгалтерии";
· реализация специфических требований каждого банковского работника, в том числе по формированию произвольных отчетов и справок, мемориальных ордеров, операционных дневников; выполнение любых вспомогательных и технологических расчетов и пр.
С использованием гибкой системы настроек СПО (компонентов АБС) появилась реальная возможность адаптации программного аппарата к практически любым условиям и различным требованиям инструктивных материалов и правилам работы, принятым либо в вышестоящей организации, либо в данном банковском учреждении. Кроме того, при многокомпонентной схеме организации АБС при проведении модернизации одного из компонентов центральная часть (ядро) АБС и другие ее компоненты не затрагивались, что значительно повышало надежность, продолжительность жизни автоматизированной системы и обеспечивало наиболее полное выполнение требуемых функций.
Двойственный подход к формированию ежедневного баланса лег в основу т.н. "принципа дуализма" – одного из важных принципов построения современных банковских систем. Реализация принципа дуализма неизбежно требовала построения АБС нового поколения в виде программных модулей, органически связанных между собой, но в то же время способных работать и автономно.
Задача проектирования АИС промышленных предприятий более сложна, т.к. характер обрабатываемой информации еще более разнороден и сложно формализуем. Однако и здесь можно выделить основную модель работы – это работа "от кода проекта". В общем случае код проекта представляет собой аналог (функциональный) лицевого счета, он имеет определенную разрядность, порядок (т.е. конкретная группа цифро-буквенного обозначения характеризует деталь, сборочную единицу, изделие и их уровень взаимосвязи). Причем конкретная часть кода характеризует технологические, конструкторские, финансовые и др. документы. Все это регламентируется соответствующими ГОСТами (аналог инструкций ЦБ для банков), поэтому может быть формализовано. При этом модульный подход к реализации АИС в этом случае еще более важен.
Двойственный подход к формированию ежедневного производственного плана лег в основу т.н. "принципа дуализма" для АИС промышленных предприятий. Реализация принципа дуализма неизбежно также требовала построения АИС предприятий нового поколения в виде программных модулей, органически связанных между собой, но в то же время способных работать и автономно.
Такая многокомпонентная система обеспечивала соблюдение основополагающего принципа построения автоматизированных информационных систем – отсутствия дублирования ввода исходных данных. Информация по операциям, проведенным с применением одного из компонентов системы, могла быть использована любым другим ее компонентом. Модульность построения АИС нового поколения и принцип одноразового ввода дают возможность гибко варьировать конфигурацией этих систем. Так, в банках, имеющих разветвленную филиальную сеть и не передающих данные в режиме реального времени, установка всего СПО во всех филиалах не всегда экономически оправдано. В этих случаях возможна эксплуатация в филиалах ПО общего назначения, предназначенного для первичного ввода информации и последующей автоматизированной обработки данных в СПО, установленном в головном офисе банка. Такая структура дает возможность органически включить в АБС нового поколения компонент для создания хранилища данных, разделяя системы оперативного действия и системы поддержки принятия решения.
Кроме того, одно из достоинств принципа многокомпонентности , являющегося базовым при создании АИС нового поколения, состоит в возможности их поэтапного внедрения. На первом этапе внедрения устанавливаются (или заменяются уже устаревшие) компоненты системы на те рабочие места, которые нуждаются в обновлении ПО. На втором этапе происходит развитие системы с подсоединением новых компонентов и отработкой межкомпонентных связей. Возможность применения такой методики внедрения обеспечивает ее достаточно простое тиражирование и адаптацию к местным условиям. Таким образом, автоматизированная информационная система нового поколения – это многокомпонентная система с распределенной базой данных по уровням экспертизы.
Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие:
– принцип "разделяй и властвуй" – принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
– принцип иерархического упорядочивания – принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие:
· принцип абстрагирования – заключается в выделении существенных аспектов системы и отвлечения от несущественных;
· принцип формализации – заключается в необходимости строгого методического подхода к решению проблемы;
· принцип непротиворечивости – заключается в обоснованности и согласованности элементов;
· принцип структурирования данных – заключается в том, что данные должны быть структурированы и иерархически организованы.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:
· SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
· DFD (Data Flow Diagrams) диаграммы потоков данных;
· ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".
На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.
Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.
Методология функционального моделирования SADT. Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.
Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:
– графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;
– строгость и точность.
Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают:
– ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
– связность диаграмм (номера блоков);
– уникальность меток и наименований (отсутствие повторяющихся имен);
– синтаксические правила для графики (блоков и дуг);
– разделение входов и управлений (правило определения роли данных).
– отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
Моделирование потоков данных (процессов). В основе данной методологии (методологии Gane/Sarson) лежит построение модели анализируемой ИС – проектируемой или реально существующей. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процесс становятся элементарными и детализировать их далее невозможно.
Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации. Таким образом, основными компонентами диаграмм потоков данных являются:
– внешние сущности;
– системы/подсистемы;
– процессы;
– накопители данных;
– потоки данных.
Case-метод Баркера. Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных.
Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для проектирования реляционных баз данных. Нотация ERD была впервые введена П. Ченом (Chen) и получила дальнейшее развитие в работах Баркера.
Методология IDEF1. Метод IDEF1, разработанный Т.Рэмей (T.Ramey), также основан на подходе П.Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия – методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).
18. Каноническое проектирование. Состав и содержание стадий и этапов
Каноническое проектирование ЭИС отражает особенности ручной технологии индивидуального (оригинального) проектирования, осуществляемого на уровне исполнителей без использования каких-либо инструментальных средств, позволяющих интегрировать выполнение элементарных операций. Как правило, каноническое проектирование применяется для небольших локальных ЭИС.
В основе канонического проектирования лежит каскадная модель жизненного цикла ЭИС. Процесс каскадного проектирования в жизненном цикле ЭИС в соответствии с применяемым ГОСТ 34601-90 «Автоматизированные системы стадий создания» делится на следующие семь
Исследование и обоснование создания системы;
Разработка технического задания;
Создание эскизного проекта;
Техническое проектирование;
Рабочее проектирование;
Ввод в действие;
Функционирование, сопровождение, модернизация.
В целях изучения взаимосвязанных приемов и методов канонического проектирования ЭИС перечисленные 7 стадий можно сгруппировать в часто используемые на практике четыре стадии процесса разработки ЭИС (рис. 20).
Традиционно этапы исследования предметной области – предприятия, обоснование проекта ЭИС для него и разработки технического задания объединяют термином «Предпроектная стадия» («Предпроектное обследование»), поскольку результаты выполнения работ на данных этапах не являются законченным проектным решением. Основное назначение «Предпроектной стадии» заключается в обосновании экономической целесообразности создания ЭИС и формулировании требований к ней.
На первой«Предпроектной стадии» принято выделять два основных этапа: сбор материалов обследования; анализ материалов обследования и разработка технико-экономического обоснования (ТЭО) и технического задания (ТЗ).
 |  |
||
Рис. 20. ТСП стадий и этапов канонического проектирования ЭИС
Д1.1 – предметная область; Д1.2 –материалы обследования; Д1.3 –ТЭО, ТЗ на проектирование; Д1.4 – эскизный проект; Д2.1 – техно-рабочий проект (ТРП); Д3.1 – исправленный ТРП, переданный в эксплуатацию; Д3.2 – акт о приемке проекта в промышленную эксплуатацию; Д4.1 – модернизированный ТРП
В результате выполнения первого этапа проектировщики получают материалы обследования (Д1.2), которые должны содержать полную и достоверную информацию, описывающую изучаемую предметную область – предприятие, в том числе: цель функционирования; организационную структуру системы и объекта управления, т.е. его управленческие отделы, цехи, склады и хозяйственные службы; функции управления, выполняемые в этих подразделениях, протекающие в них технологические процессы обработки управленческой и экономической информации, а также материальные потоки и процессыих обработки, ресурсные ограничения.
После выполнения второго этапа проектировщики получают количественные и качественные характеристики информационных потоков, описание их структуры и мест обработки, объемов выполняемых операций и трудоемкости их обработки. На основе этих материалов разрабатываются два документа: «Технико-экономическое обоснование проектных решений» (ТЭО), содержащее расчеты и обоснование необходимости разработки ЭИС для предприятия и выбираемых технологических и проектных решений (Д1.3), и «Техническое задание» (ТЗ), в состав которого входят требования к создаваемой системе и ее отдельным компонентам: программному, техническому и информационному обеспечению и целевая установка на проектирование новой системы (Д1.4). Эти документы являются основными для последующего проектирования ЭИС в соответствии с заданными требованиями.
Для сложных ЭИС иногда на этой стадии включают третий этап – разработку «Эскизного проекта». На этапе «Эскизного проекта» сформулированные ранее требования служат основой для разработки предварительных решений по ЭИС в целом и отдельным видам обеспечения. Эти решения прорабатываются на логическом уровне, включая алгоритмы обработки информации, описание информационных потребностей пользователей на уровне названий документов и показателей.
Вторая стадия«Техно-рабочее проектирование» выполняется в два этапа: техническое проектирование и рабочее проектирование.
На этапе «Техническое проектирование» выполняются работы по логической разработке и выбору наилучших вариантов проектных решений, в результате чего создается «Технический проект». Этап «Рабочее проектирование» связан с физической реализацией выбранного варианта проекта и получением документации «Рабочего проекта». При наличии опыта проектирования эти этапы иногда объединяются в один, в результате выполнения которого получают «Техно-рабочий проект» (ТРП) – Д2.1.
Третья стадия«Внедрение проекта» включает в себя три этапа: подготовка объекта к внедрению проекта; опытное внедрение проекта и сдача его в эксплуатацию.
На этапе «Подготовка объекта к внедрению проекта» осуществляется комплекс работ по подготовке предприятия к внедрению разработанного проекта ЭИС. На этапе «Опытное внедрение» осуществляют проверку правильности работы некоторых частей проекта и получают исправленную проектную документацию и «Акт о проведении опытного внедрения». На этапе «Сдача проекта в промышленную эксплуатацию» осуществляют комплексную системную проверку всех частей проекта, в результате которой получают доработанный «Техно-рабочий проект» (ДЗ. 1) и «Акт приемки проекта в промышленную эксплуатацию» (Д3.2).
Четвертая стадия –«Эксплуатация и сопровождение проекта» включает этапы: эксплуатация проекта; сопровождение и модернизация проекта.
На этапе «Эксплуатация проекта» получают информацию о работе всей системы в целом и отдельных ее компонентов и собирают статистику о сбоях системы в виде рекламаций и замечаний, которые накапливаются для выполнения следующего этапа. На этапе «Сопровождение проекта» выполняются два вида работ: ликвидируются последствия сбоев в работе системы и исправляются ошибки, не выявленные при внедрении проекта, а также осуществляется модернизация проекта, В процессе модернизации проект либо дорабатывается, т.е. расширяется по составу подсистем и задач, либо производится перенос системы на другую программную или техническую платформу с целью адаптации ее к изменяющимся внешним и внутренним условиям функционирования, в результате чего получают документы модернизированного «Техно-рабочего проекта» (Д4.1).
При изучении существующей экономической системы разработчики должны уточнить границы изучения системы, определить круг пользователей будущей ЭИС различных уровней и выделить классы и типы объектов, подлежащих обследованию и последующей автоматизации.
Важнейшими объектами обследования могут являться:
Структурно-организационные звенья предприятия (например, отделы управления, цехи, участки, рабочие места);
Функциональная структура, состав хозяйственных процессов и процедур;
Стадии (техническая подготовка, снабжение, производство, сбыт) и элементы хозяйственного процесса (средства труда, предметы труда, ресурсы, продукция, финансы).
При каноническом проектировании основной единицей обработки данных является задача. Поэтому функциональная структура проблемной области на стадии предпроектного обследования изучается в разрезе решаемых задач и комплексов задач. При этом задача в содержательном аспекте рассматривается как совокупность операций преобразования некоторого набора исходных данных для получения результатной информации, необходимой для выполнения функции управления или принятия управленческого решения. В большинстве случаев исходные данные и результатыих преобразований представляются в форме экономических документов. Поэтому к числу объектов обследования относятся компоненты потоков информации (документы, показатели, файлы, сообщения). Кроме того, объектами обследования служат:
Технологии, методы и технические средства преобразования информации;
Материальные потоки и процессы их обработки.
Основной целью выполнения первого этапа предпроектного обследования «Сбор материалов» является:
Выявление основных параметров предметной области (например, предприятия или его части);
Установление условий, в которых будет функционировать проект ЭИС;
Выявление стоимостных и временных ограничений на процесс проектирования.
На этом этапе проектировщиками выполняется ряд технологических операций и решаются следующие задачи: предварительное изучение предметной области; выбор технологии проектирования; выбор метода проведения обследования; выбор метода сбора материалов обследования; разработка программы обследования; разработка плана-графика сбора материалов обследования; сбор и формализация материалов обследования.
Выполнение операции «Предварительное изучение предметной области» имеет своей целью на основе общих сведений об объекте выявить предварительные размеры объемов работ по проектированию и состав стоимостных и временных ограничений на процессы проектирования, а также найти примеры разработок проектов ЭИС для аналогичных систем.
Важной операцией, определяющей все последующие работы по обследованию объекта и проектированию ЭИС, является «Выбор технологии проектирования» . В настоящее время в универсум входит несколько типов технологий проектирования: технология оригинального, типового, автоматизированного и смешанного вариантов проектирования.
Для технологии оригинального проектирования характерно создание уникального проектного решения для экономической системы. При этом могут создаваться не только индивидуальные проекты, но и соответствующие методики проведения проектных работ. Поэтому технологию оригинального проектирования используют в том случае, если хотят, чтобы получаемый в результате проектирования индивидуальный проект в полной мере отображал все особенности соответствующего объекта управления при невысокой стоимости разработки, понятности и доступности получаемого решения заказчику. К числу ограничений по использованию оригинального проектирования можно отнести низкую степень автоматизации проектных работ, длительные сроки разработки, низкое качество документирования, отсутствие преемственности в проектных решениях.
CRP. Основные функции MRP-систем.
