Жизненный цикл программного изделия и его модели

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

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

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

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

Мотивация изучения жизненного цикла и его моделей

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

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

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

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

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

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

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

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

• Это знание даже для непрофессионального программиста помогает понять, на что можно рассчитывать при заказе или приобретении программного обеспечения и что нереально требовать от него. В частности, неудобные моменты работы с программой, ее ошибки и недоработки обычно устраняются в ходе продолжающейся разработки, и есть основания ожидать, что последующие версии будут лучше. Однако кардинальные изменения концепций программы — задача другого проекта, который совсем необязательно будет во всех отношениях лучше данной системы.
• Модели жизненного цикла — основа знания методологий программирования и инструментария, поддерживающего их. Программист всегда использует в своей работе инструменты, но квалифицированный программист знает, где, когда и как их применять. В этом ему помогают понятия моделирования жизненного цикла: любая методология базируется на определенных представлениях о жизненном цикле, выстраивает свои методы и инструменты вокруг фаз и этапов жизненного цикла.
• Общие знания о том, как развивается программный проект, дают наиболее надежные ориентиры для его планирования, позволяют экономнее расходовать ресурсы, добиваться более высокого качества управления. Все это относится к сфере профессиональных обязанностей руководителя программного проекта.
• Общие знания помогают менеджеру проекта выстраивать надежную аргументацию при отстаивании своей точки зрения перед заказчиком, перед руководством фирмы, перед другими заинтересованными лицами.
• Наконец, знание технологических функций^{1Напомним, что мы называем функцию технологической, если последовательность выполнения составляющих ее поручений не требует дополнительных разъяснений для исполнителя (см. лекцию 2). Таким образом, технологическая функция — это не элемент некоторой технологии, а организационная или производственная функция в деятельности исполнителя. Они могут быть элементами любого производства, в частности ремесленного и мануфактурного.}, которые на разных этапах должны выполнять разработчики, занимающие те или иные роли, способствует правильному распределению обязанностей сотрудников.

Ниже модели жизненного цикла представлены в виде, позволяющем рассматривать их, абстрагируясь от специфики разработки конкретных программных систем. Описываются традиционные модели и их развитие, приспособленное к потребностям объектно-ориентированного проектирования. Изложение в значительной степени основано на материалах работы [ 22 ] и в соответствии с линией, которая определена в работе [ 16 ] . Тем не менее оно не буквально следует этим работам, а дополняется и уточняется в связи с задачами менеджмента. По той же причине опускается ряд деталей, несущественных в контексте этих задач.

Если деятельность разработчиков программного проекта поддерживается на всех основных этапах жизненного цикла, т.е. проект ведется в условиях использования некоторой так называемой CASE-системы (Computer Aided Software Engineering), то заранее установлены определенные рамки, включая контрольные точки, когда менеджер должен организовывать управляющие воздействия. Это, естественно, ограничение вариантов развития проекта. И также естественно, что CASE-система навязывает априорное представление о жизненном цикле, фиксированное поддерживаемой моделью. В такой ситуации может возникнуть ложное впечатление о единственности модели жизненного цикла. В результате, когда приходится менять условия разработки, коллектив может оказаться не готов к этому.

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

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