3.1 Определение модели ЖЦ АИС

Под моделью жизненного цикла разработки программного продукта понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении жизненного цикла разработки программного продукта. Наибольшее распространение получили следующие модели жизненного цикла разработки программного продукта (таблица1. Краткие характеристики моделей жизненного цикла АИС): каскадная модель, или водопад (waterfall model); v-образная модель (v-shaped model); модель прототипирования (prototype model); модель быстрой разработки приложений, или RAD-модель (RAD-rapid application development model);многопроходная модель (incremental model); спиральная модель (spiral model).

Таблица 1.Краткие характеристики каждой из перечисленных моделей

3.2 Каскадная модель

В однородных информационных системах 1970-х и 1980-х годов прикладные программные продукты представляли собой единое целое. Для разработки такого типа программного продукта применялось каскадная модель, или «водопад».

Каскадная модель программного продукта подобна модели автоматизированной системы управления (см. главу 1, рис.1).

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

3.3 V-образная модель

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

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

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

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

Модель включает в себя следующие фазы:

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

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

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

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

Кодирование – выполняется преобразование алгоритмов в готовое программное обеспечение;

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

Интеграционное тестирование – осуществляются интеграция программного продукта и его тестирование;

Системное тестирование – выполняется проверка функционирования программного продукта после помещения его в аппаратную среду в соответствии со спецификацией требований;

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

Рис.5 V-образная модель

Преимущества v-образной модели:

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

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

3) Ход выполнения работы может легко отслеживаться, так как завершение каждой фазы является контрольной точкой.

Кроме перечисленных достоинств модель обладает и рядом недостатков:

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

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

Продукта и создание удобных карточек заполнения атрибутов БД: простота создания связей и их модернизация. Глава II. Разработка программы для автоматизации деятельности таксопарка 2.1 Анализ требований заказчика Программа Автоматизированное рабочее место диспетчера такси разработана по спиральной модели жизненного цикла автоматизированных информационных систем. На каждом этапе создания...

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

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

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

3. Проектирование АИС

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

Стадия проектирования состоит из следующих этапов:

1) предметное обследование (ПРО) существующей (традиционной) ИС;

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

3) разработка технического проекта на создание системы;

4) разработка рабочего проекта на создание системы.

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

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

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

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

­ цель, задачи, функции АИС, рассматриваются также внешние условия функционирования системы, распределение функций между ее компонентами;

­ системные параметры АИС - интерфейсы и распределение функций между оператором и системой;

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

­ структура и система управления БД, лингвистические средства, состав информационно-поисковых языков, классификаторов и кодификаторов, методик индексирования документов и запросов;

­ ведомость конфигурации комплекса технических средств АИС и их спецификация;

­ состав и характеристика математических моделей, алгоритмов и программ АИС;

­ схема функционирования АИС, технологического процесса обработки данных и др.;

­ должностные и рабочие инструкции для персонала АИС;

­ уточненное технико-экономическое обоснование проекта.

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

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

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

Методы и средства проектирования АИС. Проектирование АИС может выполняться:

­ сторонней фирмой-разработчиком. Эта фирма имеет штат высококвалифицированных профессионалов. Работа проводится на основании договора между фирмой-разработчиком и фирмой-заказчиком;

­ силами штатных специалистов фирмы-заказчика.

Возможно и компромиссное решение: фирма-заказчик может пригласить консультанта по разработке АИС на контрактной основе.

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

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

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

­ устный или письменный опрос;

­ письменное анкетирование;

­ наблюдение, измерение и оценка;

­ обсуждение промежуточных результатов;

­ анализ задач;

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

­ процессов.

Методы формирования задаваемого состояния связаны с теоретическим обоснованием всех составных частей АИС с учетом целей, требований и условий заказчика. Сюда относятся:

­ моделирование процессов обработки данных;

­ структурное проектирование;

­ декомпозиция;

­ анализ информационной технологии.

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

4. Автоматизация проектирования АИС

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

Основная цель CASE-технологии - максимально автоматизировать процесс разработки и отделить процесс проектирования от кодирования программных средств АИС.

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

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

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

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

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

В составе методологий структурного анализа к наиболее распространенным можно отнести следующие:

SADT - технология структурного анализа и проектирования, и ее подмножество - стандарт IDEFO.

DFD - диаграммы потоков данных.

ERD - диаграммы «сущность - связь».

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

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

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

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

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

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

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

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

1) разработка диаграммы аппаратных средств, отображающей процессы, устройства, сети и их соединения;

2) определение структуры класса, описывающей связь между классами и объектами;

3) разработка диаграмм объектов, которые показывают взаимосвязь объекта с другими объектами;

4) разработка архитектуры ПО, описывающей физический проект создаваемой системы.

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

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

5. Построение и внедрение АИС

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

Определение источников финансирования и выделение средств на закупку необходимого оборудования, предусмотренного проектом, - «Ведомость спецификации оборудования АИС»;

Выбор поставщиков и заключение контрактов на поставку оборудования;

Выделение помещения для дислокации АИС и его подготовка к монтажу оборудования;

Размещение, сборка, монтаж, настройка оборудования АИС в соответствии с проектом;

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

Выполнение работ по проверке качества оборудования (контроль, тестирование). При обнаружении дефектов - оформление и предъявление рекламаций к поставщикам;

Инсталляция ПО и выполнение работ по тестированию программного комплекса АИС. При условии обнаружения дефектов - принятие мер по их устранению;

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

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

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

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

2) обучение персонала технологии АИС и изучение соответствующих разделов проектной документации;

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

4) сдача АИС в производственную эксплуатацию с оформлением соответствующей документации.

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

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

6. Методика расчета технико-экономической эффективности автоматизированной обработки информации

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

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

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

Максимального сокращения времени на выполнение отдельных операций;

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

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

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

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

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

С э = С б – С п (1)

где С э - величина снижения затрат на обработку данных;

С б - затраты при базисном варианте;

С п - затраты при проектируемом варианте.

Относительный показатель экономической эффективности проекта АИС - коэффициент эффективности (К э) затрат и индекс изменения затрат (I з).

К э = С э / С б * 100 % (2)

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

Значение индекса изменения затрат можно определить по формуле:

I з = С э / С б. (3)

Этот индекс свидетельствует о том, во сколько раз снизятся затраты на обработку данных при реализации проекта АИС.

При внедрении проекта АИС необходимо учитывать дополнительные капитальные затраты, значение которых (К 3) можно определить по формуле:

K 3 = K п – K б (4)

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

Эффективность капитальных затрат определяется сроком окупаемости (Т) дополнительных капитальных затрат на модернизацию ИС:

Т = K 3 / С э (5)

Е = С э / K 3 = 1 / Т. (6)

Наряду с расчетом стоимостных затрат полезно получение показателей снижения трудовых затрат на обработку данных. Абсолютным показателем снижения трудовых затрат (t) выступает разность между годовыми трудовыми затратами базового и проектируемого вариантов обработки данных:

t = Т б. – Т п (7)

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

Значение относительного показателя снижения трудовых затрат можно отобразить коэффициентом снижения трудовых затрат (К):

K t = t / T б. (8)

Индекс изменения трудовых затрат (I t) характеризует рост производительности труда за счет освоения более трудосберегающего варианта проекта обработки данных, его можно определить по формуле:

I t = Т б / Т п. (9)

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

Р = (t / Т ф) * f (10)

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

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

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

Экономию трудовых затрат (Э тз) при автоматизированной обработке информации по проекту можно определить по формуле

Э тз = Т о6щ – Т сов (11)

где Т о6щ - трудоемкость обработки данных традиционным способом при базовым варианте;

Т сов - трудоемкость автоматизированной обработки данных при проектном варианте.

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

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

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

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

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

Модель ЖЦ АИС включает:

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

Ключевые события или точки завершения работ и принятия решений.

В соответствии с известными моделями ЖЦ ПО определяют модели ЖЦ АИС -каскадную, итерационную, спиральную.

I. Каскадная модель описывает классический подход к разработке систем в любых предметных областях; широко использовалась в 1970-80-х гг.

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

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

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

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

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

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

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

Рис.1.1 Каскадная модель ЖЦ АИС

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

Преимущества каскадной модели:

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

2) последовательное выполнение этапов работ позволяет планировать сроки завершения и соответствующие затраты.

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

Недостатки каскадной модели:

Существенная задержка в получении результатов;

Ошибки и недоработки на любом из этапов проявляются, как правило, на последующих этапах работ, что приводит к необходимости возврата;

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

Чрезмерная информационная перенасыщенность каждого из этапов;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки итерационной модели:

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

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

· запутанность архитектуры;

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

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

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

Рис. 1.2. Спиральная модель ЖЦ АИС

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

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

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

Преимущества итерационного подхода:

Итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика;

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

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

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

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

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

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

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

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

Модель жизненного цикла и технология проектирования

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

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

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

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

· роли и ответственность участников;

· иную информацию, необходимую для планирования, организации и управления коллективной разработкой ИС,

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

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

Часто смешивают понятия «этап» и «стадия» проектирования. Иногда говорят об этапах или фазах жизненного цикла, шагах проектирования. Возникает вопрос: как правильно?

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

По опубликованным данным каждый этап разработки АИС требует определенных затрат времени. В основном (45-50 %) время уходит на кодирование, комплексное и автономное тестирование. В среднем разработка АИС занимает одну треть всего ЖЦ системы.

Рис. Распределение времени при разработке АИС

Стадии создания АИС (ISO/IEC 15288)

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

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

1) предпроектное обследование (или анализ) организации,

2) проектирование АИС,

3) реализация АИС,

4) внедрение АИС,

5) функционирование (эксплуатация, использование)

6) сопровождение АИС,

7) модернизация проекта АИС.

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

Надо отметить, АИС является продуктом информационного производства, как автомобиль является продуктом машиностроительного производства, колбаса – продуктового производства и т.п., поэтому стадии ЖЦ АИС с 1 по 5 аналогичны этапам ЖЦ любого продукта .

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

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

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

Если в вашей организации подошли ответственно и комплексно к автоматизации, организовали соответствующим образом все стадии и этапы, то предел длительности ЖЦ АИС только время существования вашей организации , а это значит, потраченные средства на АИС не будут выброшены «на помойку» вместе с физически или морально устаревшей АИС.

Выше были перечислены все стадии ЖЦ АИС, но некоторые из них проходят параллельно, поэтому выделяют всего 5 этапов в ЖЦ АИС (рис.35):

На первом этапе «Предпроектное обследование » (рис. 33) принято выделять два основных подэтапа и один дополнительный подэтап:

1.1. проведение предпроектного обследования и сбор материалов обследования;

1.2. анализ материалов обследования и разработка на основе анализа технико-экономического обоснования (ТЭО) и технического задания (ТЗ);

1.3. выбор и разработка варианта концепции системы.

Целями этапа «предпроектное обследование» является следующее:

· сформулировать потребности в новой АИС, т.е. идентифицировать все недостатки существующей ИС;

· выбрать направление и определить экономическую целесообразность проектирования АИС.

Работы по проведению обследования начинаются с анализа первичных требований и планирования работ, которые занимают от 2 дней до 4 недель. Далее проводится само обследование деятельности предприятия (длительность обследования составляет 1-2 недели.)

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

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

Далее осуществляется обработка результатов обследования и построение моделей деятельности предприятия следующих двух видов (отметим, что для построения каждой из требуемых моделей необходима интенсивная работа 6-7 квалифицированных системных аналитиков в течение 2-4 месяцев).

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

2. Формируется Модель "как должно быть", интегрирующая перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков и позволяющая сформировать видение новых рациональных технологий работы предприятия. Она представляет собой концепцию будущей АИС.

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

Детальное изучение объекта автоматизации;

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

Разработка альтернативных вариантов концепции создаваемой АИС и планов их реализации;

Оценка необходимых ресурсов на их реализацию и обеспечение функционирования;

Оценка преимуществ и недостатков каждого варианта;

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

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

Оценка эффектов, получаемых от системы;

Оформление отчета, содержащего описание выполненных работ;

Описание и обоснование предлагаемого варианта концепции системы.

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

Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху всего проекта автоматизации. В практике создания больших программных систем известно немало примеров неудачной реализации именно из-за неполноты и нечеткости определения системных требований.

На этом этапе определяются:

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

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

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

§ состав людей и работ, имеющих отношение к системе;

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

§ организационные процедуры, обеспечивающие защиту информации.

В рамках системного проектирования осуществляется:

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

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

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

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

§ разработка состава автоматизируемых процедур документооборота.

Системный проект должен включать:

· полную функциональную модель требований к будущей системе;

· комментарии к функциональной модели (спецификации процессов нижнего уровня в текстовом виде);

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

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

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

· предложения по оргштатной структуре для поддержки системы.

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

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

Описать, "увидеть" и скорректировать будущую систему до того, как она будет реализована физически;

Уменьшить затраты на разработку и внедрение системы;

Оценить разработку по времени и результатам;

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

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

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

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

Без подобной поддержки со стороны руководства предприятия бессмысленно вообще затевать проект.

Рисунок 33. Последовательность работ на этапе предпроектной стадии ЖЦ АИС.

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

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

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

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

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

Разработка предложений по техническим средствам;

Разработка предложений по программным средствам;

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

Разработка предложений по этапам и срокам автоматизации.

Если было принято решение о выборе конкретной системы управления, то некоторые этапы пропускаются.

Второй этап «Проектирование » (рис.34) выполняет следующие подэтапы:

1) эскизное проектирование: уточнение требований ТЗ, оформление и утверждение эскизного проекта;

2) техническое проектирование: выбор проектных решений по всем аспектам разработки АИС, описание всех компонент АИС, оформление и утверждение технического проекта;

3) рабочее проектирование: выбор и разработка математических методов и алгоритмов программ, корректировка структуры баз данных (БД), создание документации на поставку и разработку программных продуктов, выбор комплекта технических средств АИС, создание документации на поставку и установку технических средств, разработка рабочего проекта АИС.

Целями этого этапа является следующее:

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

· разработать системную архитектуру выбранного варианта АИС, то есть состав обеспечивающих подсистем.

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

Определение функции АИС;

Определение функции подсистем, их цели и эффекты;

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

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

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

Определение состава вычислительной системы;

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

Разработка документации на эту часть проекта.

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

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

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

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

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

Разработка общих решений по системе и ее частям,

Разработка общих решений по функционально-алгоритмической структуре системы,

Разработка общих решений по функциям персонала и организационной структуре,

Разработка общих решений по структуре технических средств,

Разработка общих решений по алгоритмам решений задач и применяемым языкам,

Разработка общих решений по организации и ведению информационной базы,

Разработка общих решений по системе классификации и кодирования информации,

Разработка общих решений по программному обеспечению;

Проводят разработку, оформление документации по всем частям проекта, в том числе документа «Постановка задачи» ,

Разработка и оформление документации на поставку изделий для комплектования АИС и/или технических требований (технических заданий) на их разработку;

Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

Подэтап 3. «Рабочее проектирование » связан с физической реализацией выбранного варианта проекта и получением документации рабочего проекта (РП).

На этом подэтапе осуществляется:

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

Разработка программ и программных средств системы, а также выбор, адаптацию и/или привязку приобретаемых программных средств,

Разработка программной документации.

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

Рисунок 34. Последовательность работ на этапе проектирование ЖЦ АИС.

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

Третий этап «Реализация » (Рис. 35) - это физическое проектирование системы в следующей последовательности:

1) получение и установка технических средств;

2) кодирование, тестирование и доводка программ;

3) получение и установка программных средств;

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

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

Эти работы практически могут осуществляться параллельно.

На четверном этапе ЖЦ АИС «Внедрение » существуют следующие подэтапы:

1) опытное внедрение:

· ввод в опытную эксплуатацию технических средств,

· ввод в опытную эксплуатацию программных средств, проведение опытной эксплуатации всех компонентов и систем в целом,

· обучение и сертифицирование персонала.

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

На этом этапе проводят работы по организационной подготовке объекта автоматизации к вводу АИС в действие, в том числе:

Реализацию проектных решений по организационной структуре АИС;

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

Внедрение классификаторов информации;

Обучение персонала,

Проверка его способности обеспечить функционирование АИС.

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

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

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

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

2) промышленное внедрение (сдача в промышленную эксплуатацию):

· сдача в эксплуатацию,

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

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

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

Анализ результатов испытаний АИС и устранение недостатков, выявленных при испытаниях.

Заканчиваются работы оформлением акта о приемке АИС в постоянную эксплуатацию .

На последнем пятом этапе ЖЦ АИС выполняются эксплуатация, сопровождение и модернизация программных, технических средств и всего проекта.

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

Послегарантийное обслуживание заключается:

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

В выявлении отклонений фактических эксплуатационных характеристик АИС от проектных значений;

В установлении причин этих отклонений;

В устранении выявленных недостатков и обеспечении стабильности эксплуатационных характеристик АИС;

Во внесении необходимых изменений в документацию на АИС.

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

Рисунок 35. Этапы жизненного цикла АИС.

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

Наибольшее распространение получили три модели ЖЦ:

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

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

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

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

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

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

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

В основе спиральной модели ЖЦ лежит применение прототипной технологии или RAD-технологии (rapid application development – технология быстрой разработки приложений).

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

Естественно, что при прототипной технологии сокращается число итераций и меньше возникает ошибок и несоответствий, которые необходимо исправлять на последующих итерациях, а само проектирование осуществляется более быстрыми темпами, упрощается создание проектной документации. Для более точного соответствия проектной документации разработанной АИС все большее значение придается ведению общесистемного репозитария и автоматизации проектирования, в частности использованию CASE(Computers Aids System Engineering)-технологий.

При использовании спиральной модели:

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

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

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

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

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

Репозитарий содержит информацию об объектах проектируемой АИС и взаимосвязях между ними, все подсистемы обмениваются данными с ним.