Скопин И.Н. Основы менеджмента программных проектов. Курс лекций - файл n1.doc

Скопин И.Н. Основы менеджмента программных проектов. Курс лекций
скачать (9790.7 kb.)
Доступные файлы (1):
n1.doc9791kb.21.10.2012 17:31скачать

n1.doc

  1   2   3   4   5   6   7   8   9   10   11
Скопин И.

Менеджмент программных проектов

(материалы к специальному курсу)
Содержание

1.1.Заявка на проект 24

1.2.Особенности планирования и управления 125


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

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

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

Функциональные роли в коллективе разработчиков

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Жизненный цикл в объектно-ориентированном проектировании

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

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

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

Таблица 1.1

Традиционные схемы

Объектно-ориентированная схема

Полностью завершенные
фазы проектирования и
программирования

Итеративно наращиваемые
возможности

Традиционные фазы распределяются по итерациям

Продукт в конце периода разработки

Рабочие продукты на каждой итерации

Техническое описание как итог конструирования

Рабочее описание, дополняемое на каждой итерации

Последовательная разработка

Возвратно-поступательная разработка

Модули действий, операций

Иерархии классов объектов

Структурная, пошаговая детализация

Наследование, переопределение, полиморфизм



Модели жизненного цикла программного обеспечения

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

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




Использование

Разработка







Продолжающаяся разработка




(сопровождение)


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

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

Общепринятая модель

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

Фазы разбиваются на ряд этапов (см. рис. 2.1 и 2.2).


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

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

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

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

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

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

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

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

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

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

Классическая итерационная модель

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

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

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

Каскадная модель

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

Характерные черты каскадной модели:

Рис. 2.3. Классическая итерационная модель

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

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



Рис 2.4. Каскадная модель

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

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

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

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

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

Модель фазы — функции

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

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

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

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







Исследова-




ния  










Анализ осуществи-







мости  




Фазы (этапы):







Конструирова-










ние  



















  Программирование










  Оценка































  Использование  



















 Спецификации утверждены




























4 Спецификации составлены







Контрольные точки (события):










3 Требования утверждены
















2 Требования сформулированы













1 Ресурсы распределены










0 Необходимость разработки признана
















Компоновка завершена 6 
















Независимые испытания начались7 
















Начато изготовление изделия 8 













Изделие передано на распространение 9 










Изделие снято с производства 10 

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

На протяжении фаз жизненного цикла разработчики выполняют следующие технологические функции (классы функций):

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

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





Исследова-




ния  










Анализ осуществи-







мости  




Фазы:







Конструирова-













ние  




Функции:













Программирование










  Оценка




























  Использование  

Планирование





























































Разработка
































































Обслуживание
































































Выпуск документации


























































Испытания
































































Поддержка



































































Сопровождение















































































 5 Спецификации утверждены



















4 Спецификации составлены







Контрольные точки (события):










3 Требования утверждены













2 Требования сформулированы










1 Ресурсы распределены










0 Необходимость разработки признана
















Компоновка завершена 6 
















Независимые испытания начались7 
















Начато изготовление изделия 8 













Изделие передано на распространение 9 










Изделие снято с производства 10 


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

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










Исследова-




ния  










Анализ осуществи-







мости  




Фазы (этапы):







Конструирова-










ние  



















  Программирование










      Оценка































  Использование  



















 Спецификации утверждены




























4 Спецификации составлены







Контроль-ные точки (события):










3 Требования утверждены
















2 Требования сформулированы













1 Ресурсы распределены










0 Необходимость разработки признана
















Компоновка завершена 6 
















Независимые испытания начались7 
















Начато изготовление изделия 8 













Изделие передано на распространение 9 










Изделие снято с производства 10 

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

Объектно-ориентированные модели жизненного цикла

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

Принципиальные моменты, в которых два подхода к развитию проектов стоит сопоставить, сводятся к следующему:

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

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

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

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

В ходе итеративного наращивания обыкновенно выполняются вполне традиционные этапы:

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

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

По вполне понятным причинам в объектно-ориентированном проектировании несколько изменяется содержание ряда этапов, что нашло свое отражение в наименованиях событий (см. рис. 2.8).

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









Исследова-




ния  










Анализ осуществи-







мости  




Фазы (этапы):







Конструирова-










ние  



















  Программирование










   Оценка




 






















­— —































  Использование  



















 Спецификации утверждены




























4 Спецификации реализуемых компонентов составлены










Контроль-ные точки (события):










3 Требования к очередной итерации утверждены



















2 Общие требования составлены,

общий план составлен
















1 Ресурсы распределены













0 Необходимость разработки признана



















Автономная проверка завершена,

комплексное тестирование началось 6 



















Тестирование завершилось,

начата подготовка новой итерации 7 



















Требования к новой итерации приняты 8 
















Начато изготовление изделия 9 













Изделие передано на распространение 10 










Изделие снято с производства 11 

Рис. 2.8. Модель жизненного цикла при объектно-ориентированном развитии проекта

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

Фаза завершения проекта включает в себя:

После того, как приложение используется некоторое время, и оно может рассматриваться как готовое, в рамках данной фазы осуществляется:

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

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

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


Планирование итерации (1-2, 7-8)

Анализ

(2-3)

Конструирование (3-5)

Программирование (4-7)

Тестирование (6-7)

Оценка (7-8)


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


I.

Пл

Ан

Ко

Пр

Те

Оц




II.

Пл

Ан

Ко

Пр

Те

Оц




III.

Пл

Ан

Ко

Пр

Те

Оц


б) Три итерации проекта I, II и III, развиваемые одновременно

Пл

Ан

Ко

Пр

Те

Оц













Совмещение не допустимо

Совмещение
возможно

Совмещение рационально

Последовательное выполнение


в) Пределы совмещения итераций в проекте

Рис. 2.9. Распараллеливание выполнения итераций проекта

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

Рис. 2.9 б) демонстрирует три одновременно выполняемые итерации: вторая начинается после завершения программирования первой итерации, а третья — в ходе этапа конструирования второй итерации.

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

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

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



Рис. 2.10. Спираль развития объектно-ориентированного проекта

Предпроектная деятельность менеджера и начало фазы исследования

Данная тема охватывает деятельность менеджера, которая выходит за временные рамки жизненного цикла программного изделия. Первый этап этой деятельности начинает проект (контрольная точка 0 «Необходимость разработки признана»). Завершается предпроектная деятельность, когда утверждено распределение ресурсов для разработки (контрольная точка 1, следуя принципам модели Гантера, здесь, как и для других периодов развития проекта, целесообразно говорить о перекрытии смежных этапов).

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

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

Немногим лучше, когда заказчик объявляет конкурс на разработку. Здесь определенности больше, но более или менее жесткие рамки конкурсного заказа ограничивают возможности предложений, которые может высказать менеджер. Пример, ставший классическим. При объявлении конкурса на разработку единого языка МО США (впоследствии он получил название Ада) были выдвинуты и одобрены мировой общественностью требования Ironman. Все четыре анонимные финалиста (языки Red, Yellow, Green и Blue), естественно, удовлетворяли этим требованиям. Однако за исключением Green эти языки в целом оказались совершенно неудовлетворительными. Green-Ада в меньшей степени следовал букве Ironman, но именно это выгодно отличало единственную европейскую конкурсную разработку. Более того, по весьма авторитетному мнению Дейкстры, требования Ironman оказались чрезмерно жесткими, и необходимость удовлетворять им не позволило авторам языка достичь по-настоящему хороших результатов (критика Дейкстры характеризует Green лишь как приемлемый язык, испорченный чрезмерно настойчивыми предписаниями из Ironman).

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

Это одна сторона предпроектного взаимодействия с заказчиком. Другая сторона — необходимо убедить заказчика в том, что именно ваша фирма (команда) способна наилучшим способом справиться с поставленной задачей, поскольку:
    1.   1   2   3   4   5   6   7   8   9   10   11


Учебный материал
© bib.convdocs.org
При копировании укажите ссылку.
обратиться к администрации