Организация документооборота с помощью "Visual Basic for Application"

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

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

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

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

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

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

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

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

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

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

Спиральная модель чаще изменяется при разработке ИС силами собственного отдела ИТ предприятия.

Стандарты ЖЦ ИС

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

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

Значительный вклад в теорию проектирования и разработки информационных систем внесла компания IBM, предложив еще в середине 1970-х годов методологию BSP (Business System Planning - методология организационного планирования). Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных подразделений, функций систем обработки данных (информационных систем), информационных объектов, документов и баз данных, предложенный в BSP, используется сегодня не только в ИТ-проектах, но и проектах по реинжинирингу бизнес-процессов, изменению организационной структуры. Важнейшие шаги процесса BSP, их последовательность (получить поддержку высшего руководства, определить процессы предприятия, определить классы данных, провести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике.

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

* ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного никла.

* ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяются на все виды заказного ПО. Стандарт не содержит описания фаз, стадий этапов.

* Custom Development Method (методика Оrас1е) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Оrас1е. Применяется СDМ для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий «быстрой разработки» (Fast Track) или «облегченного подхода», рекомендуемых в случае малых проектов.

* Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.

* Microsoft Solution Framework (MSF) сходна с RUP так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

* Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

Позднее был разработан и в 2002 г. опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). К разработке стандарта были привлечены специалисты различных областей: системной инженерии, программирования, управления качеством. Человеческими ресурсами, безопасностью и пр. Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение - поддержка создания компьютеризированных систем.

Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ следует включать следующие группы процессов:

1. Договорные процессы:

* приобретение (внутренние решения или решения внешнего поставщика);

* поставка (внутренние решения или решения внешнего поставщика).

2. Процессы предприятия:

* управление окружающей средой предприятия;

* инвестиционное управление;

* управление ЖЦ ИС;

* управление ресурсами;

* управление качеством.

3. Проектные процессы:

* планирование проекта;

* оценка проекта;

* контроль проекта;

* управление рисками;

* управление конфигурацией;

* управление информационными потоками;

* принятие решений.

4. Технические процессы:

* определение требований;

* анализ требований;

* разработка архитектуры;

* внедрение;

* интеграция;

* верификация;

* переход;

* аттестации;

* эксплуатации;

* сопровождение;

* утилизация.

5. Специальные процессы:

* определение и установка взаимосвязей исходя из задач и целей.

Стадии создания системы, предусмотренные в стандарте ISO/IEC 15288, несколько отличается от аналогичных в других стандартах. Перечень стадий и основные результаты, которые должны быть достигнуты к моменту их завершения, приведены в таблице 4.

Таблица 4. Стадии создания систем(ISO/IEC 15288)

1.3.2 Основы современной технологии проектирования АИС

Классификация методов проектирования систем

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

Так, по степени автоматизации методы проектирования разделяются на:

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

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

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

* оригинальное (индивидуальное), когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к АИС. Характеризуется тем, что все виды проектных работ ориентированы на создание индивидуальных для каждого объекта проектов, которые в максимальной степени отражают все его особенности;

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

По степени адаптивности проектных решений выделяют методы;

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

* параметризации, когда проектные решения настраиваются (генерируются) в соответствии с изменяемыми параметрами;

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

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

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

Таблица 5. Характеристики классов технологий проектирования

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

Без использования ЭВМ и с использованием ЭВМ.

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

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

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

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

2. Средства, поддерживающие проектирование отдельных компонентов. К данному подклассу относятся средства общесистемного назначения:

* системы управления базами данных (СУБД);

* методо-ориентированные пакеты прикладных программ (решение задач дискретного программирования, математической статистики и т. П.);

* табличные процессоры;

* статистические ППП и др.

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

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

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

К функциональным средствам проектирования систем обработки информации относятся типовые проектные решения, функциональные пакеты прикладных программ, типовые проекты.

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

1) по охватываемым этапам процесса разработки ИС;

2) по степени интегрированности:

* отдельные локальные средства (tools);

* набор неинтегрированных средств, охватывающих большинство этапов разработки ИС (toolkit);

* полностью интегрированные средства, связанные общей базой проектных данных - репозиторием (workbench).

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

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

В наибольшей степени задаче формализации технологии проектирования ИС соответствует аппарат технологических сетей проектирования.

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

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

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

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

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

Каноническое проектирование ИС

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

Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного никла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

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

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

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

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

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

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

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

6) ввод в действие;

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

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

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

Состав и содержание работ на предпроектной стадии создания ИС.

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

Важнейшими объектами обследования могут валяться:

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

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

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

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

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

* материальные потоки и процессы их обработки.

Основной целью выполнения первого этапа предпроектного обследования «Сбор материалов» является:

* выявление основных параметров предметной области (например, предприятия или его части);

* установление условий, в которых будет функционировать проект ИС;

* выявление стоимостных и временных ограничений на процесс

проектирования.

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

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

1. Факторы, связанные с параметрами входных информационных потоков, поступающих на обработку ЭВМ: объем информации, тип носителя информации, характер представления информации.

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

3. Факторы, определяемые техническими характеристиками ЭВМ: производительность процессора, емкость оперативной памяти, поддерживаемая операционная система, возможность подключения различных устройств ввода-вывода.

4. Факторы, относящиеся к эксплуатационным характеристикам ЭВМ: требуемые условия эксплуатации.

5. Факторы, учитывающие стоимостные оценки затрат на приобретение, на содержание обслуживающего персонала, на проведение ремонтных работ.

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

К факторам, определяющим выбор конкретного класса ОС и его версии, относятся:

* необходимое множество поддерживаемых программных продуктов;

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

* возможность использования различных устройств ввода-вывода;

* требование поддержки сетевой технологии;

* наличие справочной службы для пользователя;

* наличие дружественного интерфейса и простота использования и др.

Следующей операцией является операция «Выбор способа организации информационной базы (ИБ) и программного средства ведения ИБ. Информационная база имеет несколько способов организации как совокупность локальных файлов и интегрированную организацию в виде баз данных.

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

Интегрированная база данных представляет собой совокупность взаимосвязанных, хранящихся вместе данных, используемых для одного или нескольких приложений. Данные, организованные в виде БД, могут быть организованы как централизованно (размещены на одной ЭВМ), так и в виде распределенных БД (размещенных на нескольких ЭВМ).

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

* масштаб применения СУБД. По этому признаку выделяют персональные - настольные СУБД (например, FохРго или Access) или промышленные - сетевые СУБД (например, Oracle);

* язык общения. Разделяют СУБД с открытыми языками, замкнутыми или смешанными;

* число уровней в архитектуре. Существуют одноуровневые: двухуровневые, трехуровневые СУБД;

* выполняемые СУБД функции: информационные - организация хранения информации и доступа к ней и операционные функции, связанные с обработкой информации;

* сфера возможного применении СУБД: универсальное использование и специализированное.

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

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

К информационным параметрам относятся такие, как достоверность, периодичность сбора, форма представления, периодичность обработки информации и т. д.

К экономическим параметрам ИС относятся: показатели годового экономического эффекта, коэффициента эффективности затрат и т.п.

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

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

* обоснование цели создания ИС;

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

* разработка перечня организационно-технических мероприятий по проектированию системы;

* расчет и обоснование эффективности выбранного проекта;

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

В предметной области, как правило, рассматривается модели исходной системы (объекта). Например, модели деятельности организации создаются в двух видах:

* модель «как есть» («as-is»)-отражает существующие в организации бизнес-процессы;

* модель «как должно быть» («to-be»)-отражает необходимые изменения бизнес-процессов с учетом внедрения ИС.

На основе ТЭО разрабатываются основные требования к будущему проекту ЭИС и составляется «Техническое задание» согласно ГОСТ 34.602 - 89 «Техническое задание на создание автоматизированной системы», в состав которого входят следующие основные разделы.

1. В разделе «Общие сведения о проекте» указывают: полное наименование системы, код системы, код договора, наименование предприятия-разработчика.

2. Раздел описания «Назначение, цели создания системы» состоит из двух подразделов:

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

в подразделе «Цели создания системы» указываются наименования и требуемые значения технических и других показателей объекта автоматизации ИС.

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

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

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

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

При разработке технического задания необходимо решить следующие задачи:

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

* разработать и обосновать требования, предъявляемые к подсистемам;

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

* установить общие требования к проектируемой системе;

* определить перечень задач создания системы и исполнителей;

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

* провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.

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

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

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

* функции ИС;

* функции подсистем, их цели и ожидаемый эффект от внедрения;

* состав комплексов задач и отдельных задач;

* концепция информационной базы и ее укрупненная структура:

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

* состав вычислительной системы и других технических средств;

* функции и параметры основных программных средств.

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

Состав и содержание работ на стадии техно-рабочего проектирования

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

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

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

* разработка общесистемных положений по ЭИС;

* изменение организационной структуры;

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

* разработка проектно-сметной документации и расчет экономической эффективности системы;

* разработка плана мероприятий по внедрению ИС.

Наиболее принципиальной в данном комплексе работ является разработка функциональной архитектуры ИС на базе принципов выделения функциональных подсистем (модулей, контуров): предметного, функционального, смешанного (предметно-функционального и проблемного.

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

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

* проектирование форм входных и выходных документов, системы ведения документов и макетов экранных форм документов;

* проектирование классификаторов экономической информации и системы ведения классификаторов;

* разработка структуры входных и выходных сообщений;

* проектирование состава и структур файлов информационной базы;

* проектирование внемашинной и внутримашинной технологии решения каждой задачи;

* уточнение состава технических средств.

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

* характеристику задачи;

* описание выходной информации;

* описание входной информации.

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

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

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

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

Результатом работ на данной стадии является утвержденный «Технический проект», состав и содержание которого регламентируются стандартом (ГОСТ 34.201-89).

Таким образом на основе ТЗ (и эскизного проекта) разрабатывается технический проект ИС.

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

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

* описание программ;

* спецификация программ;

* тексты программ;

* контрольные примеры;

* инструкции для системного программиста, оператора и пользователя.

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

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

Состав и содержание работ на стадиях внедрения, эксплуатации и сопровождения проекта

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

Внедрение может осуществляться с использованием следующих методов:

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

* параллельного метода, при котором все задачи внедряются во всех подсистемах одновременно;

* смешанного подхода, согласно которому проектировщики, внедрив несколько подсистем первым методом и накопив опыт, приступают к параллельному внедрению остальных.

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

* подготовка объекта к внедрению;

* опытное внедрение;

* сдача проекта в промышленную эксплуатацию.

Первый этап- "Подготовка объекта к внедрению». На этом этапе осуществляются следующие операции;

* изменяется организационная структура объекта (предприятия);

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

* осуществляется установка каналов связи: проводится разработка новых документов и классификаторов;

* осуществляется создание файлов информационной базы с нормативно-справочной информацией и др.

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

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

* подготовка исходных оперативных данных для задач, которые

проходят опытную эксплуатацию;

* ввод исходных данных в ЭВМ и выполнение запланированного числа реализации;

* анализ выходных данных на предмет наличия ошибок.

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

После устранения ошибок получают «Акт о проведении опытного внедрения», который служит сигналом для начала выполнения следующего этапа.

На третьем этапе - «Сдача проекта в промышленную эксплуатацию» - используют следующую совокупность документов:

* договорную документацию;

* приказ на разработку ИС;

* ТЭО и ТЗ;

* исправленный техно-рабочий проект;

* приказ о начале промышленного внедрения;

* программу проведения испытаний;

* требования к научно-техническому уровню проекта системы.

В процессе сдачи проекта в промышленную эксплуатацию осуществляются следующие работы:

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

* проверка соответствия проектных решений по ИС требованиям ТЗ;

* проверка соответствия проектной документации ГОСТам и ОСТам;

* проверка технологических процессов обработки данных по всем задачам и подсистемам;

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

* выявление локальных и системных ошибок и их исправление.

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

На четвертой стадии - «Эксплуатация и сопровождение проекта» - выполняются следующие процессы:

* эксплуатация проекта;

* сопровождение и модернизация проекта.

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

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

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

* сделать заключение о необходимости модернизации всего проекта или его частей;

* определить объемы доработок, сроки и стоимость выполнения этих работ с целью получения «Техно- рабочего проекта», прошедшего модернизацию.

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

1.3.3 Автоматизированное проектирование ИС (CASE-ТЕХНОЛОГИЯ)

Основные понятия и классификация CASE-технологий

Термин CASE (Computer Aided System/Software Engineering) используется в довольно

широком смысле. Первоначальное значение термина CASE, ограниченное вопросами

автоматизации разработки только лишь программного обеспечения, в настоящее время

приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом.

С самого начала CASE-технологии развивались с целью преодоления ограничений при

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

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

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

Преимущества CASE-технологии по сравнению с традиционной технологией оригинального проектирования

сводятся к следующему:

- улучшение качества разрабатываемого программного приложения за счет средств автоматического

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

- возможность повторного использования компонентов разработки;

- поддерживание адаптивности и сопровождения ИС;

- снижение времени создания системы, что позволяет на ранних стадиях проектирования получить

прототип будущие системы и оценить его;

- освобождение разработчиков от рутинной работы по документированию проекта, так как при этом

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

- возможность коллективной разработки ЭИС в режиме реального времени.

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

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

Метод - это процедура или техника генерации описаний компонентов ЭИС (например, проектирование

потоков и структур данных).

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

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

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

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

- создавать элементы диаграмм и взаимосвязи между ними;

- задавать описания элементов диаграмм;

- задавать описания связей между элементами диаграмм;

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

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

проектирования ЭИС. Он выполняет следующие функции:

- мониторинг правильности построения диаграмм;

- диагностику и выдачу сообщений об ошибках;

- выделение на диаграмме ошибочных элементов.

Документатор проекта позволяет получать информацию о состоянии проекта в виде различных отчетов.

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

Администратор проекта представляет собой инструменты, необходимые для выполнения следующих функции:

- инициализации проекта;

- задания начальных параметров проекта;

- назначения и изменения прав доступа к элементам проекта;

- мониторинга выполнения проекта.

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

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

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

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