Понятие жизненного цикла является одним из базовых понятий методологии проектирования информационных систем. Жизненный цикл информационной системы представляет собой непрерывный процесс, начинающийся! с момента принятия решения о создании информационной системы и заканчивается в момент полного изъятия ее из эксплуатации.
Стандарт ISO/IEC 12207 определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания информационной системы. Согласно данному стандарту структура жизненного цикла основывается на трех группах процессов:
1. основные процессы жизненного цикла (приобретение, поставка, разработка, эксплуатация, сопровождение);
2. вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, разрешение проблем);
3. организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла, обучение).
Среди основных процессов жизненного цикла наибольшую важность разработка, эксплуатация и сопровождение. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными; полученными на предыдущем этапе, и результатами.
1. Разработка
Разработка информационной системы включает в себя все работы по разработке информационного программного обеспечения и его компонентов в соответствии с заданными требованиями. Разработка информационного программного обеспечения также включает:
1. оформление проектной и эксплуатационной документации;
2. подготовку материалов, необходимых для проведения тестирования тайных программных продуктов;
3. разработку материалов, необходимых для организации обучения персонала.
Разработка является одним из важнейших процессов жизненного цикла информационной системы и, как правило, включает в себя стратегическое планирование, анализ, проектирование и реализацию (программирование).
2. Эксплуатация
Эксплуатационные работы можно подразделить на подготовительные и основные. К подготовительным относятся:
1. конфигурирование базы данных и рабочих мест пользователей;
2. обеспечение пользователей эксплуатационной документацией;
3. обучение персонала.
Основные эксплуатационные работы включают;
1. непосредственно эксплуатацию;
2. локализацию проблем и устранение причин их возникновения;
3. модификацию программного обеспечения;
4. подготовку предложений по совершенствованию системы;
5. развитие и модернизацию системы.
3. Сопровождение
Службы технической поддержки играют весьма заметную роль в жизни любой корпоративной информационной системы. Наличие квалифицированного технического обслуживания на этапе эксплуатации информационной системы является необходимым условием для решения поставленных перед ней задач. Причем ошибки обслуживающего персонала могут приводить к явным или скрытым финансовым потерям сопоставимым со стоимостью самой информационной системы.
Модели жизненного цикла
Под моделью жизненного цикла понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики информационной системы и специфики условий, в которых последняя создается и функционирует
К настоящему времени наибольшее распространение получили следующие основные модели жизненного цикла:
1. задачная модель;
2. каскадная модель (или системная) (70-85 г.г.);
3. спиральная модель (настоящее время).
Задачная модель
При разработке системы "снизу-вверх" от отдельных задач ко всей системе (задачная модель) единый поход к разработке неизбежно теряется, возникают проблемы при информационной стыковке отдельных компонентов. Как правило, по мере увеличения количества задач трудности нарастают, приходится постоянно изменять уже существующие программы и структуры данных. Скорость развития системы замедляется, что тормозит и развитие самой организации. Однако в отдельных случаях такая технология может оказаться целесообразной:
Крайняя срочность (надо чтобы хоть как-то задачи решались; потом придется все сделать заново);
Эксперимент и адаптация заказчика (не ясны алгоритмы, решения нащупываются методом проб и ошибок).
Общий вывод: достаточно большую эффективную информационной системы таким способом создать невозможно.
Каскадная модель
В ранних не очень больших по объему однородных информационных систем каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис. 2). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в следующем:
на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Рис. . Каскадная схема разработки
Каскадный подход хорошо зарекомендовал себя при построении информационных систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако в процессе использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания систем никогда полностью не укладывался в такую жесткую схему. В процессе создания постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания программного обеспечения принимал следующий вид (рис. 3):
Рис. 3. Реальный процесс разработки ПО по каскадной схеме
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к информационным системам "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания программного обеспечения, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Сущность системного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. Таким образом, данная модель основным достоинством имеет системность разработки, а основные недостатки - медленно и дорого.
Спиральная модель
Для преодоления перечисленных проблем была предложена спиральная модель жизненного цикла (рис. 4), делающая упор на начальные этапы жизненного цикла: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Рис 4. Спиральная модель ЖЦ ИС
Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:
небольшую команду программистов (от 2 до 10 человек);
короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Жизненный цикл программного обеспечения по методологии RAD состоит из четырех фаз:
1. фаза определения требований и анализа;
2. фаза проектирования;
3. фаза реализации;
4. фаза внедрения.
Лекция 6. Классификация информационных систем
Информационная система - взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной цели
Классификация по масштабу
По масштабу информационные системы подразделяются на следующие группы:
1. одиночные;
2. групповые;
3. корпоративные.
Одиночные информационные системы реализуются, как правило, на автономном персональном компьютере (сеть не используется). Такая система может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создайся с помощью так называемых настольных или локальных систем управления базами данных (СУБД). Среди локальных СУБД наиболее известными являются Clarion, Clipper, FoxPro, Paradox, dBase и Microsoft Access.
Групповые информационные системы ориентированы на коллективное использование информации членами рабочей группы и чаще всего строятся на базе локальной вычислительной сети. При разработке таких приложений используются серверы баз данных (Называемые также SQL-серверами) для рабочих групп. Существует довольно большое количество различных SQL-серверов, как коммерческих, так и свободно распространяемых. Среди них наиболее известны такие серверы баз данных, как Oracle, DB2, Microsoft SQL Server, InterBase, Sybase, Informix.
Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура клиент-сервер со специализацией серверов или же многоуровневая архитектура. При разработке таких систем могут использоваться те же серверы баз данных, что и при разработке групповых информационных систем. Однако в крупных информационных системах наибольшее распространение получили серверы Oracle, DB2 и Microsoft SQL Server.
Для групповых и корпоративных систем существенно повышаются требования к надежности функционирования и сохранности данных. Эти свойства обеспечиваются поддержкой целостности данных, ссылок и транзакций в серверах баз.
Классификация по сфере применения
По сфере применения информационные системы обычно подразделяются на четыре группы:
1. системы обработки транзакций;
2. системы принятия решений;
3. информационно-справочные системы;
4. офисные информационные системы.
Системы обработки транзакций , в свою очередь, по оперативности обработки данных, разделяются на пакетные информационные системы и оперативные информационные системы. В информационных системах организационного управлений преобладает режим оперативной обработки транзакций, для отражения актуального состояния предметной области в любой момент времени, а пакетная обработка занимает весьма ограниченную часть.
Системы поддержки принятия решений - DSS (Decision Support Systeq) - представляют собой другой тип информационных систем, в которых с помощью довольно сложных запросов производится отбор и анализ данных в различных разрезах: временных, географических и по другим показателям.
Обширный класс информационно-справочных систем основан на гипертекстовых документах и мультимедиа. Наибольшее развитие такие информационные системы получили в сети Интернет.
Класс офисных информационных систем нацелен на перевод бумажных документов в электронный вид, автоматизацию делопроизводства и управление документооборотом.
Классификация по способу организации
По способу организации групповые и корпоративные информационные системы подразделяются на следующие классы:
1. системы на основе архитектуры файл-сервер;
2. системы на основе архитектуры клиент-сервер;
3. системы на основе многоуровневой архитектуры;
4. системы на основе Интернет/интранет - технологий.
В любой информационной системе можно выделить необходимые функциональные компоненты, которые помогают понять ограничения различных архитектур информационных систем.
Архитектура файл-сервер только извлекает данные из файлов так, что дополнительные пользователи и приложения добавляют лишь незначительную нагрузку на центральный процессор. Каждый новый клиент добавляет вычислительную мощность к сети.
Архитектура клиент-сервер предназначена для разрешения проблем файл-серверных приложений путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации.
В настоящее время архитектура клиент-сервер получила признание и широкое распространение как способ организации приложений для рабочих групп и информационных систем корпоративного уровня. Подобная организация работы повышает эффективность выполнения приложений за счет использования возможностей сервера БД, разгрузки сети и обеспечения контроля целостности данных.
Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в своей классической форме состоит из трех уровней:
1. нижний уровень представляет собой приложения клиентов, имеющие программный интерфейс для вызова приложения на среднем уровне;
2. средний уровень представляет собой сервер приложений;
3. верхний уровень представляет собой удаленный специализированный сервер базы данных.
Трехуровневая архитектура позволяет еще больше сбалансировать нагрузку на разные узлы и сеть, а также способствует специализации инструментов для разработки приложений и устраняет недостатки двухуровневой модели клиент-сервер.
В развитии технологии Интернет/интранет основной акцент пока что делается на разработке инструментальных программных средств. В то же время наблюдается отсутствие развитых средств разработки приложений, работающих с базами данных. Компромиссным решением для создания удобных и простых в использовании и сопровождении информационных систем, эффективно работающих с базами данных, стало объединение Интернет/интранет-технологии с многоуровневой архитектурой. При этом структура информационного приложения приобретает следующий вид: браузер - сервер приложений - сервер баз данных - сервер динамических страниц - web-сервер.
По характеру хранимой информации БД делятся на фактографические и документальные . Если проводить аналогию с описанными выше примерами информационных хранилищ, то фактографические БД - это картотеки, а документальные - это архивы. В фактографических БД хранится краткая информация в строго определенном формате. В документальных БД - всевозможные документы. Причем это могут быть не только текстовые документы, но и графика, видео и звук (мультимедиа).
Автоматизированная система управления (АСУ) - это комплекс технических и программных средств, совместно с организационными структурами (отдельными людьми пли коллективом), обеспечивающий управление объектом (комплексом) в производственной, научной или общественной среде.
Выделяют информационные системы управления образования (Например, кадры, абитуриент, студент, библиотечные программы). Автоматизированные системы для научных исследований (АСНИ), представляющие собой программно-аппаратные комплексы, обрабатывающие данные, поступающие от различного рода экспериментальных установок и измерительных приборов, и на основе их анализа облегчающие обнаружение новых эффектов и закономерностей.Системы автоматизированного проектирования и геоинформационные системы.
Систему искусственного интеллекта, построенную на основе высококачественных специальных знании о некоторой предметной области (полученных от экспертов - специалистов этой области), называют экспертной системой. Экспертные системы - один из немногих видов систем искусственного интеллекта - получили широкое распространение, и нашли практическое применение. Существуют экспертные системы по военному делу, геологии, инженерному делу, информатике, космической технике, математике, медицине, метеорологии, промышленности, сельскому хозяйству, управлению, физике, химии, электронике, юриспруденции и т.д. И только то, что экспертные системы остаются весьма сложными, дорогими, а главное, узкоспециализированными программами, сдерживает их еще более широкое распространение.
Экспертные системы (ЭС) - это компьютерные программы, созданные для выполнения тех видов деятельности, которые под силу человеку-эксперту. Они работают таким образом, что имитируют образ действий человека-эксперта, и существенно отличаются от точных, хорошо аргументированных алгоритмов и не похожи на математические процедуры большинства традиционных разработок.
Лабораторная работа №1
Выделение жизненных циклов проектирования компьютерных систем
Цель работы : ознакомиться с моделями жизненного цикла информационных систем, определить достоинства и недостатки моделей, выбрать модель построения информационной системы индивидуального проектного задания и программные средства, составить план реализации индивидуального проектного задания.
Краткие теоретические сведения.
Жизненный цикл информационной системы
Разработка сложных информационных систем (ИС) невозможна без тщательно обдуманного методологического подхода. Понятие жизненного цикла является одним из базовых понятий методологии проектирования информационных систем.
Жизненный цикл ИС –это непрерывный процесс с момента принятия решения о необходимости принятия решения о необходимости ее создания до полного завершения ее эксплуатации.
Процесс проектирования АИС регламентирован следующей документацией (стандартами, методологиями, моделями):
· ГОСТ 34.601-90. Введен в действие 01.01.1992. Устанавливает стадии и этапы создания автоматизированных систем и дает содержание работ на каждой стадии. Стадии и этапы работы, закрепленные в стандарте, соответствуют каскадной модели жизненного цикла.
· ISO/IEC 12207:1995. Международный стандарт, описывающий процессы жизненного цикла программного обеспечения. Содержит описание более, чем 220 базовых работ, выполнение которых может потребоваться в процессе создания ИС. Все процессы ЖЦ ПО подразделяются на три большие группы:
o Основные процессы (приобретение, поставка, разработка, эксплуатация, сопровождение);
o Вспомогательные процессы (документирование, управление конфигурацией, обеспечение качества, разрешение проблем, аудит, аттестация, совместная оценка, верификация);
o Организационные процессы (создание инфраструктуры, управление, обучение, усовершенствование).
Для реализации положений стандарта должны быть выбраны инструментальные средства, совместно образующие взаимосвязанный комплекс технологической поддержки и автоматизации жизненного цикла программного обеспечения и не противоречащие предварительно скомпонованному набору нормативных документов. Чтобы облегчить практическое применение стандарта, международной организацией по стандартизации были разработаны и утверждены следующие документы:
o ISO/IEC TR 15271:1998 – руководство по применению ISO/IEC 12207;
o ISO/IEC TR 16326:1999 – руководство по управлению проектами при использовании ISO/IEC 12207.
· ISO/IEC 15288:2002. Международный стандарт, описывающий возможные процессы жизненного цикла систем, созданных человеком. Был создан с учетом опыта проектирования автоматизированных информационных систем, а также с привлечением специалистов различных областей: системной инженерии, программирования, администрирования, управления качеством, безопасностью и т.д. Предполагается, что стандарт содержит полное множество процессов, которые могут протекать в ходе жизненного цикла системы. Таким образом, задача разработчика ИС заключается в формировании необходимого ему множества – среды процессов. В обзоре стандарта отмечается, что в нем не содержится описания методов и процедур, необходимых для обеспечения выполнения целей, задач и результатов указанных процессов. В 2003 году выпущено руководство по применению стандарта (ISO/IEC TR 19760:2003). В настоящее время продолжается работа над подготовкой новой редакции стандарта серии 15288.
· Rational Unified Process (RUP) – концепция итеративной (спиральной) разработки программного обеспечения, предложенная фирмой Rational Software (ныне – подразделение IBM). Жизненный цикл ИС представляет собой четыре фазы: начало (inception), исследование (elaboration), конструирование (construction) и внедрение (transition). Каждая фаза может содержать в себе несколько итераций. Кроме того, завершение всех четырех фаз не всегда означает завершение работы над проектом – его развитие может продолжится новым циклом. В рамках итераций производится создание взаимосогласованных моделей, которые описываются на специально разработанном языке UML (Unified Modeling Language).
· Microsoft Solution Framework (MSF). Итерационная методология разработки приложений, аналогичная RUP. Так же включает четыре фазы: анализ, проектирование, разработка, стабилизация и предполагает использование объектно-ориентированного моделирования. По сравнению с RUP в большей степени ориентирована на разработку ИС для бизнеса.
· Extreme Programming (XP). Экстремальное программирование – это самая новая среди рассматриваемых методологий (первые идеи были сформированы в середине 1990-ых). Основные принципы: командная работа, эффективное взаимодействие между заказчиком и исполнителем в течение всего времени разработки ИС, использование последовательно дорабатываемых прототипов, достижение максимальной гибкости разработки (адаптация к изменяющимся требованиям заказчика).
Модели ЖЦ ИС.
Под моделью ЖЦ ИС понимается структура определяющая последовательность выполнения и взаимосвязи процессов действий и задач на протяжении жизненного цикла.
Модель жизненного цикла ИС - это структура, описывающая процессы, действия и задачи, которые осуществляются и ходе разработки, функционирования и сопровождения в течение всего жизненного цикла системы.
Выбор модели жизненного цикла зависит от специфики, масштаба, сложности проекта и набора условий, в которых АИС создается и функционирует.
В соответствии с известными моделями ЖЦ программного обеспечения определяют модели ЖЦ ИС -каскадную, итерационную, спиральную.
I. Каскадная модель описывает классический подход к разработке систем в любых предметных областях; широко использовалась в 1970-80-х гг.
Каскадная модель предусматривает последовательную организацию работ, причем основной особенностью модели является разбиение всей работы на этапы. Переход от предыдущего этапа к последующему происходит только после полного завершения всех работ предыдущего.
Выделяют пять устойчивых этапов разработки, практически не зависящих от предметной области:
На первом этапе проводится исследование проблемной области, формулируются требования заказчика. Результатом данного этапа является техническое задание (задание на разработку), согласованное со всеми заинтересованными сторонами.
В ходе второго этапа, согласно требованиям технического задания, разрабатываются те или иные проектные решения. В результате появляется комплект проектной документации.
Третий этап - реализация проекта; по существу, разработка программного обеспечения (кодирование) в соответствии с проектными решениями предыдущего этапа. Методы реализации при этом принципиального значения не имеют. Результатом выполнения этапа является готовый программный продукт.
На четвертомэтапе проводится проверка полученного программного обеспечения на предмет соответствия требованиям, заявленным в техническом задании. Опытная эксплуатация позволяет выявить различного рода скрытые недостатки, проявляющиеся в реальных условиях работы ИС.
Последний этап - сдача готового проекта.
На каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности. На заключительных этапах разрабатывается пользовательская документация, охватывающая все предусмотренные стандартами виды обеспечения АИС (организационное, информационное, программное, техническое и т. д.). Последовательное выполнение этапов работ позволяет планировать сроки завершения и соответствующие затраты.
При этом для каскадной модели необходимо отметить существенную задержки в получении результатов, сложность параллельного ведения работ по проекту и сложность управления проектом, и как следствие, высокий уровень риска и ненадежность вложений в ИС. Кроме того, ошибки и недоработки на любом из этапов проявляются, как правило, на последующих этапах работ, что приводит к необходимости возврата.
II. Итерационная модель заключается в серии коротких циклов (шагов) по планированию, реализации, изучению, действию. Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.
Создание сложных ИС предполагает проведение согласований проектных решений, полученных при реализации отдельных задач. Подход к проектированию «снизу - вверх» обусловливает необходимость таких итераций возвратов, когда проектные решения по отдельным задачам объединяются в общие системные. При этом возникает потребность в пересмотре ранее сформировавшихся требований.
В итерационной модели межэтапные корректировки обеспечивают меньшую трудоемкость разработки по сравнению с каскадной моделью.
При этом, время жизни каждого этапа растягивается на весь период работки, вследствие большого числа итераций возникают рассогласования выполнения проектных решений и документации, возможно появление на стадии внедрения необходимости перепроектирования всей системы.
III . Спиральная модель , в отличие от каскадной, но аналогично предыдущей предполагает итерационный процесс разработки ИС. При этом возрастает значение начальных этапов, таких как анализ и проектирование, на которых проверяется и обосновывается реализуемость технических решений путем создания прототипов.
Каждая итерация представляет собой законченный цикл разработки, приводящий к выпуску внутренней или внешней версии изделия (или подмножества конечного продукта), которое совершенствуется от итерации к итерации, чтобы стать законченной системой:
Таким образом, каждый виток спирали соответствует созданию фрагмента или версии программного изделия, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы на следующем витке спирали. Каждая итерация служит для углубления и последовательной конкретизации деталей проекта, в результате этого выбирается обоснованный вариант окончательной реализации.
Использование спиральной модели позволяет осуществлять переход на следующий этап выполнения проекта, не дожидаясь полного завершения текущего, - недоделанную работу можно будет выполнить на следующей итерации. Главная задача каждой итерации - как можно быстрее создать работоспособный продукт для демонстрации пользователям. Таким образом, существенно упрощается процесс внесения уточнений и дополнений проект.
Спиральный подход к разработке программного обеспечения позволяет преодолеть большинство недостатков каскадной модели, кроме того, обеспечивает ряд дополнительных возможностей, делая процесс разработки более гибким. При использовании спиральной модели существенно упрощается внесение изменений в проект при изменении требований заказчика, происходит снижение уровня рисков (уровень рисков максимален в начале разработки проекта, по мере продвижения разработки он снижается), обеспечивается большая гибкость в управлении проектом за счет возможности внесения тактических изменений в разрабатываемое изделие, возможность совершенствовать процесс разработки - в результате анализа в конце каждой итерации проводится оценка изменений в организации разработки; на следующей итерации она улучшается, упрощается повторное использование компонентов, поскольку гораздо проще выявить (идентифицировать) общие части проекта, когда они уже частично разработаны, чем пытаться выделить их в самом начале проекта. Спиральная модель позволяет получить более надежную и устойчивую систему. Это связано с тем, что по мере развития системы ошибки и слабые места обнаруживаются и исправляются на каждой итерации. Одновременно корректируются критические параметры эффективности, что в случае каскадной модели доступно только перед внедрением системы. Вовлечение пользователей в процесс проектирования и копирования приложения позволяет получать замечания и дополнения к требованиям непосредственно в процессе проектирования приложения, сокращая время разработки. Представители заказчика получают возможность контролировать процесс создания системы и влиять на ее функциональное наполнение. Результатом является сдача в эксплуатацию системы, учитывающей большинство потребностей заказчиков.
Однако, организация проектирования ИС по спиральной модели обычно имеет высокую стоимость (поэтому ее имеет смысл использовать для сложных и дорогостоящих систем). Модель имеет сложную структуру, что может затруднить ее применение на практике неподготовленными специалистами и заказчиками. Спираль может продолжаться до бесконечности, поскольку каждая ответная реакция заказчика на созданную версию может порождать новый цикл работ. Большое количество промежуточных стадий усложняет ведение документации проекта. Возможны затруднения в определении момента перехода на следующую итерацию цикла. Обычно вводят временные ограничения на выполнение итерации и каждого из ее этапов.
В некоторых ситуациях применение спиральной модели невозможно или ограничено, поскольку невозможно использование/тестирование продукта, обладающего неполной функциональностью (например, военные разработки, атомная энергетика и т.д.). Поэтапное итерационное внедрение корпоративных информационных систем обычно сопряжено с организационными сложностями (перенос данных, интеграция систем, изменение бизнес-процессов, учетной политики, обучение пользователей). Трудозатраты при поэтапном итерационном внедрении оказываются значительно выше, а неграмотное управление процессом внедрения может свести на нет все полученные результаты. По этой причине на этапе внедрения часто обходятся без итерационных моделей, внедряя систему «раз и навсегда».
©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-27
Подобно живому организму, всякий продукт (товар или услуга) имеет свой жизненный цикл , который начинается с момента его «рождения» (или, возможно, с момента зарождения идеи) и заканчивается его «смертью», или изъятием из употребления.
Жизненный цикл ЭИС – совокупность этапов, которые проходит ЭИС в своем развитии от момента принятия решения о ее создании до прекращения функционирования.
Жизненный цикл экономической информационной системы включает следующие этапы:
1) предпроектный;
2) проектирование логическое и техническое;
3) проектирование рабочее (физическое);
4) внедрение;
5) эксплуатацию;
6) изъятие.
Предпроектный этап включает в себя исследование и анализ системы управления компанией, выявляющие имеющихся информационных потребителей. Целью данного этапа является формирование требований к ИС, корректно и точно отражающих цели и задачи организации-заказчика. Чтобы специфицировать процесс создания ИС, отвечающей потребностям организации, нужно выяснить и четко сформулировать, в чем заключаются эти потребности. Для этого необходимо определить требования заказчиков к ИС и отобразить их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие будущей ИС целям и задачам организации.
Задача формирования требований к ИС является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки.
Современные инструментальные средства и программные продукты позволяют достаточно быстро создавать ИС по готовым требованиям. Но зачастую эти системы не удовлетворяют заказчиков, требуют многочисленных доработок, что приводит к резкому удорожанию фактической стоимости ИС. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС на этапе анализа.
На этом этапе должны решаться проблемы, связанные с разработкой технического задания, плана мероприятий по подготовке объекта, включая подготовку персонала и финансирования. На данном этапе также осуществляется анализ осуществимости ИС, а именно рассматривается:
· эксплуатационная осуществимость – возможно ли создание данной ИС, насколько она будет удобно в эксплуатации и отвечать заданным требованиям;
· экономическая осуществимость – стоимость, эффективность с точки зрения пользователя;
Проектирование логическое и техническое – это разработка в соответствии со сформулированными требованиями и выявленными информационными потребностями системной и функциональной архитектуры ЭИС.
На этапе проектирования, прежде всего, формируются модели данных. Проектировщики в качестве исходной информации получают результаты анализа. Построение логической и физической моделей данных является основной частью проектирования базы данных. Полученная в процессе анализа информационная модель сначала преобразуется в логическую, а затем в физическую модель данных.
Параллельно с проектированием схемы базы данных выполняется проектирование процессов, чтобы получить спецификации (описания) всех модулей ИС. Оба эти процесса проектирования тесно связаны, поскольку часть бизнес-логики обычно реализуется в базе данных (ограничения, триггеры, хранимые процедуры). Главная цель проектирования процессов заключается в отображении функций, полученных на этапе анализа, в модули информационной системы. При проектировании модулей определяют интерфейсы программ: разметку меню, вид окон, горячие клавиши и связанные с ними вызовы.
Кроме того, на этапе проектирования осуществляется также разработка архитектуры ИС, включающая в себя выбор платформы (платформ) и операционной системы (операционных систем). В неоднородной ИС могут работать несколько компьютеров на разных аппаратных платформах и под управлением различных операционных систем.
Кроме выбора платформы, на этапе проектирования определяются виды архитектуры:
· архитектура «файл-сервер» или «клиент-сервер»;
· база данных централизованная или распределенная. Если база данных будет распределенной, то какие механизмы поддержки согласованности и актуальности данных будут использоваться;
· серверы, параллельные или одиночные для баз данных (в целях достижения необходимой производительности) и т.д.
Этап проектирования завершается разработкой технического проекта ИС.
Проектирование рабочее (физическое) включает создание и настройку программ, наполнение баз данных, создание рабочих инструкций для персонала. Проектирование заканчивается созданием рабочего проекта.
Рабочий проект – это техническая документация, утвержденная в установленном порядке, содержащая уточненные данные и детализированные общесистемные проектные решения, программы и инструкции по решению задач, а также уточненную оценку экономической эффективности автоматизированной системы управления и уточненный перечень мероприятий по подготовке объекта к внедрению.
В ходе опытного и промышленного внедрения
осуществляется комплексная отводка системы и обучение персонала.
Внедрение системы – это процесс постепенного перехода от существующей ЭИС к новой, предусмотренной документацией рабочего проекта на всю систему. Внедрение отдельных задач и подсистем может проводиться параллельно с разработкой рабочего проекта на всю систему.
Основными этапами внедрения системы являются:
· подготовка объекта к внедрению системы;
· сдача задач и подсистем в опытную эксплуатацию;
· проведение опытной эксплуатации;
· сдача задач, подсистем, системы в целом в промышленную эксплуатацию.
Опытная эксплуатация ИС заключается в проверке алгоритмов, программ и звеньев технологического процесса обработки данных в реальных условиях. Она проводится для следующего:
· окончательной отладки программ и отработки технологического процесса решения задач;
· проверки подготовленности информационной базы;
· отработки взаимосвязи задач системы;
· приобретения навыков работы персоналом предприятия;
· настройки всей системы в целом и устранения выявленных недочетов.
После окончания опытной эксплуатации системы составляется отчет о внедрении. При положительных результатах опытной эксплуатации система сдается в промышленную эксплуатацию.
Эксплуатация ЭИС – ее использование в реальных условиях. В ходе эксплуатации также осуществляется сопровождение, анализ работы системы, исправление ошибок и недоработок, оформление требований и разработка планов по модернизации и расширению системы.
Изъятием ЭИС из эксплуатации называется полное изъятие ЭИС из эксплуатации или существенная модернизация, позволяющая говорить о создании принципиально новой информационной системы.
Существующие модели жизненного цикла определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее распространение получили три следующие модели жизненного цикла:
1) каскадная модель, предполагающая переход на следующий этап после полного окончания работ по предыдущему этапу;
2) поэтапная модель с промежуточным контролем, т.е. итерационная модель разработки с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью, однако время жизни каждого из этапов растягивается на весь период разработки;
3) спиральная модель делает упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии программного изделия, на нем уточняются цели и характеристики проекта, определяется его качество, планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.
На всех этапах жизненного цикла ЭИС большую роль играют специалисты экономического профиля, которые:
· формируют требования к будущей информационной системе или плану ее модернизации;
· осуществляют обоснование и расчет экономической эффективности отдельных решений, используемых в составе ИС и системы в целом;
· участвуют непосредственно в процессе создания ЭИС, помогая моделировать бизнес-процессы и соответствующие им информационные процессы, в том числе и работники предприятия, для которого создается ИС, в соответствии с одним из принципов создания ИС.
· участвуют в отладке системы при передаче ее в эксплуатацию;
· (эксперты) используют свои знания и опыт для наполнения баз данных и знаний;
· на этапе внедрения разрабатывают инструкции и обучают персонал, применяя свои знания и практический опыт.
Исследования последних лет показали, что повышение производительности за счет использования информационных технологий достигается очень редко. Главная причина в том, что новые информационные технологии часто являются зеркальным отображением предыдущих методов и процессов. Осознание этого привело к
появлению нового направления в области управления – реинжиниринга бизнес-процессов, под которым понимается улучшение или совершенствование уже существующего бизнес-процесса за счет использования информационных технологий с параллельным фундаментальным переосмыслением и радикальной переориентацией деловых процессов для достижения резких улучшений важных показателей (повышения производительности, улучшения качества, снижения себестоимости).
Жизненный цикл - это не временной период существования, а процесс последовательного изменения состояния, обусловленный видом производимых воздействий (Р 50-605-80-93) .
Под термином «жизненный цикл системы» обычно понимают эволюцию новой системы в виде нескольких ступеней, включающих такие важные стадии, как концепция , разработка, производство , эксплуатация и окончательное выведение из эксплуатации :70 .
История концепции жизненного цикла
Концепция жизненного цикла возникла в конце XIX в. как комплекс идей, включающих в себя идеи наследственности и развития на уровне индивидуумов и организмов, а также адаптации, выживания и вымирания на уровне отдельных видов и целых популяций живых организмов .
Типовые модели жизненного цикла системы
Не существует единой модели жизненного цикла, удовлетворяющей требованиям любой возможной задачи. Различные организации по стандартизации, правительственные учреждения и инженерные сообщества публикуют свои собственные модели и технологии, которые могут быть использованы для конструирования модели. Таким образом нецелесообразно утверждать о существовании единственно возможного алгоритма построение модели жизненного цикла.
Некоторые специалисты по системной инженерии предлагают рассматривать модель жизненного цикла системы, на основе следующих трех источников: модель управления материально-техническим обеспечением Министерства Обороны США (МО США) (DoD 5000.2), модель стандарта ISO/IEC 15288 и модель Национального общества профессиональных инженеров (NSPE) :71 .
Типовая модель жизненного цикла по стандарту ISO/IEC 15288
Согласно стандарту, процессы и действия жизненного цикла определяются, соответствующим образом настраиваются и используются в течение стадии жизненного цикла, для полного удовлетворения целей и результатов на этой стадии. В различных стадиях жизненного цикла могут принимать участие разные организации. Не существует единой универсальной модели жизненных циклов систем. Те или иные стадии жизненного цикла могут отсутствовать или присутствовать в зависимости от каждого конкретного случая разработки системы :34 .
В стандарте в качестве примера были приведены следующие стадии жизненного цикла:
- Замысел.
- Разработка.
- Производство.
- Применение.
- Поддержка применения.
- Прекращение применения и списание.
В версии стандарта от 2008 года (ISO/IEC 15288:2008) примеры стадий жизненного цикла отсутствуют .
Типовая модель жизненного цикла по версии Министерства обороны США
Для управления рисками в области применения передовых технологий, и сведения к минимуму дорогостоящих технических или управленческих ошибок, МО США разработало руководство, содержащее все необходимые принципы разработки систем. Эти принципы вошли в специальный перечень директив - DoD 5000.
Модель жизненного цикла системы управления материально-техническим обеспечением по версии МО США состоит из пяти стадий :71:
- Анализ.
- Разработка технологии.
- Инженерная и производственная разработка.
- Производство и развертывание.
- Функционирование и поддержка.
Типовая модель жизненного цикла системы Национального общества профессиональных инженеров (NSPE)
Данная модель адаптирована для развития коммерческих систем. Данная модель в основном направлена на развитие новых продуктов, обычно являющихся результатом технического прогресса. Модель NSPE представляет собой альтернативный взгляд на модель версии МО США. Жизненный цикл по модели NSPE разбивается на шесть стадий :72:
- Концепция.
- Техническая реализация.
- Разработка.
- Коммерческая валидация и подготовка производства.
- Полномасштабное производство.
- Поддержка конечного продукта.
Типовая модель жизненного цикла продукции по Р 50-605-80-93
В руководящем документе Р 50-605-80-93 тщательно проработан жизненный цикл промышленного изделия, в том числе - военной техники .
Для промышленной продукции гражданского назначения предложены следующие стадии:
- Исследование и проектирование.
- Изготовление.
- Обращение и реализация.
- Эксплуатация или потребление.
В рамках жизненного цикла промышленной продукции гражданского назначения предложено рассматривать 73 вида работ и 23 типа стейкхолдеров («участников работ» по терминологии документа).
Для промышленной продукции военного назначения предложены следующие стадии:
- Исследование и обоснование разработки.
- Разработка.
- Производство.
- Эксплуатация.
- Капитальный ремонт.
В рамках жизненного цикла промышленной продукции военного назначения предложено рассматривать 25 видов работ и 7 типов стейкхолдеров (участников работ).
Типовая модель жизненного цикла программного обеспечения
Стадии жизненного цикла системы и их составные фазы, представленных на рисунке «Модель жизненного цикла системы», относятся к большинству сложных систем, в том числе к тем, которые содержат программное обеспечение со значительным объемом функциональных возможностей на уровне компонентов. В программно-интенсивных системах, в которых программное обеспечение выполняет практически все функции (как например в современных финансовых системах, в системах бронирования авиабилетов, в глобальной сети интернет, и в др.), как правило жизненные циклы схожи по содержанию, но часто усложняются итерационными процессами и прототипированием :72-73 .
Основные стадии жизненного цикла системы (Kossiakoff, Sweet, Seymour, Biemer)
Как показано на рисунке «Модель жизненного цикла системы», модель жизненного цикла системы содержит 3 стадии. Первые 2 стадии приходятся на разработку, а третья стадия охватывает пост-разработку. Эти стадии показывают более общие переходы из состояния в состояние, в жизненном цикле системы, а также показывают изменения в типе и объеме действий, вовлеченных в системную инженерию. Стадии представляют собой :73:
- стадию разработки концепции;
- стадию технической разработки;
- стадию пост-разработки.
Стадия разработки концепции
Целью стадии разработки концепции являются оценки новых возможностей в сфере применения системы, разработка предварительных системных требований и возможных проектных решений. Стадия разработки концептуального проекта начинаются с момента осознания необходимости создания новой системы или модификации уже имеющейся. Стадия включает в себя начало исследований фактов, периода планирования, оцениваются экономические, технические, стратегические и рыночные основы будущих действий. Осуществляется диалог между стейкхолдерами и разработчиками .
Основные цели стадии разработки концепции :74:
- Провести исследования, установив, что является необходимым для новой системы, а также установив техническую и экономическую целесообразность данной системы.
- Изучить потенциально возможные концепции системы, а также сформулировать и подвергнуть валидации набор требований к производительности системы.
- Выбрать наиболее привлекательную концепцию системы, определить её функциональные характеристики, а также разработать детальный план последующих стадий проектирования, производства и оперативного развертывания системы.
- Разработать любую новую технологию, подходящую для выбранной концепции системы и подвергнуть валидации её способности удовлетворять потребности.
Стадия технической разработки
Стадия технической разработки подразумевает процесс проектирования системы для реализации функций, сформулированных в концепции системы, в физическое воплощении, которые могут поддерживаться и успешно эксплуатироваться в своей операционной среде. Системная инженерия в первую очередь касается направления развития разработки и проектирования, управления интерфейсами, разработки планов тестирования, и определяет, как расхождения в производительности системы, не проверенной во время тестирования и оценки, должны быть надлежащим образом исправлены. Основная масса инженерных действий осуществляется на этой стадии.
Основными целями стадии технической разработки являются :74:
- Выполнение технической разработки прототипа системы, отвечающего требованиям производительности, надежности, ремонтопригодности и безопасности.
- Спроектировать систему пригодную для использования, и продемонстрировать свою оперативную пригодность.
Стадия пост-разработки
Стадия пост-разработки состоит из деятельности за пределами периода разработки системы, но все еще требует значительной поддержки со стороны системных инженеров, особенно когда встречаются непредвиденные проблемы, требующие скорейшего разрешения. Кроме того, достижения в области технологий часто требуют внутренней модернизации системы обслуживания, которая может быть столь же зависимой от системной инженерии, как стадии концепции и технической разработки.
.В основе деятельности по созданию и использованию программного обеспечения (ПО) лежит понятие его жизненного цикла (ЖЦ).
ЖЦИС - это период создания и использования ИС, начиная с момента возникновения потребности в ИС и заканчивая моментом полного её выхода из эксплуатации.
ЖЦ является моделью создания и использования ПО, отражающей его различные состояния, начиная с момента возникновения необходимости в данном программном изделии и заканчивая моментом его полного выхода из употребления у всех пользователей.
Традиционно выделяются следующие основные этапы ЖЦ ПО:
анализ требований;
проектирование;
кодирование (программирование);
тестирование и отладка;
эксплуатация и сопровождение.
Стадии жизненного цикла информационной системы
Предпроектное обследование
1.1. Сбор материалов для проектирования; при этом выделяют формулирование требований, изучение объекта автоматизации, даются предварительные выводы предпроектного варианта ИС.
1.2. Анализ материалов и разработка документации; обязательно даётся технико-экономическое обоснование с техническим заданием на проектирование ИС .
Проектирование
2.1. Предварительное проектирование:
выбор проектных решений по аспектам разработки ИС;
описание реальных компонент ИС;
оформление и утверждение технического проекта (ТП).
выбор или разработка математических методов или алгоритмов программ;
корректировка структур БД;
создание документации на доставку и установку программных продуктов;
выбор комплекса технических средств с документацией на её установку.
2.2. Детальное проектирование:
2.3. Разработка техно-рабочего проекта ИС (ТРП).
2.4. Разработка методологии реализации функций управления с помощью ИС и описанием регламента действий аппарата управления.
Разработка ИС
получение и установка технических и программных средств;
тестирование и доводка программного комплекса;
разработка инструкций по эксплуатации программно-технических средств.
Ввод ИС в эксплуатацию
ввод технических средств;
ввод программных средств;
обучение и сертификация персонала;
опытная эксплуатация;
сдача и подписание актов приёмки-сдачи работ.
Эксплуатация ИС
повседневная эксплуатация;
общее сопровождение всего проекта.
ЖЦ образуется в соответствии с принципом нисходящего проектирования и, как правило, носит итерационный характер: реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с изменениями требований и внешних условий, введением ограничений и т.п. На каждом этапе ЖЦ порождается определённый набор документов и технических решений; при этом для каждого этапа исходными являются документы и решения, полученные на предыдущем этапе. Каждый этап завершается верификацией порождённых документов и решений с целью проверки их соответствия исходным.
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 [5 ] (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - InternationalElectrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.
Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трёх группах процессов:
основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);
вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);
организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
Разработка включает в себя все работы по созданию ПО и его компонент в соответствии с заданными требованиями. Сюда включается оформление проектной и эксплуатационной документации, подготовка материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов , материалов, необходимых для организации обучения персонала и т.д. Разработка ПО включает в себя, как правило, анализ, проектирование и реализацию (программирование).
Эксплуатация включает в себя работы по внедрению компонентов ПО в эксплуатацию. В этот процесс входит конфигурирование базы данных и рабочих мест пользователей, обеспечение эксплуатационной документацией, проведение обучения персонала и т.д., и непосредственно эксплуатацию, в том числе локализацию проблем и устранение причин их возникновения, модификацию ПО в рамках установленного регламента, подготовку предложений по совершенствованию, развитию и модернизации системы.
Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает выбор методов и инструментальных средств для реализации проекта, определение методов описания промежуточных состояний разработки, разработку методов и средств испытаний ПО, обучение персонала и т.п. Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования ПО.
Верификация - это процесс определения того, отвечает ли текущее состояние разработки, достигнутое на данном этапе, требованиям этого этапа. Проверка позволяет оценить соответствие параметров разработки с исходными требованиями. Проверка частично совпадает с тестированием, которое связано с идентификацией различий между действительными и ожидаемыми результатами и оценкой соответствия характеристик ПО исходным требованиям. В процессе реализации проекта важное место занимают вопросы идентификации, описания и контроля конфигурации отдельных компонентов и всей системы в целом.
Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего, процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учёта их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учёта, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2.
Каждый процесс характеризуется определёнными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО носит итерационный характер: результаты очередного этапа часто вызывают изменения в проектных решениях, выработанных на более ранних этапах.
