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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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