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

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

знать

• • понятие жизненного цикла информационной системы, его стадии и стандарты;
• • основные процессы жизненного цикла информационной системы;
• • модели жизненного цикла информационной системы;
• • действия по моделям жизненного цикла информационной системы;

уметь

• • управлять жизненным циклом информационной системы;
• • проводить анализ и оценку эффективности на всех этапах жизненного цикла информационной системы;

владеть

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

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

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

Согласно этой теории обычно выделяют следующие стадии жизненного цикла организации: рождение и становление, рост, зрелость, упадок или возрождение. При рождении и становлении главная цель организации заключается в выживании и выходе на рынок, получении прибыли в ближайшей перспективе и ускоренном росте; далее идут укрепление позиций и захват рынка [18]. В период зрелости главная цель — систематический сбалансированный рост, формирование индивидуального имиджа, рост по разным направлениям деятельности, завоевание рынка, разделение и кооперация труда, премирование в соответствии с индивидуальными результатами. На стадии упадка главной целью является сохранение достигнутых результатов, стабильность результатов, свободный режим организации труда, участие и прибылях. Если далее возможно возрождение этой организации, то необходимо обеспечить оживление, омоложение, внедрение инновационного механизма, внедрение научной организации труда и коллективное премирование.

Теория жизненного цикла применима и к продукции производственнотехнического назначения. В этом случае жизненный цикл, согласно ГОСТ Р 53 791—2010 «Ресурсосбережение. Стадии жизненного цикла изделий производственно-технического назначения. Общие положения», включает в себя следующие стадии: обоснование разработки, разработку технического задания, проведение опытно-конструкторских работ, производство и испытания, модернизацию, использование (эксплуатацию); ликвидацию (включая утилизацию и (или) удаление отходов).

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

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

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

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

Вскоре после этой конференции вблизи Лондона собрались 22 руководителя из различных стран, которые курировали разработку ПО в академиях, научно-исследовательских лабораториях и на предприятиях. На этой встрече обсуждались решения, принятые на прошедшей ранее конференции, и была предложена концепция жизненного цикла разработки ПО (Software life cycle, SLC), которая реализует последовательность событий, происходящих при разработке ПО. Особо подчеркивалась роль организационного процесса. При управлении организационным процессом «определяются, реализуются и поддерживаются рабочие процессы в организации. Процесс определяется как парадигма управления, обеспечивающая улучшение качества с помощью формального определения процесса, измерения процесса, обратной связи и контроля, усовершенствования, оптимизации»^[1].

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

1) планирование краткосрочной цели; 2) делать то, что требуется по плану; 3) проверять; 4) действовать. К. Ишикава увеличил количество исходных четырех этапов Деминга до шести: планирование разделил на два этапа, а именно — определение целей и задач и определение методов достижения цели, а выполнение — на участие в образовании и обучении и внедрение рабочего процесса ^{[2]. Шесть новых этапов цикла Деминга — Шухарта — Ишикавы для IT-проектов отображаются на оригинальном цикле PDCA (Plan-Do-Check-Act — планирование-действие-проверка-корректировка) следующим образом: планирование отображается в план; выполнение отображается в исследование, наблюдение и анализ; проверка отображается в адаптацию; действие отображается в улучшение.}

Большое значение имеет принятый в то время стандарт IEEE 1074 (Institute of Electrical and Electronics Engineers — Институт инженеров по электротехнике и электронике), являющийся картой обработки для процесса жизненного цикла разработки ПО (Software life cycle process, SLCP). Процесс SLCP определяется как характерное для проекта описание процесса, который основывается на жизненном цикле ПО проекта (SLC), а также на интегральных процессах и процессах менеджмента, используемых организацией. Интегральные процессы включают менеджмент конфигурации, метрические показатели, обеспечение качества, уменьшение степени риска, действия по оценке, планированию и обучению. Реализация подобной методологии начинается с выбора соответствующей модели жизненного цикла разработки ПО (Software life cycle model, SLCM) с целью ее применения в рамках определенного проекта. Затем создается SLC, используя отобранную модель SLCM и действия, характерные для этой модели. Стандарт IEEE 1074 не обращается к действиям не программного характера наподобие заключения контракта, приобретения или разработки аппаратных средств. Он также не дает полномочий для использования определенной модели SLCM. В стандарте IEEE 1074 предполагается, что менеджер проекта и архитектор процесса уже знакомы с разнообразием процессов модели SLCM, с критериями их выбора, а также с критериями определения признаков и ограничений конечной системы и среды разработки, которые влияют на этот выбор. Стандарт одинаково пригоден к разработке процесса SLCP на любом уровне.

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

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

• 1) выбор модели SLCM;
• 2) сравнение действий с требованиями модели SLCM;
• 3) размещение действий во временной последовательности;
• 4) проверка информационного потока;
• 5) назначение выхода действия для поставляемых продуктов;
• 6) включение процессов поддержки жизненного цикла, который рассматривается, добавление активов организационного процесса (Organizational process asset, О РА) [18].

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

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

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

Обобщенная схема процесса, согласно стандарту IEEE 1074, представлена на рис. 3.1 К^[3]

Рис. 3.1. Обобщенная схема процесса.

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

Основными разработчиками стандартов по управлению жизненным циклом информационных систем (ЖЦ ИС) являются Институт программного инжиниринга (Software Engineering Institute, SEI), IEEE. Управление процессами жизненного цикла информационных систем гарантирует корректное выполнение процедур, стратегий и реализацию модели жизненного цикла.

Согласно Международному стандарту ISO/IEC 12 207:1995, в жизненный цикл ПО (ЖД ПО) входят: основные процессы; вспомогательные процессы; организационные процессы. Основные процессы ЖЦ ПО включают процессы: приобретения, поставки; разработки; эксплуатации; сопровождения. Если рассмотреть процесс разработки более детально, то видно, что он имеет как требования к системе, так и требования к ПО, а именно выбор модели ЖЦ ПО, анализ требований к системе, проектирование архитектуры системы, анализ требований к ПО, проектирование архитектуры ПО, детальное проектирования ПО, кодирование и тестирование ПО, интеграцию ПО, квалификационное тестирование ПО, интеграцию системы, квалификационное тестирование системы, установку ПО, приемку ПО.

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

В настоящее время для разработки модели жизненного цикла используются стандарты ГОСТ Р ИСО/МЭК 15 288−2005 и ГОСТ Р ИСО/МЭК 12 207−2010.

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

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

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

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

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

Особое внимание^[3] уделяется определенному пониманию и применению стандартов во взаимосвязи с моделью зрелости функциональных возможностей (Capability Maturity Model, СММ), которая служит «каркасом» процесса разработки ПО. Когда говорят об уровне развития функциональных возможностей, обычно подразумевают строго определенную стадию развития, направленного на получение законченного процесса разработки ПО. Эта модель предполагает, что существуют следующие ключевые области процесса по уровням зрелости:

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

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

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

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

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

В СССР в 1980;е гг. были разработаны и использовались стандарты комплекса ГОСТ 34 [22]. Он задумывался как всеобъемлющий комплекс взаимоувязанных межотраслевых документов, рассчитанный на взаимодействие заказчика и разработчика. ГОСТ 34 в основном уделяет внимание содержанию проектных документов, а распределение действий между сторонами обычно отталкивается от этого содержания. Отдельно существовал ГОСТ 24.204—80, который разработан для определения требований к содержанию документа «Описание постановки задачи». Подробные методические указания к написанию технического задания определялись ГОСТ 24.202—80 «Технико-экономическое обоснование создания АСУ».

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

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

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

• [1] 2 Шафер Д. Ф., Фатрелл Р. 7'., Шафер Л. И. Управление программными проектами: достижение оптимального качества при минимуме затрат: пер. с англ. М.: Вильямс, 2003.
• [2] Ishikawa К., Lu D. /. What is Total Quality Control? The Japanese Wav. Englewood Cliffs, N. J.: Prentice Hall, 1988.
• [3] Шафер Д. Ф, Фатрелл Р. Т., Шафер Л. И. Указ. соч.
• [4] Шафер Д. Ф, Фатрелл Р. Т., Шафер Л. И. Указ. соч.