Из рабочей учебной программы:

Тема 2. Стандарты и нормативные руководства по системной и программной инженерии.

Стандарт ISO/IEC 15288 «Системная инженерия - процессы жизненного цикла систем".

ГОСТ 34: Комплекс стандартов на автоматизированные системы.

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

2.1. Стандарт ISO 15288 «Системная инженерия - процессы жизненного цикла систем".

2.2. Жизненный цикл системы.

2.3. Представления жизненного цикла системы.

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

2.5. Модели жизненного цикла

2.6. Выбор модели жизненного цикла

2.1. Стандарт iso 15288 «системная инженерия - процессы жизненного цикла систем".

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

Задачи стандарта:

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

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

• системного подхода

  жизненного цикла

  инжиниринга требований

  архитектурного дизайна

  процессного подхода

  проектного подхода

  культуры контрактации

Ис т ория создания

Совместная разработка ISOиIEC, активное участиеINCOSE

Начало работ в 1996, версии в 2002, 2005 (ГОСТ Р ИСО/МЭК 15288-2005), 2008

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

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

2.2. Жизненный цикл системы

Аббревиатура русск: ЖЦ

Аббревиатура англ: LC (Life Cycle )

Русский: «жизненный цикл» . Английское life cycle в технике ранее означало и переводилось как «срок службы», и иногда даже «срок службы до первого капитального ремонта». «Жизненный цикл» -- это относительно новый перевод. Иногда «цикл» переводят как «период», но такой перевод не устоялся (хотя он и точнее в данном случае: «период жизни» системы). Слово «цикл» не должно смущать – ничего циклического в жизненном цикле нет. Слово «цикл» имеет смысл «типичности», говоря о том, что то же самое происходит и с другими системами.

Формально: жизненный цикл – это смена состояний системы (эволюция системы) в период времени от замысла до прекращения её существования.

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

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

Определение стандарта 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):

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

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

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

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

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

Таблица 2.1

Стадии создания систем (ISO/IEC 15288)
№ п./п	Стадия	Описание
	Формирование концепции	Анализ потребностей, выбор концепции и проектных решений
	Разработка	Проектирование системы
	Реализация	Изготовление системы
	Эксплуатация	Ввод в эксплуатацию и использование системы
	Поддержка	Обеспечение функционирования системы
	Снятие с эксплуатации	Прекращение использования, демонтаж, архивирование системы

Жизненный цикл системы является старейшим методом построения информа­ционных систем, в наши дни он используется при создании сложных проектов среднего и крупного масштабов. Данный процесс включает в себя шесть этапов: 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. Рекомендации. Система разработки и постановки продукции на производство. Термины и определения (Ссылка на текст).

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

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

Следует отметить, что в Советском Союзе, а затем в России создание программного обеспечения ( ПО ) первоначально, в 70-е годы прошлого столетия, регламентировалось стандартами ГОСТ ЕСПД (Единой системы программной документации – серии ГОСТ 19.ХХХ), которые были ориентированы на класс относительно простых программ небольшого объема, создаваемых отдельными программистами. В настоящее время эти стандарты устарели концептуально и по форме, их сроки действия закончились и использование нецелесообразно.

Процессы создания автоматизированных систем ( АС ), в состав которых входит и ПО , регламентированы стандартами ГОСТ 34.601-90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Стадии создания", ГОСТ 34.602-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы" и ГОСТ 34.603-92 "Информационная технология. Виды испытаний автоматизированных систем". Однако многие положения этих стандартов устарели, а другие отражены недостаточно, чтобы их можно было применять для серьезных проектов создания ПС. Поэтому в отечественных разработках целесообразно использовать современные международные стандарты.

В соответствии со стандартом ISO / IEC 12207 все процессы ЖЦ ПО разделены на три группы (рис.5.1).

Рис. 5.1.

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

5.2. Основные процессы ЖЦ ПС

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

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

Инициирование приобретения включает следующие задачи:

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

Заявочные предложения должны содержать:

1. требования, предъявляемые к системе;
2. перечень программных продуктов;
3. условия приобретения и соглашения;
4. технические ограничения (например, по среде функционирования системы).

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

Подготовка и корректировка договора включает следующие задачи:

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

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

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

1. инициирование поставки;
2. подготовку ответа на заявочные предложения;
3. подготовку договора;
4. планирование работ по договору;
5. выполнение и контроль договорных работ и их оценку;
6. поставку и завершение работ.

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

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

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

Процесс разработки включает следующие действия:

1. подготовительную работу;
2. анализ требований, предъявляемых к системе;
3. проектирование архитектуры системы;
4. анализ требований, предъявляемых к программному обеспечению;
5. проектирование архитектуры программного обеспечения;
6. детальное проектирование программного обеспечения;
7. кодирование и тестирование программного обеспечения;
8. интеграцию программного обеспечения;
9. квалификационное тестирование программного обеспечения;
10. интеграцию системы;
11. квалификационное тестирование системы;
12. установку программного обеспечения;
13. приемку программного обеспечения.

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

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

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

Анализ требований к программному обеспечению предполагает определение следующих характеристик для каждого компонента ПО :

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

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

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

1. трансформацию требований к ПО в архитектуру, определяющую на высоком уровне структуру ПО и состав его компонентов;
2. разработку и документирование программных интерфейсов ПО и баз данных (БД);
3. разработку предварительной версии пользовательской документации;
4. разработку и документирование предварительных требований к тестам и плана интеграции ПО.

Детальное проектирование ПО включает следующие задачи:

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

Кодирование и тестирование ПО включает следующие задачи:

1. кодирование и документирование каждого компонента ПО и базы данных, а также подготовку совокупности тестовых процедур и данных для их тестирования;
2. тестирование каждого компонента ПО и БД на соответствие предъявляемым к ним требованиям с последующим документированием результатов тестирования;
3. обновление документации (при необходимости);
4. обновление плана интеграции ПО.

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

Квалификационное тестирование ПО проводится разработчиком в присутствии заказчика (

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

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

   1. планирование действий и работ, выполняемых в процессе эксплуатации, и установка эксплуатационных стандартов;
   2. определение процедур локализации и разрешения проблем, возникающих в процессе эксплуатации.
2. Эксплуатационное тестирование, осуществляемое для каждой очередной редакции программного продукта, после чего эта редакция передается в эксплуатацию.
3. Собственно эксплуатация системы, которая выполняется в предназначенной для этого среде в соответствии с пользовательской документацией.
4. анализ проблем и запросов на модификацию ПО (анализ сообщений о возникшей проблеме или запроса на модификацию, оценка масштаба, стоимости модификации, получаемого эффекта, оценка целесообразности модификации);
5. модификацию ПО (внесение изменений в компоненты программного продукта и документацию в соответствии с правилами процесса разработки);
6. проверку и приемку (в части целостности модифицируемой системы);
7. перенос ПО в другую среду (конвертирование программ и данных, параллельная эксплуатация ПО в старой и новой среде в течение некоторого периода времени);
8. снятие ПО с эксплуатации по решению заказчика при участии эксплуатирующей организации, службы сопровождения и пользователей. При этом программные продукты и документации подлежат архивированию в соответствии с договором.

(MSF). Включает 4 фазы: анализ, проектирование, разработка, стабилизация, предполагает использование объектно-ориентированного моделирования.

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

Стандарт ГОСТ 34 .601-90

Стандарт ISO/IEC 12207/ и его применение

Стандарт ISO/IEC 12207:1995 «Information Technology - Software Life Cycle Processes» является основным нормативным документом, регламентирующим состав процессов жизненного цикла ИС. Он определяет структуру жизненного цикла, содержащую процессы , действия и задачи , которые должны быть выполнены во время создания ИС.

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

Процессы жизненного цикла ИС

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

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

1. Инициирование приобретения
2. Подготовка заявочных предложений
3. Подготовка и корректировка договора
4. Надзор за деятельностью поставщика
5. Приемка и завершение работ

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

1. Формирование требований к системе
2. Формирование списка программных продуктов
3. Установление условий и соглашений
4. Описание технических ограничений (среда функционирования системы и т. д.)

Стадии жизненного цикла ИС, взаимосвязь между процессами и стадиями

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

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

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

Каскадная модель жизненного цикла («модель водопада» , англ. waterfall model ) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

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

1. Формирование требований
2. Проектирование
3. Реализация
4. Тестирование
5. Ввод в действие
6. Эксплуатация и сопровождение

Спиральная модель

Итерационная модель

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

Литература

• Братищенко В.В. Проектирование информационных систем. - Иркутск: Изд-во БГУЭП, 2004. - 84 с.
• Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2000.
• Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. - М.: Интернет-университет информационных технологий - ИНТУИТ.ру, 2005.
• Мишенин А.И. Теория экономических информационных систем. - М.: Финансы и статистика, 2000. - 240 с.

Примечания

Wikimedia Foundation . 2010 .

• «Исследования новейшей русской истории»
• Дробница

Смотреть что такое "Жизненный цикл информационной системы" в других словарях:

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

Жизненный цикл - Термин «Жизненный цикл» используется в различных областях знаний. Содержание 1 В биологии 2 В информатике 3 В астрономии … Википедия

Жизненный цикл базы данных - Необходимо перенести содержимое этой статьи в статью «Жизненный цикл информационной системы». Вы можете помочь проекту, объединив статьи. В случае необходимости обсуждения целесообразности объединения, замените этот шаблон на шаблон {{к об … Википедия

жизненный цикл - 4.16 жизненный цикл (life cycle): Развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения. Источник …

Жизненный цикл изделия - (продукции) это совокупность процессов, выполняемых от момента выявления потребностей общества в определенной продукции до момента удовлетворения этих потребностей и утилизации продукта. Жизненный цикл продукции (ЖЦП) включает период от… … Википедия

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

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

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

ГОСТ 34.003-90: Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения - Терминология ГОСТ 34.003 90: Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения оригинал документа: 1.1 автоматизированная система; АС: Система, состоящая из персонала и … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р 52611-2006: Системы промышленной автоматизации и их интеграция. Средства информационной поддержки жизненного цикла продукции. Безопасность информации. Основные положения и общие требования - Терминология ГОСТ Р 52611 2006: Системы промышленной автоматизации и их интеграция. Средства информационной поддержки жизненного цикла продукции. Безопасность информации. Основные положения и общие требования оригинал документа: 3.14 владелец… … Словарь-справочник терминов нормативно-технической документации , В. В. Кеворков, Д. В. Кеворков. Рассматриваются процессы разработки стратегии и миссии компании, создания единой информационной среды, методика анализа конъюнктуры рынка товаров (услуг) и его сегментирование. Изложены…