Описание презентации Этапы создания АИС Модели жизненного цикла АИС по слайдам
Жизненный цикл АИС -совокупность стадий и этапов, которые проходит АИС в своем развитии от момента принятия решения о создании системы до момента прекращения ее функционирования.
Этапы жизненного цикла 1 Планирование и анализ (предпроектная стадия) – определение того, что должна делать система. Оформление технико-экономического обоснования (ТЭО) и технического задания (ТЗ).
2 Проектирование (техническое и логическое проектирование) – определение того, как система будет функционировать (спецификация* подсистем, функциональных компонентов и способов их взаимодействия). Оформление технического проекта. * Спецификация — точное, полное, ясно сформулированное описание требований для данной задачи.
3. Реализация (рабочее проектирование, программирование) — Создание функциональных компонентов и отдельных подсистем, соединение подсистем в единое целое. Заполнение БД. Создание инструкций для персонала. Оформление рабочего проекта
4 Внедрение (тестирование, опытная эксплуатация) – установка и ввод системы в действие, отладка подсистем, обучение персонала. Оформление акта о приемо-сдаточных испытаниях.
Замечания 1. Этапы 2 и 3 можно объединить в одну: техно-рабочее проектирование или системный синтез. 2. На каждом этапе жизненного цикла используется определенный набор технических решений и соответствующих документов
3. Для каждого этапа исходными являются документы и решения принятые на предыдущем этапе. 4. Модели жизненного цикла определяют порядок исполнения этапов в процессе создания системы и критерии перехода от этапа к этапу.
Модель жизненного цикла — это модель создания и использования АИС, которая отражает различные состояния системы с момента возникновения до момента его полного выхода из употребления.
Основные модели ЖЦ Каскадная – предполагает переход на следующий этап после полного завершения работ предыдущего. Эта модель используется при построении АИС для которых с самого начала точно и полно сформулированы все требования. Недостатки: жесткая схема – невозможность возврата к предыдущим этапам и использование для сложных систем.
Поэтапная итерационная модель Предполагает наличие обратной связи между циклами. Преимущество в том, что межэтапные корректировки обеспечивают большую гибкость и меньшую трудоемкость. Недостаток – время жизни каждого из этапов может растянуться на весь период создания системы.Трудности и недостатки спиральной модели ЖЦ Основная проблема — определение перехода на следующий этап: для ее решения вводятся временные ограничения на каждый из этапов. Переход осуществляется в соответствии с планом составленным на основе статистических данных предыдущих проектов и опыта разработчиков. Недостатки: ошибки, допущенные на этапах анализа и проектирования, могут привести к проблемам на следующих этапах и к неуспеху всего проекта.
Роль пользователя АИС создается для удовлетворения информационных потребностей конкретного пользователя. Он принимает непосредственное участие в ее работе. .
Пользователь участвует в постановке задачи и проводит опытную эксплуатацию, в ходе которой может обнаружить недостатки постановки, корректировать входную и выходную информацию, формы выдачи результатов и оформление документов.
Участие пользователя в создании АИС обеспечивает оперативное и качественное решение задач, сокращает время на внедрение новых технологий
Практически в любой области люди используют тот или иной вид моделей (математических, физических или компьютерных), чтобы иметь более ясное представление о том, что происходит в реальных процессах.
Существует 2 способа описания моделей:
1) статический, рассматривающий структуру модели, ᴛ.ᴇ. такие её аспекты, в которых можно пренебречь временем;
2) динамический, рассматривающий поток событий, ᴛ.ᴇ. изменение моделируемых явлений во времени, которым нельзя пренебречь с точки зрения решаемых задач.
Любую фирму и её деятельность можно рассматривать с точки зрения различных людей: оператора, исполнительного директора, заказчика, акционера, партнёра, продавца и т.д. Каждой категории людей необходимы различные модели деятельности фирмы.
Исполнительный директор должен иметь общую картину: процессы, продукцию, финансы, перспективы и т.д., ᴛ.ᴇ. интегрированную картину в целом. Для того, чтобы управляющий персонал мог принимать правильные решения в любых ситуациях, крайне важно иметь набор моделей, описывающих разные стороны деятельности фирмы и их взаимоотношения. В моделях, используемых на верхнем уровне управления, самое главное - ϶ᴛᴏ краткость и понятность. В них должны быть подчёркнуты основные моменты, а детали бывают скрыты.
Одной из наиболее важных моделей является в настоящее время модель бизнеса, с помощью которой определяются функции фирмы во внешнем мире.
Рисунок 1 – Модель иерархически организованной компании
Существующие модели жизненного цикла определяют порядок исполнения этапов в процессе создания системы, а также критерии перехода от этапа к этапу. Наибольшее распространение получили три следующие модели.
Среди известных моделей жизненного цикла АИС можно выделить каскадные, итерационные и спиральные модели.
Каскадная модель (до 70 ᴦ.ᴦ.) предполагает переход на следующий этап после полного завершения работ предыдущего этапа. Эта модель используется при построении АИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования. Это дает разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие.
Рисунок 2 – Схема каскадной модели
Преимущества каскадной модели:
1) на каждом этапе формируется законченный набор проектной документации, отвечающей критериям полноты и согласованности;
2) выполняемые в логичной последовательности этапы работы позволяют планировать сроки их завершения и соответствующие затраты.
Недостатки каскадной модели:
1) запоздание с получением результатов;
2) крайне важность возврата к предыдущим этапам.
Для каскадной модели жизненного цикла АИС характерна автоматизация отдельных несвязанных задач, не требующая выполнения информационной интеграции и совместимости, программного, технического и организационного сопряжения. В рамках решения отдельных задач каскадная модель жизненного цикла по срокам разработки и надёжности оправдывала себя. Применение каскадной модели жизненного цикла АИС к большим и сложным проектам вследствие большой длительности процесса проектирования и изменчивости требований за это время может привести к практической нереализуемости.
Поэтапная итерационная модель. Эта модель создания АИС предполагает наличие циклов обратной связи между этапами. Преимущество такой модели состоит по сути в том, что межэтапные корректировки обеспечивают большую гибкость и меньшую трудоемкость по сравнению с каскадной моделью. При этом время жизни каждого из этапов может растянуться на весь период создания системы.
Рисунок 3 – Схема поэтапной итерационной модели
Недостатки: Как правило, вследствие большого числа итераций возникают рассогласования в выполненных проектных решениях и документации. Запутанность функциональной и системной архитектуры созданной АИС, трудность в использовании проектной документации вызывают на стадиях внедрения и эксплуатации сразу крайне важность перепроектирования всей системы. Жизненный длительный цикл разработки АИС заканчивается этапом внедрения, за которым начинается жизненный цикл создания новой АИС.
Спиральной модель (80-90 ᴦ.ᴦ.) – опирается на начальные этапы жизненного цикла: анализ, предварительное и детальное проектирование.
Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии системы, на нем уточняются цели и характеристики проекта͵ определяется его качество, планируются работы следующего витка спирали. Основная проблема - определение момента перехода на следующий этап. Для ее решения крайне важно ввести временные ограничения на каждый из этапов ЖЦ. Переход осуществляется в соответствии с планом, который составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Недостатком этого подхода являются нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования. Οʜᴎ могут привести на последующих этапах к проблемам и даже к неуспеху всего проекта. По этой причине анализ и проектирование должны выполняться особенно тщательной
Рисунок 4 – Схема спиральной модели
В основе спиральной модели жизненного цикла лежит применение прототипной технологии или RAD-технологии (Rapid Application Development – технологии быстрой разработки приложений). Согласно этой технологии АИС разрабатывается путём расширения программных прототипов, повторяя путь от детализации требований к детализации программного кода. Естественно, что при этой технологии сокращается число итераций и возникает меньше ошибок и несоответствий, которые крайне важно исправлять на последующих итерациях. При этом проектирование АИС идёт более быстро, упрощается создание проектной документации. Для более точного соответствия проектной документации разработанной АИС всё большее значение придаётся ведению общесистемного репозитария и использованию САSЕ-технологий.
Жизненный цикл при использовании RAD-технологии предполагает активное участие конечных пользователей будущей системы на всех этапах разработки и включает 3 основные стадии информационного реинжиниринга:
1) анализ и планирование информационной стратегии : пользователи вместе со специалистами-разработчиками принимают участие в идентификации проблемной области;
2) проектирование : пользователи принимают участие в техническом проектировании под руководством специалистов-разработчиков;
3) внедрение : специалисты-разработчики обучают пользователей работе в среде новой АИС.
Разработка и проектирование АИС начинается с создания концептуальной модели использования системы. Прежде всего должна быть определена целесообразность создания системы, ее конкретные функции и подлежащие автоматизации задачи. Должна быть выполнена оценка не только целей, но и возможностей создания системы. Далее проводится анализ требований к АИС, детальное проектирование, взаимосвязь этапов, программирование и тестирование, минимизация потерь при переходе от одного уровня представления информации к другому, интеграция в существующую систему, внедрение и поддержка.
Существует три класса методологий проектирования АИС:
Концептуальное моделирование предметной области;
Выявление требований и спецификация информационной системы через ее макетирование;
Системная архитектура программных средств, поддерживаемая инструментальными средствами CASE-технологии (CASE - Computer Aided Software Engineering - технология создания и сопровождения ПО различных систем).
Современные методологии проектирования систем должны обеспечивать описание объектов автоматизации, описание функциональных возможностей АИС, спецификацию проекта͵ гарантирующую достижение заданных характеристик системы, детальный план создания системы с оценкой сроков разработки, описание реализации конкретной системы.
Спецификация - точное, полное, ясно сформулированное описание требований для данной задачи.
АИС существуют, как правило, на протяжении длительного отрезка времени, последовательно проходя в своем развитии несколько стадий объединенных жизненным циклом (ЖЦ) системы:
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)-технологий.
При использовании спиральной модели:
· происходит накопление и повторное использование проектных решений, средств проектирования, моделей и прототипов АИС и информационных технологий;
· осуществляется ориентация на развитие и модификацию системы и технологий в процессе их проектирования;
· проводится анализ риска и издержек в процессе проектирования системы.
Интерфейс – это сопряжение частей программных и технических средств, данных, технология общения человека с компьютером, в котором все информационные, логические, физические и электрические параметры отвечают установленным стандартам.
Прототип – минимальная версия системы, используемая для генерации или разработки полной версии
Репозитарий содержит информацию об объектах проектируемой АИС и взаимосвязях между ними, все подсистемы обмениваются данными с ним.
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 Жизненный цикл АИС и модели жизненного цикла АИС
Жизненный цикл АИС – это непрерывный процесс с момента принятия решения о необходимости принятия решения о необходимости ее создания до полного завершения ее эксплуатации.
Продолжительность жизненного цикла современных АИС составляет около 10 лет, что значительно превышает сроки морального и физического старения технических и системных программных средств, используемых при реализации АИС. Поэтому, как правило, в течение ЖЦ системы проводится ее модернизация, после чего все функции системы должны выполняться с не меньшей эффективностью.
Добиться этого на протяжении всего ЖЦ АИС - довольно сложная по ряду объективных и субъективных причин задача, в результате подавляющее большинство проектов АИС внедряется с нарушениями качества, сроков или сметы; почти треть проектов прекращают свое существование незавершенными. По данным Standish Group в 1996 г. 84 % проектов АИС не были завершены в установленные сроки, в 1998 г. это число сократилась до 74 %, после 2000 г. оно не опускается ниже 50 %. Главной причиной такого положения является то, что уровень технологии анализа и проектирования систем, методов и средств управления проектами не соответствует сложности создаваемых систем, которая постоянно возрастает в связи с усложнением и быстрыми изменениями бизнеса.
Из мировой практики известно, что затраты на сопровождение прикладного программного обеспечения АИС составляют не менее 70 % его совокупной стоимости на протяжении ЖЦ, поэтому крайне важно еще на проектной стадии предусмотреть необходимые методы и средства сопровождения, включая методы конфигурационного управления.
Процесс проектирования АИС регламентирован следующей документацией (стандартами, методологиями, моделями):
ГОСТ 34.601-90 - стандарт на стадии и этапы создания АИС, соответствующие каскадной модели ЖЦ ПО (рассматривается ниже). Приводится описание содержания работ на каждом этапе;
180/1ЕС 12207:1995 - стандарт на процессы и организацию жизненного цикла; распространяется на все виды заказного программного обеспечения; не содержит описания фаз, стадий и этапов;
Custom Develoment Method (методология Oracle) - технологический материалпо разработке прикладных АИС, детализированный до уровня заготовок проектных документов в расчете на использование Oracle.Применяется для классической модели ЖЦ (предусмотрены все работы, задачи и этапы), а также для технологий «быстрой разработки» (Fast Track) или «облегченного подхода», рекомендуемых в случае малых проектов.
Rational Unified Process (методология RUP )- технологический материал по реализации итеративной модели разработки, включающей четыре фазы (цикл разработки): начало, исследование, построение и внедрение. Каждая фаза разбита на этапы (итерации), результатами которых являются версии для внутреннего или внешнего использования. Каждый цикл завершается генерацией очередной версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова проходит те же фазы. Суть работы в рамках RUP-методологии - создание и сопровождение моделей на базе UML;
Microsoft Solution Framework (методология MSF ) - технологический материал по реализации итеративной модели разработки, аналогично RUP включает четыре фазы: анализ, проектирование, разработку, стабилизацию; предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений;
Extreme Programming (ХР) - экстремальное программирование (самая новая среди рассматриваемых методологий); сформировалось в 1996 г. Основой методологии является работа в команде, эффективные коммуникации между заказчиком и исполнителем в течение всего проекта; разработка АИС ведется с использованием последовательно дорабатываемых прототипов.
Стандарт ISO/IЕС 12207 в структуре жизненного цикла определяет процессы, которые выполняются при создании ПО АИС. Эти процессы подразделяют на три группы:
основные (приобретение, поставка, разработка, эксплуатация и сопровождение);
вспомогательные (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит и решение проблем);
организационные (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла, обучение).
Среди основных процессов жизненного цикла самыми важными являются разработка, эксплуатация и сопровождение. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами.
Разработка АИС включает все работы по созданию программного обеспечения и его компонентов в соответствии с заданными требованиями. Этот процесс также предусматривает:
Оформление проектной и эксплуатационной документации;
Подготовку материалов, необходимых для тестирования разработанных программных продуктов;
Разработку материалов, необходимых для обучения персонала.
Как правило, составляющими процесса разработки являются стратегическое планирование, анализ, проектирование и реализация (программирование).
К процессу эксплуатации относятся:
Конфигурирование базы данных и рабочих мест пользователей;
Обеспечение пользователей эксплуатационной документацией;
Обучение персонала.
Основные эксплуатационные работы включают:
Непосредственно эксплуатацию;
Локализацию проблем и устранение причин их возникновения;
Модификацию программного обеспечения;
Подготовку предложений по совершенствованию системы;
Развитие и модернизацию системы.
Профессиональное, грамотное сопровождение - необходимое условие решения задач, выполняемых АИС. Службы технической поддержки играют весьма заметную роль в жизни любой АИС. Ошибки на этом этапе могут привести к явным или скрытым финансовым потерям, сопоставимым со стоимостью самой системы.
К предварительным действиям при организации технического обслуживания АИС относятся:
Выделение наиболее ответственных узлов системы и определение для них критичности простоя (это позволит выделить наиболее критичные составляющие АИС и оптимизировать распределение ресурсов для технического обслуживания);
Определение задач технического обслуживания и их разделение на внутренние, решаемые силами обслуживающего подразделения, и внешние, решаемые специализированными сервисными организациями (таким образом, четко ограничивается круг исполняемых функций и производится распределение ответственности);
Проведение анализа имеющихся внутренних и внешних ресурсов, необходимых для организации технического обслуживания в рамках описанных задач и разделения компетенции (основные критерии для анализа: наличие гарантии на оборудование, состояние ремонтного фонда, квалификация персонала);
Подготовка плана организации технического обслуживания с определением этапов исполняемых действий, сроков их исполнения, затрат на этапах, ответственности исполнителей.
Обеспечение качественного технического обслуживания ШС требует привлечения специалистов высокой квалификации, которые в состоянии решать не только ежедневные задачи администрирования, но и быстро восстанавливать работоспособность системы при сбоях и авариях.
Среди вспомогательных процессов одним из главных является управление конфигурацией, которое поддерживает основные процессы жизненного цикла АИС, прежде всего процессы разработки и сопровождения.
Разработка сложных АИС предполагает независимую разработку компонентов системы, что приводит к появлению многих вариантов и версий реализации как отдельных компонентов, так и системы в целом. Таким образом, возникает проблема обеспечениясохранения единой структуры в ходе разработки и модернизации АИС. Управление конфигурацией позволяет организовывать, систематически учитывать и контролировать внесение изменений в различные компоненты АИС на всех стадиях ее ЖЦ.
Организационные процессы имеют очень большое значение, так как современные АИС - это большие комплексы, в создании и обслуживании которых занято много людей разных специальностей.
| Процесс(исполнитель процесса) | Действия" | Вход | Результат |
| Приобретение (заказчик) | Инициирование. Подготовка заявочных предложений. Подготовка договора. Контроль деятельности поставщика. Приемка АИС | Решение о начале работ по внедрению АИС. Результаты обследования деятельности заказчика. Результаты анализа рынка АИС/тен-дера. План поставки/разработки. Комплексный тест АИС | Технико-экономическое обоснование внедрения АИС. Техническое задание на АИС. Договор на поставку/разработку. Акты приемки этапов работы. Акт приемо-сдаточных испытаний |
| Поставка (разработчик АИС) | Инициирование. Ответ на заявочные предложения. Подготовка договора. Планирование исполнения. Поставка АИС | Техническое задание на АИС. Решение руководства об участии в разработке. Результаты тендера. Техническое задание на АИС. План управления проектом. Разработанная АИС и документация | Решение об участии в разработке. Коммерческие предложения/конкурсная заявка. Договор на поставку/разработку. План управления проектом. Реализация/корректировка. Акт приемо-сдаточных испытаний |
| Разработка (разработчик АИС) | Подготовка. Анализ требований к АИС. Проектирование архитектуры АИС. Разработка требований к ПО. Проектирование архитектуры ПО. Детальное проектирование ПО. Кодирование и тестирование ПО. Интеграция ПО и квалификационное тестирование ПО. Интеграция ИС и квалификационное тестирование АИС | Техническое задание на АИС. Техническое задание на АИС, модель ЖЦ. Техническое задание на АИС. Подсистемы АИС. Спецификации требования к компо-" нентам ПО. Архитектура ПО. Материалы детального проектирования ПО. План интеграции ПО, тесты. Архитектура ИС, ПО, документация на ИС, тесты | Используемая модель ЖЦ, стандарты разработки. План работ. Состав подсистем, компоненты оборудования. Спецификации требования к компонентам ПО. Состав компонентов ПО, интерфейсы с БД, план интеграции ПО. Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам. Тесты модулей ПО, акты автономного тестирования. Оценка соответствия комплекса ПО требованиям ТЗ. Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ |
Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков, конроля сроков и качества выполнения работ. Техническое и организационное обеспечение проекта включает:
Выбор методов и инструментальных средств реализации проекта;
Определение методов описания состояния процесса разработки;
Разработку методов и средств испытаний созданного программного обеспечения;
Обучение персонала.
Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования компонентов АИС.
Верификация - процесс определения соответствия текущего состояния разработки, достигнутого на данном этапе, требованиям этого этапа.
Проверка - процесс определения соответствия параметров разработки исходным требованиям. Проверка отчасти совпадает с тестированием, которое проводится для определения различий между действительными и ожидаемыми результатами, а также для оценки соответствия характеристик АИС исходным требованиям.
В 2002г. Был опубликован стандарт на процессы ЖЦ автоматизированных систем (ISO/IEC 15288 System Life cycle processes). В разработке стандарта участвовали специалисты из различных областей деятельности; учитывался практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Согласно стандарту ISO/IEC серии 15288 в структуру ЖЦ включены следующие группы процессов.
1. Договорные процессы:
Приобретение (внутренние решения или решения внешнего поставщика);
Поставка (внутренние решения или решения внешнего поставщика).
2. Процессы предприятия:
Управление окружающей средой предприятия;
Инвестиционное управление; в управление ЖЦ ИС;
Управление ресурсами;
Управление качеством.
3. Проектные процессы:
Планирование проекта;
Оценка проекта;
Контроль проекта;
Управление рисками;
Управление конфигурацией;
Управление информационными потоками;
Принятие решений.
4. Технические процессы:
Определение требований;
Анализ требований;
Разработка архитектуры;
Внедрение;
Интеграция;
Верификация;
Переход;
Аттестация;
Эксплуатация;
Сопровождение;
Утилизация.
5. Специальные процессы:
Определение и установка взаимосвязей исходя из задач и целей.
В табл. 1.4 приведены перечень стадий и основные результаты к моменту их завершения в соответствии с указанным стандартом.
В 1970-х гг. корпорация IBM предложила методологию Business System Planning (BSP) или методологию организационного планирования.
Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных подразделений систем обработки данных (ИС), информационных объектов, документов и баз данных, предложений в BSP, их последовательность (получить поддержку высшего руководства, определить процессы предприятия, определить процессы классы данных, привести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике.
Таблица 1.4. Стадии создания АИС (ISO/IEC 15288)
По опубликованным данным каждый этап разработки АИС требует определенных затрат времени. В основном (45-50 %) время уходит на кодирование, комплексное и автономное тестирование (рис.14). В среднем разработка АИС занимает одну треть всего ЖЦ системы (рис.1.5).
Рис.1.4. Распределение времени при разработке АИС
