Понятие жизненного цикла программного продукта

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

· последовательность этапов (фаз, стадий): инициации, проектирования, изготовления образца, организация производства, серийное производство, эксплуатация, ремонт, вывод из эксплуатации;

· состоящих из технологических процессов, действий и операций.

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

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

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

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

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

А правомерно ли переносить такой поход из сферы материального производства на программирование? Если да, то мы должны с самого начала разграничить два вида деятельности в этой области:

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

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

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

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

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

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

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

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

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

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

 

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

 

Рис. 5.1. Схема жизненного цикла ПО на этапах разработки, использования и сопровождения.

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

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

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

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

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

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

Впервые о жизненном цикле ПО заговорили в 1968 г. в Лондоне, где состоялась встреча 22-х руководителей проектов по разработке ПО. На встрече анализировались проблемы и перспективы проектирования, разработки, распространения и поддержки программ. Применяющиеся принципы и методы разработки ПО требовали постоянного усовершенствования. Именно на этой встрече была предложена концепция жизненного цикла ПО (SLC – Software Lifetime Cycle) как последовательности шагов-стадий, которые необходимо выполнить в процессе создания и эксплуатации ПО.

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