Информационные технологии и информационные системы. Жизненный цикл информационной системы

Таблица 2.1

Определения.

1. Определение стандарта ISO/IEC 15288:2008 (Определение: life cycle -- evolution of a system, product, service, project or other human-made entity from conception through retirement (ISO 15288, 4.11):

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

2. Определение стандарта ISO 15704 (Industrial automation systems - Requirements for enterprise-reference architectures and methodologies Системы промышленной автоматизации. Требования к архитектуре эталонных предприятий и методологии. Описывает эталонную архитектуру предприятия и средства реализации проектов в рамках полнрго жизненного цикла предприятия):

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

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

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

Комментарий: жизненный цикл – всегда жизненный цикл конкретной системы. Не бывает «жизненного цикла» кроме как в текстах стандартов, в жизни всегда «жизненный цикл X», где X – название целевой системы. Процессы жизненного цикла – это те процессы, которые акторы выполняют над/с системой, и которые меняют состояние системы, заставляя ее эволюционировать в ходе её жизненного цикла. «Управление жизненным циклом» -- общепринятое название подхода к описанию процессов жизненного цикла (а часто и название самой группы процессов жизненного цикла, описанных с использованием такого подхода).

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

Прежде всего, нужно различить жизненный цикл (иногда, ограничиваясь только инженерией, но не полным ЖЦ говорят также delivery process, изредка для софта -- software process) и другие "процессные представления" -- трансакции DEMO, логические "бизнес-процессы" (практики), workflows, проектные представления (подробнее -- http://ailev.livejournal.com/904643.html). Хотя есть множество подходов, при которых все эти разные аспекты описаний организации и методов ее работы смешиваются.

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

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

· «Нарезанная колбаска»

· V-диаграмма

Нарезанная колбаска".

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

Рисунок 2.1. Традиционное представление жизненного цикла

Вокруг традиционной «колбаски» могут указываться еще две дополнительных: как ЖЦ видят менеджеры (лица, управляющие проектом), и как ЖЦ видят инженеры(лица, реализующие проект) (рис.2.2)

Рисунок 2.2. Пример представления жизненного цикла

Жизненные циклы наблюдаются в историях отдельных товаров и потребностей, торговых марок, предприятий, целых индустрий и рынков. Жизненный цикл неотделим от конкретной системы, поэтому особенности разных систем порождают большое разнообразие экземпляров «колбасок» жизненных циклов (рис.2.3) .

Рис.2.3. Разнообразие жизненных циклов

Жизненный цикл системы является старейшим методом построения информа­ционных систем, в наши дни он используется при создании сложных проектов среднего и крупного масштабов. Данный процесс включает в себя шесть этапов: 1) подготовка проекта; 2) исследование системы; 3) проектирование; 4) програм­мирование; 5) инсталляция; 6) эксплуатация и освоение системы. Эти этапы изо­бражены на рис. 10.7. Каждый этап включает в себя несколько процессов.

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

Systems lifecycle (жизненный цикл системы)

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

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

Этапы жизненного цикла системы

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

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

аналитики совместно с программистами готовят спецификации для каждой про­граммы, входящей в систему.

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

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

Project definition (определение проекта)

Один из этапов системного жизненного цикла, позволяющий сформулиро­вать организационные проблемы, которые могут быть решены при помощи новой информационной системы. Systems study (исследование системы)

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

Design (проектирование)

Этап, на котором разрабатываются проектные спецификации для системного

Programming (программирование)

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

Installation (установка)

Данный этап состоит из трех процессов: тестирования, обучения персонала и конверсии; последних подготовительных стадий перед вводом системы в экс­плуатацию. Postimplementation (эксплуатация и освоение системы)

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

небольших настольных систем, которые по своей природе более индивидуализи­рованы, т. е. «настроены» на определенного пользователя.

Создание прототипа

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

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

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

На рис. 10.8 изображен процесс создания прототипа, состоящий из четырех сле­дующих этапов (шагов):

Шаг 1. Определение основных пользовательских требований. Проектировщик системы (как правило, в его роли выступает специалист по информационным си­стемам) работает совместно с пользователем до тех пор, пока не уяснит потребно­сти последнего.

Шаг 2. Разработка начального прототипа. Проектировщик быстро создает ра­бочую модель, используя программное обеспечение нового поколения, мультиме­дийные программы или системы автоматизированного проектирования (см. гл. 14).

Шаг 3. Работа с прототипом. Пользователь оценивает работу системы и дает рекомендации по ее улучшению.

Prototyping (создание прототипа)

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

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

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

Шаг 4. Исправление и совершенствование прототипа. Проектировщик реали­зует на практике все пожелания пользователей. После внесения изменений и ис­правления ошибок процесс возвращается к шагу 3. Шаги 3 и 4 повторяются до тех пор, пока пользователь не будет полностью удовлетворен.

Когда итерации прекращаются, модель становится «рабочим прототипом», на основе которого составляются окончательные спецификации системы. Иногда та­кой прототип просто используется как рабочая версия информационной системы.

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

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

End-user interface (пользовательский интерфейс)

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

Но быстрое создание прототипа может создать иллюзию ненужности некото­рых важных этапов разработки системы. Если завершенная модель работает нор­мально, руководство компании может решить, что такие процессы, как програм­мирование, реконструкция системы и подготовка исчерпывающей документации, не играют существенной роли в создании полностью работоспособной системы. Некоторые из систем, созданные в такие сжатые сроки, не могут оперировать большими объемами данных или же не в состоянии поддерживать много пользо­вателей одновременно. Процесс создания прототипа может также сильно замед­литься, если в нем участвуют слишком много пользователей (Hardgrove, Wilson, and Eastman, 1999).

Пакеты прикладных программ

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

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

Если потребности организации настолько оригинальны, что им не соответ­ствует ни один пакет программ, то можно использовать возможности кастомиза-ции (настройки), которые содержатся в большинстве современного программного обеспечения. Подобная настройка позволяет модифицировать пакет таким обра­зом, чтобы он соответствовал нуждам предприятия, не нарушая его целостности и функциональности. Если предполагаются слишком серьезные изменения, то дополнительные работы по перепрограммированию и настройке могут обойтись очень дорого и отнять много времени, к тому же они могут свести на «нет» многие преимущества данного пакета программ. На рис. 10.9 показано, как растет соот­ношение цены пакета и стоимости его внедрения с увеличением степени касто-мизации. Изначальная продажная цена пакета может на практике не соответство­вать действительности, поскольку в ней не учтены скрытые расходы на настройку и внедрение.

Application software package (пакет прикладных программ)

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

Customization (кастомизация)

Настройка и модификация программного пакета под нужды конкретной орга­низации, не нарушающие его целостности и функциональности.

Выбор программного пакета

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

Разработка конечными пользователями

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

Request for proposal (RFP) (запрос предложений)

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

End-user development (разработка конечными пользователями)

Разработка информационных систем конечными пользователями при незна­чительном участии технических специалистов.

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

Жизненный цикл - это не временной период существования, а процесс последовательного изменения состояния, обусловленный видом производимых воздействий (Р 50-605-80-93).

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

Энциклопедичный YouTube

1 / 5

Видео 22. Жизненный цикл ПО. Этапы разработки ПО. Классическая модель разработки ПО

"Жизненный цикл системы или проекта" - тренинг №2.

Жизненный цикл товара.mp4

Жизненный цикл дефекта

Жизненный цикл организации

Субтитры

История концепции

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

Типовые модели жизненного цикла системы

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

Некоторые специалисты по системной инженерии предлагают рассматривать модель жизненного цикла системы, на основе следующих трех источников: модель управления материально-техническим обеспечением Министерства Обороны США (МО США) (DoD 5000.2), модель стандарта ISO/IEC 15288 и модель Национального общества профессиональных инженеров (NSPE). :71

Типовая модель жизненного цикла по стандарту ISO/IEC 15288

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

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

1. Стадия замысла.
2. Стадия разработки.
3. Стадия производства.
4. Стадия применения.
5. Стадия поддержки применения.
6. Стадия прекращения применения и списания.

В версии стандарта от 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

1. Провести исследования, установив, что является необходимым для новой системы, а также установив техническую и экономическую целесообразность данной системы.
2. Изучить потенциально возможные концепции системы, а также сформулировать и подвергнуть валидации набор требований к производительности системы.
3. Выбрать наиболее привлекательную концепцию системы, определить её функциональные характеристики, а также разработать детальный план последующих стадий проектирования, производства и оперативного развертывания системы.
4. Разработать любую новую технологию, подходящую для выбранной концепции системы и подвергнуть валидации её способности удовлетворять потребности.

Стадия технической разработки

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

Основными целями стадии технической разработки являются :74:

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

Стадия пост-разработки

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

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

ISO/IEC 15288:2008 Systems and software engineering - Life cycle processes

Kossiakoff A., Sweet W. N., Seymour S. J., Biemer S. M. Systems Engineering Principles and Practice. - 2-е изд. - Hoboken, New Jersey: A John Wiley & Sons, 2011. - 599 с. - ISBN 978-0-470-40548-2 .

Батоврин В. К. , Бахтурин Д. А. Управление жизненным циклом технических систем. - 2012.

ГОСТ Р ИСО/МЭК 15288-2005 Информационная технология. Системная инженерия. Процессы жизненного цикла систем

Р 50-605-80-93. Рекомендации. Система разработки и постановки продукции на производство. Термины и определения (Ссылка на текст).

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

Жизненный цикл ЭИС – совокупность этапов, которые проходит ЭИС в своем развитии от момента принятия решения о ее создании до прекращения функционирования.

Жизненный цикл экономической информационной системы включает следующие этапы:

1) предпроектный;

2) проектирование логическое и техническое;

3) проектирование рабочее (физическое);

4) внедрение;

5) эксплуатацию;

6) изъятие.

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

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

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

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

· эксплуатационная осуществимость – возможно ли создание данной ИС, насколько она будет удобно в эксплуатации и отвечать заданным требованиям;

· экономическая осуществимость – стоимость, эффективность с точки зрения пользователя;

Проектирование логическое и техническое – это разработка в соответствии со сформулированными требованиями и выявленными информационными потребностями системной и функциональной архитектуры ЭИС.

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

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

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

Кроме выбора платформы, на этапе проектирования определяются виды архитектуры:

· архитектура «файл-сервер» или «клиент-сервер»;

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

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

Этап проектирования завершается разработкой технического проекта ИС.

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

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

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

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

Основными этапами внедрения системы являются:

· подготовка объекта к внедрению системы;

· сдача задач и подсистем в опытную эксплуатацию;

· проведение опытной эксплуатации;

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

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

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

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

· отработки взаимосвязи задач системы;

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

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

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

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

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

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

1) каскадная модель, предполагающая переход на следующий этап после полного окончания работ по предыдущему этапу;

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

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

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

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

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

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

· участвуют в отладке системы при передаче ее в эксплуатацию;

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

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

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

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

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

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

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

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

Стадии жизненного цикла ИС

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

Согласно методологии, предлагаемой Rational Software, жизненный цикл информационной системы подразделяется на четыре стадии.

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

1) Начальная стадия

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

2) Стадия уточнения

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

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

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

3) Стадия конструирования

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

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

4) Стадия передачи в эксплуатацию

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

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

Стандарты жизненного цикла ИС

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

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

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

ISO/IEC 12207(International Organization of Standardization /International Electrotechnical Commission)1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

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

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

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

спиральный жизненный цикл каскадный