Размещено на http://www.allbest.ru/

КУРСОВАЯ РАБОТА

на тему: «Жизненный цикл ПО и методологии программирования»



Содержание

1. Жесткие и гибкие стратегии в методологиях программирования, их характерные черты и границы применимости. Модели RUP, XP, MSF

2. Методологические стратегии

3. Определение этапов проекта: последовательное развитие проекта

4. Сужение текущей задачи проекта: итеративное наращивание возможностей

5. Жесткие и гибкие стратегии в методологиях программирования

6. Производственные функции в моделировании жизненного цикла: модель фазы-функции

7. Фазовое измерение

8. Функциональное измерение

9. Учет итерационного развития

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

11. Rational Unified Process (RUP)

12. Rational Unified Process как продукт

13. Модель Rational Unified Process

14. Модель процессов MSF

15. Базовые принципы MSF

16. Жизненный цикл в методологиях быстрого развития проектов

17. Экстремальное программирование (ХР)

18. Базовые принципы ХР

19. Основные методики ХР



1. Жесткие и гибкие стратегии в методологиях программирования, их характерные черты и границы применимости. Модели RUP, XP, MSF

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

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

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

При этом в технических и строительных проектах принято разграничивать два вида деятельности:

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

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

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

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

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

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

2. Методологические стратегии

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

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

Рис. 6.1. Конус операционных маршрутов проекта



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

Рис. 6.2. Выявление отклонений и корректировка траектории

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

3. Определение этапов проекта: последовательное развитие проекта

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

Постановка задачи каждого этапа характеризуется:

- субъектом-исполнителем;

- сроками, когда должны быть решены задачи;

- выделенными ресурсами;

- средствами, инструментами и методами решения задач;

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

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

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

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

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

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

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

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

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

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



4. Сужение текущей задачи проекта: итеративное наращивание возможностей

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

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

На рис. 6.4 стратегия итеративного наращивания изображена в виде схемы.



Рис. 6.4. Итеративное наращивание возможностей системы

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

5. Жесткие и гибкие стратегии в методологиях программирования

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

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

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

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

Охарактеризовать все методологии быстрого развития по отдельности не представляется возможным -- слишком различны их исходные принципы, слишком зависимы они от специфики коллективов, занимающихся разработками программного обеспечения, от зачастую стихийно складывающихся предпочтений и привычек. На стратегическом уровне их действительно объединяет так называемый Agile Manifesto, принятый энтузиастами в феврале 2001 года в местечке Сноуберд (США), который сводится к четырем постулатам:

- индивидуумы и их взаимодействие важнее процессов и инструментов;

- работоспособное программное обеспечение важнее обширной документации;

- сотрудничество с заказчиком важнее заключения контракта;

- готовность к изменениям важнее следования плану.

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

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

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

В приведено сопоставление жесткой и быстрой стратегий в методологиях программирования.

Таблица 6.1. Сопоставление жесткой и быстрой стратегий в методологиях программирования

Жесткие методологии	Быстрые методологии
Ориентация на предсказуемые процессы разработки программного обеспечения с четко обозначенными целями	Осознание того, что процессы разработки программного обеспечения в принципе непредсказуемы
Распознавание ситуаций и применение готовых методов	Распознавание ситуаций и конструирование методов для работы в них
Планирование, в котором определяются этапы с объемом работ, ресурсами, сроками и уровнем качества работ	Соблюдение баланса между параметрами проекта: объем работ, ресурсы, сроки и уровень качества работ
Заказчик -- внешний по отношению к проекту субъект, влияющий на разработку только через предоставление ресурсов и контроль результатов, в том числе по поэтапным срокам выполнения проекта	Заказчик (его представитель) -- член команды разработчиков, наделенный правом влиять на разработку; его главной целью является отслеживание актуальности решаемых задач
Ролевое разделение труда работников проекта	Совместная деятельность сотрудников и персонифицированная ответственность
Дисциплина и подчинение	Самодисциплина и сотрудничество
Обезличенный процесс, исполнители которого определяются только по квалификационным требованиям	Процесс, максимально учитывающий личностные качества исполнителей

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

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

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

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

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

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

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

6. Производственные функции в моделировании жизненного цикла: модель фазы-функции

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

Наиболее последовательно такое дополнение классической схемы реализовано в модели Гантера в виде матрицы «фазы -- функции». Уже из упоминания о матрице следует, что модель Гантера имеет два измерения:

- фазовое, отражающее этапы выполнения проекта и сопутствующие им события;

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



7. Фазовое измерение

В модели Гантера отражено то, что выполнение функции на одном этапе может продолжаться на следующем. На рис. 6.5 представлено фазовое измерение модели. Жирной чертой (с разрывом и стрелкой, обозначающей временное направление) изображен процесс разработки. Контрольные точки и наименования событий указаны под этой чертой. Они пронумерованы. Все развитие проекта в модели привязывается к этим контрольным точкам и событиям.

В данной модели жизненный цикл распадается на следующие перекрывающие друг друга фазы (этапы):

- Этап исследования -- начинается, когда необходимость разработки признана руководством проекта (контрольная точка 0), и заключается в том, что для проекта обосновываются необходимые ресурсы (контрольная точка 1) и формулируются требования к разрабатываемому изделию (контрольная точка 2).

- Анализ осуществимости -- начинается на этапе исследования, когда определены исполнители проекта (контрольная точка 1), и завершается утверждением требований (контрольная точка 3). Цель этапа -- определить возможность конструирования изделия с технической точки зрения (достаточно ли ресурсов, квалификации и т.п.), будет ли изделие удобно для практического использования; решение вопросов экономической и коммерческой эффективности.



Рис. 6.5. Фазовое измерение модели фазы -- функции

- Конструирование -- начинается обычно на этапе анализа осуществимости, как только документально зафиксированы предварительные цели проекта (контрольная точка 2), и заканчивается утверждением проектных решений в виде официальной спецификации на разработку (контрольная точка 5).

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

- Оценка -- является буферной зоной между началом испытаний и практическим использованием изделия. Этап начинается, как только проведены внутренние (силами разработчиков) испытания изделия (контрольная точка 6) и заканчивается, когда подтверждается готовность изделия к эксплуатации (контрольная точка 9).

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

8. Функциональное измерение

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

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

- содержание (цели) функции на различных этапах претерпевает изменение;

- интенсивность функции (в частности, потребности в ресурсах, необходимых для выполнения) меняется как при переходе от этапа к этапу, так и в рамках работ одного этапа.

Эти положения требуют отражения при моделировании жизненного цикла.

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

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

Исходя из этих предпосылок, строится второе измерение модели Гантера. Гантер говорит о следующем наборе функций (если угодно -- классов функций).

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

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

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



Рис. 6.6. Матрица фазы--функции модели Гантера

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

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

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

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

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

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

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

9. Учет итерационного развития

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

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

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

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

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



Рис.6.7. Учет итеративности в модели фазы-функции (фазовое измерение, показаны лишь некоторые возвраты)

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

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

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

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

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

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

11. Rational Unified Process (RUP)

Сегодня 51% программных разработок применяют CASE-системы, поддерживающие RUP -- Rational Unified Process. Уже одного этого достаточно, чтобы обратить внимание на данный поход и исследовать, за счет чего он обеспечивает ощутимую пользу для практических разработок. Безусловно, достоинством RUP является предлагаемый инструментарий моделирования различных аспектов реализуемого программного обеспечения, и именно этот инструментарий применяется чаще всего. Он привлекает разработчиков выразительностью, поддержкой согласованного использования систем моделей, связываемых общей системой понятий.

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

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

Существует четыре функции процесса разработки программного обеспечения:

1. Обеспечивать руководство последовательностью действий команды.

2. Определять, какие артефакты должны создаваться и когда.

3. Указывать, чем должны заниматься отдельные разработчики и целые команды.

4. Предлагать критерии наблюдения и измерения продуктов и видов деятельности проекта.

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

Rational Unified Process основан на шести лучших советах по организации процесса разработки программного обеспечения:

- Разрабатывайте итеративно

- Управляйте требованиями

- Пользуйтесь модульными архитектурами

- Используйте визуальное моделирование

- Не забывайте о проверке качества

- Следите за изменениями

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

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

Rational Unified Process -- это продукт процесса, разработанный корпорацией Rational Software. Он неразрывно связан с выпускаемым корпорацией набором средств для разработки программного обеспечения.

Rational Unified Process -- это еще и контур процесса, который можно адаптировать и расширить для удовлетворения требований принявшей его организации.

История создания унифицированного процесса уходит корнями в поздние 60-е, когда Айвар Якобсон (Ivar Jacobson) работал над проектом в компании Ericsson. Якобсон и его коллеги смоделировали большую телекоммуникационную систему, используя слои "блоков", при этом нижние ярусы служили основой для подсистем на верхних ярусах (можно провести параллель между блоками и тем, что сейчас называют компонентами). Для построения блоков низкого уровня команда изучила то, что тогда называли случаями в потоках информации (в UML их называют прецедентами); от них в большей или меньшей степени зависел весь последующий анализ, разработка, реализация и тесты. Остальные диаграммы из тех, что сейчас являются ключевыми аспектами UML, также развились из проекта компании Ericsson, включая диаграммы последовательности (тогда их называли диаграммами взаимодействия объектов) и диаграммы видов действий (ранее графики смены состояний). В документе, который содержал описание архитектуры программного обеспечения, был представлен основной материал, касающийся упрощения диалога между разработчиками и клиентами, а также между самими разработчиками.

В 1987 году Якобсон организовал собственную компанию Objectory AB. Он и его коллеги потратили несколько лет на разработку Objectory, который одновременно был и продуктом и процессом, каким является унифицированный процесс компании Rational. Его книга Object-Oriented Software Engineering (Addison-Wesley, 1995), где подробно описан процесс Objectory, стала поворотным пунктом в области объектно-ориентированного программирования; это была первая книга, в которой методист высказывает идею о том, что требования клиента, выраженные в терминах прецедентов, должны быть основной движущей силой в разработке программного обеспечения. В ней было впервые оговорено значение, которое в унифицированном процессе придается архитектуре. Полная интерактивная версия процесса появилась вместе с книгой в 1995 году.

Вскоре после этого Компания Rational купила Objectory AB, и Якобсон уже со значительно расширившимся кругом коллег принялся за развитие областей, которых процесс Objectory не касался глубоко, а именно организации проектирования и инструментов разработки. Гради Буч (Grady Booch) и Джим Рамбо (Jim Rumbaugh) уже в то время работали в компании Rational -- Буч почти с момента образования, а Рамбо с конца 1994 года. Эти джентльмены и Якобсон, которые приобрели известность как "три товарища", были среди лидеров проекта создания Rational Objectory Process (ROP) и параллельно работали над расширением унифицированных методов до унифицированного языка моделирования (Unified Modeling Language -- UML).

В то время как продолжалась работа над ROP и UML, компания Rational занималась приобретением и поглощением нескольких компаний, создававших инструменты для разработки программного обеспечения. Инструменты оказались полезными для ROP и применялись для организации управления требованиями (инструмент компании Requisite переименован в RequisitePro), общего тестирования (программное обеспечения производства SQA было разделено на несколько отдельных инструментов) и в других сферах, таких, как тестирование рабочих характеристик, управление конфигурацией и организация внесения изменений. В 1998 году компания Rational изменила название продукта на RUP.

В 2003 году компания Rational Software вошла в состав IBM.

12. Rational Unified Process как продукт

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

«Процесс разработки программного обеспечения -- это тоже программное обеспечение», -- сказал Ли Остервейл (Lee Osterweil). В противоположность работам в «пыльных переплетах», Rational Unified Process проектируется, разрабатывается, сдается и эксплуатируется подобно любому программному продукту. Действительно, Rational Unified Process присущи многие свойства программных продуктов.

...