Концепция жизненного цикла в практике использования информационных технологий

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

Роль стандартов в жизненном цикле информационных систем

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

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

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

• Рождение и становление.
• Рост.
• Зрелость.
• Упадок или возрождение.

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

Теория жизненного цикла

Теорию жизненного цикла организации можно применять в том числе и к продукции производственно-технического назначения. В такой ситуации жизненный цикл, в соответствии с ГОСТ 53791 – 2010 "Ресурсосбережение. Стадии жизненного цикла изделий производственно-технического назначения. Общие положения", состоит из нескольких стадий: обоснование разработки, разработка технического задания, проведение опытно-конструкторских работ, производство и испытания, модернизация, использование, ликвидация, удаление.

В теории маркетинга рассматривается характеристика этапов жизненного цикла товара:

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

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

Источником данного процесса стала Германия, где в 1968 г. на конференции подкомитета NATO по науке и технике, в которой приняло участие более 50 профессионалов-разработчиков программного обеспечения из 11 стран, впервые была признана общественная значимость управления программными проектами.

Спустя некоторое время на конференции неподалёку от Лондона, собрались 22 руководителя из разных стран мира, чтобы курировать разработку программного обеспечения в академиях, научно-исследовательских лабораториях, а также на предприятиях. Эта встреча была посвящена обсуждениям концепции жизненного цикла разработки программного обеспечения, которая реализует последовательность событий, происходящих при разработке ПО. Особое внимание в процессе обсуждения уделялось роли организационного процесса. При управлении организационным процессом необходимо установить, реализовать и поддержать рабочие процессы в организации. Данный процесс можно определить как парадигму управления, которая помогает улучшить качество посредством формального определения процесса, измерения процесса, обратной связи и контроля, усовершенствования и оптимизации.

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

• Планирование краткосрочной цели.
• Выполнять действия в соответствии с планом.
• Проверять сделанное.
• Действовать.

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

Таким образом, шесть новый этапов цикла Деминга – Шухарта – Ишикавы для IT-проектов представлены в оригинальном цикле PDCA так: планирование отображается в план; выполнение отображается в исследование, наблюдение и анализ; проверка отображается в адаптацию; действие отображается в улучшение.

Важную роль играет принятый в те времена стандарт IEEE 1074 (Institute of Electrical and Electronics Engineers – Институт инженеров по электротехнике и электронике, который выступает в качестве путеводителя обработки для процесса жизненного цикла разработки ПО.

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

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

Стандарт IEEE 1074 – это пошаговое руководство, которое представляет собой описание реализации девяти этапов, которые определяют методы выполнения процессов SLCP:

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

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

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

Модель SLCM и её особенности

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

В 1995 г. был разработан Международный стандарт ISO/IEC 12207: 1995 "Information Technology — Software Life Cycle Processes". (ISO - International Organization for Standardization, Международная организация по стандартизации, IEC — International Electrotechnical, Commission Международная комиссия по электротехнике). Данный стандарт даёт следующее определение жизненному циклу программного обеспечения: период времени, который начинается с момента принятия решения о необходимости создания программного обеспечения и завершается в момент его полного изъятия из эксплуатации.

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

 В соответствии с Международным стандартом ISO/IEC 12207:1995, жизненный цикл программного обеспечения состоит из следующих элементов: основные процессы, вспомогательные процессы, организационные процессы. В свою очередь, основные процессы жизненного цикла программного обеспечения состоят из следующих: приобретение, поставка, разработка, эксплуатация, сопровождение. Примечательно, что при детальном рассмотрении процесса разработки заметно, что он имеет как требования к системе, так и требования к программному обеспечению, а если более конкретно, что именно выбор модели жизненного цикла программного обеспечения, анализ требований к системе, проектирование архитектуры системы, анализ требований к программному обеспечению, проектирование архитектуры ПО, детальное проектирование ПО, кодирование и тестирование, интеграцию в программное обеспечение, квалификационное тестирование ПО, интеграцию системы, квалификационное тестирование системы, установку ПО, приёмку ПО.

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

ГОСТ Р ИСО/МЭК 15288—2005 необходим для установления общих основ с целью описания жизненного цикла систем, которые создаются человеком на протяжении всего жизненного цикла системы для реализации и управления отдельно взятыми стадиями жизненного цикла. Одновременно с этим не детализируются процессы жизненного цикла в терминах методов и процедур и не устанавливаются требования к документации.

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

Процессы жизненного цикла системы можно поделить на четыре группы процессов:

1. Процессы соглашения.
2. Процессы предприятия.
3. Процессы проекта.
4. Технические процессы.

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

ГОСТ Р ИСО/МЭК 12207—2010 необходима для определения процессов, видов деятельности и задач, которые применяются в процессе приобретения программного продукта или услуги, в том числе при поставке, разработке, применении по назначению, сопровождении и прекращении применения программных продуктов. Данный стандарт применяется при покупке систем, программных продуктов и услуг, при их поставке, разработке, применении по назначению сопровождении и прекращении применения программных продуктов и программных компонентов системы как в самой организации, так и за её пределами. Справедливо заметить, что данный стандарт используется для программных продуктов, а также для программных услуг.

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

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

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

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

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

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

Критиками каскадной модели жизненного цикла высказывались мнения, что ещё в 1981 г. в соответствии с высказываниями Боэма "… использование термина “последовательный” для описания фаз разработки программного обеспечения является “удобным упрощенчеством”". Основной посыл Боэма, который описывал прототипирование и инкрементную разработку как альтернативных вариантов, состоял в том, что это последовательная каскадная модель. Именно он стал открывателем, который предложил известную спиральную модель. Начиная с каскадной, каждая из его моделей была более совершенной, нежели предыдущая модель. 

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

Во времена СССР в 1980-е гг. разрабатывались и использовались стандарты комплекса ГОСТ 34. Его основная идея состояла в том, чтобы играть роль всеобъемлющего комплекса взаимоувязанных межотраслевых документов, рассчитанный на взаимодействие заказчика и разработчика. Особенность ГОСТ 34 состояла в том, что он концентрирует собственное внимание на содержании проектных документов, а распределение действий между сторонами зачастую отталкиваются от данного содержания. Обособленно существовал ГОСТ 24.204-80, разработка которого велась конкретно для определения требований к содержанию документа "Описание постановки задачи".

В работе "Управление качеством программного обеспечения" Б.В. Черников достаточно глубоко исследует назначение и содержание единой системы программной документации). В основном стандарты ЕСПД состоят из требований к составу, содержанию и оформлению документов, которые описывают программное средство на разных стадиях его жизненного цикла. Помимо всего прочего, несколько документов, которые посвящаются порядку хранения и обновления документации также содержатся в требованиях. Стандарты ЕСПД не содержат методической составляющей. Они не объясняют разработчику, как необходимо составлять документацию, чтобы она была достаточно полезной, понятной, информативной и удобной. Они предлагают разработчику лишь ознакомиться с перечнем типов документов и списком разделов первого уровня для каждого из них. При этом важно обратить внимание на то, что для каждого раздела определены некоторые уточнения, какие сведения должны быть в нём изложены.

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

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