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

Последовательное развитие проекта и итеративное наращивание

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

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

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

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

Понятно, что этот подход часто подвергался критике. В качестве достаточно полного собрания аргументов против него можно указать на соответствующую главу в книге Г. Буча [ 8 ] . Однако до недавнего времени все предложения, которые выдвигались в противовес недостаткам последовательного развития, на поверку оказывались лишь паллиативами, неспособными кардинально решить проблему. Реальный прогресс оказался возможным лишь тогда, когда было продемонстрировано, что средствами объектно-ориентированного программирования можно реализовать стратегию итеративного развития проектов, которая характеризуется постепенным предоставлением необходимых пользователю средств и гибким реагированием на вновь возникающие требования (см. лекцию 5).

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

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

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

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

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