Каскадная модель аис. Жизненный цикл автоматизированных информационных систем (ЖЦ АИС). Модели ЖЦ АИС. Описание презентации Этапы создания АИС Модели жизненного цикла АИС по слайдам

I. Блоки построения АИС. Методы и средства проектирования Проектирование - процесс создания проекта-прототипа, прообраза предполагаемого или возможного объекта, его состояния. Современная технология создания АИС - совокупность эффективных средств и методов проектирования, позволяющих упростить данный процесс, уменьшить стоимостные затраты, сократить календарные сроки проектирования системы и, в конечном итоге, за счет возможности более широкого выбора проверенных прогрессивных проектных решений, повысить качество разработки. Основные средства проектирования : -стандартные средства операционных систем, обеспечивающих автоматическое прохождение на ЭВМ определенного класса задач; -процедуры, реализующие типовые процессы обработки данных, например контроль выходной информации и ее сортировку; -инструментальные средства, к которым относится совокупность взаимосвязанных специальных программных средств, предназначенных для инструментальной поддержки отдельных элементов процесса проектирования АИС. Это создание и актуализация словаря данных, документирование проекта, автоматизация контроля проектирования и др.; -типовые компоненты, представленные в виде типовых проектных решений (ТПР) и пакетов прикладных программ (ППП). ТПР - совокупность алгоритмических, программных, инструктивно-методических элементов, обеспечивающих машинную реализацию задач или комплекса с помощью соответствующих технических средств. ТПР - основа создания ППП, к которым относятся комплексы программ, обеспечивающих работу типовых конфигураций вычислительной техники, диалоговых систем при решении типовых функциональных задач; -системы автоматизированного проектирования (САПР), предполагающие использование ЭВМ на всех этапах создания АИС и занимающие высшую ступень в эволюции средств проектирования системы. В методах проектирования различают классы и подклассы: Классы: -оригинальное проектирование . Средства, используемые при этом методе: - стандартные средства операционных систем; - процедуры, реализующие типовые процессы обработки данных. -типовое проектирование . Подклассы: элементы, подсистемы, объектное, групповое. Средства: стандартные средства операционных систем; типовые компоненты (ТПР, ППП); некоторые инструментальные средства. -автоматизированное проектирование . Подклассы: модульное; др. Средства: стандартные средства операционных систем САПР; взаимосвязанный комплекс инструментальных средств. Средства проектирования подразделяются на: -комплексные - это ТПР, ППП, типовые проекты автоматизированных систем, САПР. -локальные - большое разнообразие, в их состав входят системы управления базами данных, телеобработки, инструментальные средства и др. Общие требования к средствам проектирования : -полный охват всего процесса создания АИС; -совместимость, требующая согласованных решений как в процессе создания системы и ее обеспечивающих подсистем, так и в процессе их функционирования; -универсальность в своем классе, допускающем возможность применения одних и тех же средств для различных объектов; -д.б. легко доступными, не требующими особых усилий в освоении и просты в реализации; -возможность организации процесса проектирования в режиме интерактивного взаимодействия разработчика системы, проектировщика и ЭВМ; -д.б. адаптированными и экономически эффективными. Методы оригинального проектирования являются традиционными и ориентированы на одно предприятие. Характерная черта - разработка оригинальных методик обследования объекта, его внедрения, создания необходимой проектной документации в виде индивидуального проекта. Достоинство - отражение в проекте АИС специфических особенностей объекта автоматизации. Недостатки: сравнительно высокая трудоемкость и большие сроки разработки, низкий показатель функциональной надежности и адаптируемости к изменяющимся условиям. Проекты, созданные оригинальным методом, поддаются модернизации, однако в чистом виде этот метод используется редко. При его реализации используются в настоящее время различные средства проектирования и лишь для отдельных частей проекта требуются оригинальные проектные решения. Так, общесистемные проектные решения по разработке информационного обеспечения включают методы сбора, контроля и передачи данных, создание нормативно- справочных массивов информации, по программному обеспечению, определяют версию операционной системы, типовые процедуры обработки информации и т.д. Это несколько сглаживает его недостатки. Этот метод особенно актуален при автоматизации сложных, неординарных объектов. Типовое проектирование - индустриальный метод создания АИС, использующий ТПР и ППП, характеризуется наличием апробированных, типовых организационно-экономических, технических, информационных, математических и программных средств автоматизации управления. Достоинства: уменьшает трудоемкость, снижает стоимость и сокращает сроки проектирования, повышая его качество путем более полного охвата задач функциональных подсистем, строгого соблюдения требований нормативных документов, применения передовых технических решений. Типовое проектирование призвано устранить дублирование проектов, создать основу для расширения обмена готовыми типовыми компонентами, облегчить разработку рекомендаций по изменению организационной структуры и методов управления с учетом отраслевых и внутрихозяйственных особенностей. Процесс типового проектирования заключается в выборе и привязке указанных средств в соответствии с треб-ми конкретной системы. Типовая часть АИС представляет собой комплекс информационного, программного и технического обеспечения. Типовой характер первого достигается путем строгого соблюдения единства структуры информационной базы, состава массивов, форм входных и выходных документов; второго- на использовании ППП, и последнего в результате применения ЭВМ одного или совместных типов. Основами элементного проектирования являются ТПР - результат выполнения нескольких взаимосвязанных технологических операций проектирования, при разработке проекта используется уже готовое решение с небольшими модификациями, а не разрабатывается новое. Комплекс типовых проектных решений подразделяется на три группы: “Техника”, “ Задача”, “ Персонал”. Первая группа служит для выбора и комплектации всех видов технических средств вычислительных центров или др. организационных форм их применения. Вторая - содержит документацию по организационно-экономической сущности каждой задачи, алгоритмы их решения, описание входной и выходной информации, соответствующие программные модули с их описаниями и инструкциями по применению. Третья - должностные инструкции всех категорий работников, определяющие их права и обязанности. ТПР создаются по модульному принципу, когда каждое проектное решение расчленяется на отдельные составные части- модули, которые реализуют определенную часть ТПР. Это позволяет создать проект новой автоматизированной системы путем сочетания отдельных типовых модулей. При использовании подсистемного метода проектирования предполагается более высокая степень интеграции типовых элементов системы, когда для каждой подсистемы создаются проекты решений и пакеты прикладных программ. Выделение подсистем- в зависимости от объекта хозяйственно-производственного процесса. Для каждой из подсистем разрабатывается свое автоматизированное проектное решение и ППП, которые могут быть общесистемного или функционального назначения. К первой группе относятся ППП управления данными, типовых процедур их обработки, методовматематической статистики и дискретного программирования, решения непрерывных задач, например дифференциальных уравнений. Во вторую группу входят пакеты, ориентированные на промышленные предприятия с дискретным или непрерывным характером производства, на непромышленную сферу, отраслевое управление. Важное требование, предъявляемое к ППП,- совместимость, т.к. при проектировании АИС целесообразно использовать сразу несколько пакетов. Проектирование систем с применением ППП фактически сводится к привязке выбранных по определенным параметрам пакетов к конкретным условиям объекта автоматизации. Достоинства: менее трудоемкий процесс, занимает меньше времени по сравнению с оригинальным проектированием, реализует прогрессивные методы обработки данных, упрощает документирование проекта, т.к. используется документация пакетов, повышается надежность проектируемых систем. Метод объектного проектирования базируется на применении типовых проектов автоматизированных систем управления. Применяется недостаточно широко, т.к. слишком много разнообразных объектов, а модификация типового проекта системы в соответствии с конкретными условиями объекта автоматизации требует больших трудовых и материальных затрат. Отдельной группой выделяется метод группового проектирования . Его сущность: предварительно подбирается группа объектов, однотипных по характеристикам их информационных систем, среди них выбирается базовый объект, для которого и разрабатывается проект, причем могут использоваться различные методы и способы проектирования, главное- это обеспечение его высокой адаптивности. Основная сфера применения этого метода- непромышленные объекты (например склады), т.к. они более устойчивы с позиции экономической информационной системы. Среди автоматизированных методов особое место занимают методы модульного проектирования . Создание и использование САПР обеспечивает достаточно высокий уровень функциональной надежности, комплексный охват всех технологических процессов, снижение трудоемкости проектных работ с максимальным учетом интересов объекта автоматизации. Однако этот метод достаточно дорог и требует высококвалифицированных разработчиков. Ключевое требование, предъявляемое к САПР, - возможность построения и поддержания в системе проектирования в адекватном состоянии некоторой глобальной экономической информационной модели объекта автоматизации. Модель - отображение информационных компонентов объекта автоматизации и отношение между ними, заданные в явном виде. Основная цель построения модели - создание соответствующего этой модели проекта АИС, учитывающего и активно использующего все характеристики объекта. Такая модель должна содержать в формализованном виде описание совокупностей информационных компонентов и отношения между ними, включая информационные связи и алгоритмическое взаимодействие. С помощью модульного метода проектирования применяется системный подход, обусловливающий использование ЭВМ не только на всех стадиях создания системы, но и в процессе анализа результатов ее промышленной эксплуатации. Развитие и применение САПР предопределило переход к созданию индивидуальных проектов, но на значительно более высоком уровне, по сравнению с оригинальным методом проектирования. Разработкой, внедрением, сопровождением и эксплуатацией корпоративных информационных систем (или сокращенно КИС) занимаются специалисты по информационным технологиям (ИТ). Информационные технологии являются очень широким понятием, поскольку они определяют методы и средства создания, сбора, регистрации, передачи, обработки, хранения и выдачи информации в информационных системах. В настоящее время наряду с названием Корпоративные информационные системы (КИС) употребляются, например, следующие названия: · Автоматизированные системы управления (АСУ); · Интегрированные системы управления (ИСУ); · Интегрированные информационные системы (ИИС); · Информационные системы управления предприятием (ИСУП). Основные стадии проектирования автоматизированных информационных систем · Перед началом проектирования АИС необходимо детально обосновать необходимость ее создания, подробно описать цели и задачи проекта, ожидаемую прибыль, временные затраты, доступные ресурсы, ограничения и т. д. Такие работы часто называют стратегическим планированием информационной системы, и для их осуществления назначается менеджер проекта. Необходимость разработки любой АИС может быть обусловлена следующими факторами: ростом значимости информационной среды предприятия; комплексностью системы управления предприятием; необходимостью анализа потенциальных возможностей и опасностей предприятия; необходимостью систематизации деятельности предприятия; необходимостью постоянного повышения эффективности использования основных фондов предприятия, улучшения соотношения цены и качества; повышением роли капиталовложений в сферу информатизации предприятия; необходимостью кадрового планирования для адекватного обеспечения развития предприятия; ростом сложности и комплектности существующих ИС, влекущим за собой усложнение функциональных требований к ИС и их развитию. Главная особенность стратегического планирования информационной системы состоит в том, что именно в этот период уточняются потребности организации в информации, что и определяет возможные варианты структуры информационной системы. В зависимости от интенсивности функционирования информационно-технологического комплекса выделяют следующие группы организаций: организации, развитие которых зависит от использования информационных технологий для ежедневной деятельности (банки, страховые компании и т. д.); организации, не зависящие от информационных технологий, но способные в будущем широко их использовать для достижения конкурентных преимуществ; организации, в деятельности которых информационные технологии не могут стать источником конкурентного преимущества; организации, использующие информационные технологии для поддержки деятельности, не являющейся основной. Для каждой из описанных групп разрабатываются информационные системы, автоматизирующие соответствующие участки деятельности организации . Разработка и внедрение любой АИС осуществляется в определенной последовательности в соответствии с техническим заданием. Содержание первой очереди управленческой системы определяется составом задач учета, анализа, планирования и оперативного управления, наиболее поддающихся автоматизации и имеющих существенное значение для принятия управленческих решений в организации. В процессе разработки последующих очередей системы происходит расширение и интеграция информационного, программного и математического обеспечения, модернизация технических средств. Жизненный цикл АИС позволяет выделить четыре основных периода: предпроектный, проектный, внедрение, эксплуатация и сопровождение . Технология проектирования автоматизированных информационных систем в настоящее время определяется действующим ГОСТ 34.601-90, согласно которому весь процесс разбит на стадии и этапы . 1. Стадия «Формирование требований к АИС»: определение объема обоснования, необходимого для создания АИС (сбор данных об объекте автоматизации и осуществляемых видах деятельности, оценка качества его функционирования, выявление проблем, решение которых возможно средствами автоматизации, оценка целесообразности создания АИС); формирование требований пользователя к АИС; оформление отчета о выполненных работах и подача заявки на разработку АИС. 2. Стадия «Разработка концепции АИС»: изучение объекта АИС; проведение необходимых исследовательских и проектных работ; разработка вариантной концепции АИС и выбор варианта, который удовлетворяет требованиям пользователя, оценка преимуществ и недостатков альтернативных вариантов; оформление отчета о выполненной работе. 3. Стадия «Техническое задание»: разработка и оформление технического задания на создание АИС (общие сведения, назначение и цели создаваемой системы, характеристика объекта автоматизации, требования к системе в целом, ее функциям и задачам, видам обеспечения, планам работ по созданию, вводу в действие и приемке). 4. Стадия «Эскизный проект»: разработка предварительных проектных решений по системе и ее частям (функции АИС, ее подсистемы, состав задач, концепция и структура информационной базы, состав и основные характеристики технических средств); разработка документации на АИС и ее элементы. 5. Стадия «Технический проект»: разработка проекта решений по системе и ее элементам, по функциональной, алгоритмической и организационной структуре системы, структуре технических средств, организации и ведения базы данных, по системе классификации и кодирования информации, алгоритму решения задач, используемым языкам программирования и программному обеспечению; разработка документов АИС; разработка и оформление документации на поставку изделий для комплектования АИС и технических требований на их разработку; разработка заданий на проектирование. 6. Стадия «Рабочее проектирование»: разработка рабочей документации на систему и ее части; разработка или адаптация программ. 7. Стадия «Ввод в действие»: подготовка АИС к внедрению; сдача задач и подсистем в опытную эксплуатацию; составление отчета о вводе в действие. 8. Стадия «Сопровождение АИС»: анализ функционирования системы; авторский надзор. Особенность разработки АИС заключается в концентрации сложности и трудоемкости на стадиях предпроектного обследования, так как ошибки, допущенные на этапах обследования, анализа и проектирования, порождают на этапах внедрения и эксплуатации часто неразрешимые проблемы достижения поставленных целей и эффективности использования АИС. Формирование требований к системе подразумевает определение ее функциональных возможностей, пользовательских требований, требований к надежности и безопасности, к внешним интерфейсам и т. д. Планирование работ включает предварительную экономическую оценку проекта, построение плана-графика выполнения работ, создание и обучение совместной рабочей группы. На этом этапе осуществляется системный анализ рассматриваемой системы, который включает в себя описание структуры элементов системы и проведение обследования деятельности автоматизируемого объекта; анализ распределения функций по подразделениям и сотрудникам, информационных потоков внутри подразделений и между ними, внешних по отношению к организации объектов и внешних информационных взаимодействий. Fuckyeah. Анализ завершается построением моделей деятельности организации, предусматривающих обработку материалов обследования и построения функциональных и информационных моделей двух видов: модели «as is» («как есть»), отражающей существующее положение дел в организации; модели «to be» («как должно быть»), отражающей представление о новых технологиях и бизнес-процессах организации. По результатам обследования определяется перечень задач, решение которых целесообразно автоматизировать, и очередность их разработки (рис. 8.2). Рис. Результаты обследования Техническое задание - это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки АИС и определения уровня экономической эффективности ее внедрения. Содержание и оформление технического задания регламентируются требованиями ГОСТ 34.602-89. Стадия эскизного проектирования предполагает предварительный выбор методов проектирования и оценку ожидаемых результатов, однако зачастую эта стадия вводится в состав технического проектирования . Технический проект разрабатывается в целях определения основных проектных решений по созданию системы. На этом этапе осуществляется комплекс исследовательских работ для выбора наилучших вариантов решений, провіодятся эксперименталь ная оценка проектных решений и расчет экономической эффективности системы. Для каждой задачи, включенной в комплекс первоочередных задач, выполняется детальная постановка задачи и разработка алгоритма ее решения. Целью этой стадии является формирование новой структуры системы и логических взаимосвязей ее элементов, которые будут функционировать на выбранной технологической основе. Построение системной архитектуры предполагает выделение элементов и модулей информационного, технического, программного обеспечения и других обеспечивающих подсистем, определение связей по информации и управлению между выделенными элементами и разработку технологии обработки информации . Рабочее проектирование включает разработку спецификаций каждого компонента и материалов, обеспечивающих эффективную эксплуатацию АИС, которые содержат уточненные данные и детализированные общесистемные проектные решения, программы и инструкции по решению задач, а также уточненную оценку экономической эффективности АИС. Техническая часть рабочего проекта предусматривает определение технических средств, описание технологического процесса обработки данных, расчет и составление графика загрузки комплекса технических средств, описание режима функционирования АИС . Внедрение разработанного проекта предполагает выполнение следующих этапов : подготовка объекта управления к внедрению АИС, опытное внедрение, т. е. проверка работоспособности элементов и модулей проекта и устранение выявленных ошибок, и промышленное внедрение - этап сдачи в эксплуатацию и проверки на уровне функций, контроль соответствия требованиям, сформулированным на стадии системного анализа (рис. 8.3). На стадии эксплуатации и сопровождения собирается статистика о качестве работы каждого из компонентов системы, исправляются обнаруженные недостатки, в некоторых случаях принимается решение о необходимости расширения функциональности системы (рис. 8.4) . В целом процесс проектирования АИС условно включает в свой состав только основные стадии, а реальный набор этапов и технологических операций в значительной степени зависит от выбранного подхода проектирования. Рис. Основные работы, выполняемые на стадии внедрения АИС Рис. Работы, выполняемые на стадии эксплуатации и сопровождения

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

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

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

1. Формирование требований;

2. Проектирование;

3. Разработка;

4. Тестирование;

5. Внедрение;

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

Преимущества:

-Полная и согласованная документация на каждом этапе;

-Определенный порядок последовательности работ;

-Позволяет четко спланировать сроки и затраты.

Недостатки:

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

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

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

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

Каждая итерация – законченные циклы разработки в виде 1й версии АИС.

Этапы итерации:

1.Формирование требований

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

4.Разработка

5.Интеграция

На каждой итерации оцениваются:

Риск превышения сроков и стоимости проекта;

Необходимость выполнения ещё одной итерации;

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

Целесообразность прекращения проекта.

Преимущества:

-Упрощается процесс внесения изменений в проект;

-Обеспечивает большую гибкость в управлении проектом;

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

-Влияние заказчика на работу в процессе проверки каждой итерации.

Недостатки:

-Сложность планирования;

-Напряженный режим работы для разработчиков;

-Планирование работ проводится на основе имеющегося опыта и недостаточно метрик для измерения качества каждой версии.

Требования к технологии проектирования, разработки и сопровождения АИС

Технология проектирования - определяет совокупность трех составляющих:

-пошаговой процедуры, определяющей последовательность технологических операций проектирования;

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

-представление проектной разработки на экспертизу и утверждению.

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

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

Технология должна поддерживать полный ЖЦ ПО;

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

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

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

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

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

-стандарт оформления проектной документации;

-стандарт пользовательского интерфейса.

Требование разработки

- Выполнение работ по созданию программного обеспечения;

Подготовка к внедрению АИС;

Контроль, тестирование основных показателей проекта.

Требования к сопровождению

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

В процессе сопровождения КИС ставится задача поддержания ее жизнеспособности. Жизнеспособность КИС во многом определяется насколько она соответствует реальным задачам и потребностям ВУЗа, которые являются меняющимися в течение жизненного цикла КИС.

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

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)-технологий.

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

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

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

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

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

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

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

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

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

Существует три класса методологий проектирования АИС :
· концептуальное моделирование предметной области;
· выявление требований и спецификация информационной системы через ее макетирование;
· системная архитектура программных средств, поддерживаемая инструментальными средствами CASE-технологии (CASE -- Computer Aided Software Engineering -- технология создания и сопровождения ПО различных систем).

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

Формирование требований к АС.
Разработка концепции АС.
Техническое задание.
Эскизный проект.
Технический проект.
Рабочая документация.
Ввод в действие.
Сопровождение АС.

Можно выделить три периода создания системы: предпроектный, проектирование, ввод в эксплуатацию.
Стадии 1, 2, 3 относятся к первому периоду, стадии 4, 5, 6 — ко второму периоду, стадии 7, 8 — к третьему.
В предпроектный период разрабатывают технико-экономическое обоснование (ТЭО) и техническое задание (ТЗ) на проектирование системы. В этот период на стадии формирования требований к АС проводят три этапа работ:

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

На стадии разработки концепции АС проводят четыре этапа работ:

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

На 3-й стадии разрабатывают и утверждают техническое задание на создание АС.
Техническое задание (ТЗ) — это перечень основных эксплуатационных, технологических экономических и других требований, которым должен удовлетворять проектируемый объект на всех этапах его существования.После утверждения ТЗ начинается второй период создания АС — период проектирования системы.
Проектирование — процесс обоснованного выбора характеристик системы, формирования логико-математических и экономико-математических моделей, разработки документации.
На стадии создания эскизного проекта на 1-м этапе разрабатывают предварительные проектные решения по системе и ее частям, на 2-м — документацию наАС и ее части.
На 5-й стадии при создании технического проекта в четыре этапа проводят разработку:

проектных решений по системе и ее частям;
документации наАС и ее части;
документации на поставку изделий для комплектования АС и ТЗ на их разработку;
заданий н# проектирование в смежных частях проекта объекта автоматизации.

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

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

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

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

Для АИС условно выделяют следующие основные этапы их жизненного цикла:
1. анализ -- определение того, что должна делать система;
2. проектирование -- определение того, как система будет функционировать: прежде всего спецификация подсистем, функциональных компонентов и способов их взаимодействия в системе;
3. разработку -- создание функциональных компонентов и отдельных подсистем, соединение подсистем в единое целое;
4. тестирование -- проверку функционального и параметрического соответствия системы показателям, определенным на этапе анализа;
5. внедрение -- установку и ввод системы в действие;
6. сопровождение -- обеспечение штатного процесса эксплуатации системы на предприятии заказчика.

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

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

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

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

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

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

Название	характеристики
Каскадная модель	Прямолинейная и простая в использовании. Необходим постоянный жесткий контроль за ходом работы. Разрабатываемое программное обеспечение не доступно для изменений
v-образная модель	Простая в использовании. Особое значение придается тестированию и сравнению результатов фаз тестирования и проектирования
Модель прототипирования	Создается «быстрая» частичная реализация системы до составления окончательных требований. Обеспечивается обратная связь между пользователями и разработчиками в процессе выполнения проекта. Используемые требования не полные
Модель быстрой разработки приложений	Проектные группы небольшие (3… 7 человек) и составлены из высококвалифицированных специалистов. Уменьшенное время цикла разработки (до 3 месяцев) и улучшенная производительность. Повторное использование кода и автоматизация процесса разработки
Многопроходная модель	Быстро создается работающая система. Уменьшается возможность внесения изменений в процессе разработки. Невозможен переход от текущей реализации к новой версии в течение построения текущей частичной реализации
Спиральная модель	Охватывает каскадную модель. Расчленяет фазы на меньшие части. Позволяет гибко выполнять проектирование. Анализирует риски и управляет ими. Пользователи знакомятся с программным продуктом на более раннем этапе благодаря прототипам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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