5565

МИНОБРНАУКИ РОССИИ

Федеральное государственное бюджетное образовательное учреждение высшего образования

«Нижегородский государственный архитектурно-строительный университет»

Папкова М.Д.

УПРАВЛЕНИЕ ИТ-ПРОЕКТАМИ

Учебно-методическое пособие по подготовке к лекциям, практическим занятиям

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

выполнению курсовой работы

для обучающихся по дисциплине «Управление ИТ-проектами» по направлению подготовки 09.04.03 Прикладная информатика профиль Прикладная информатика в аналитической экономике

Нижний Новгород

2022

УДК 004.9

Папкова М.Д. / Управление ИТ-проектами : учебно-методическое пособие / М.Д. Папкова; Нижегородский государственный архитектурно-строительный университет – Нижний Новгород: ННГАСУ, 2022. – 25 с. – Текст: электронный.

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

Учебно-методическое пособие предназначено для обучающихся в ННГАСУ по дисциплине «Управление ИТ-проектами» по направлению подготовки 09.04.03 Прикладная информатика, профиль Прикладная информатика в аналитической экономике.

© М.Д. Папкова, 2022

© ННГАСУ, 2022

2

Оглавление

3

1. Общие положения

1.1 Цели изучения дисциплины и результаты обучения

Основными целями освоения учебной дисциплины «Управление ИТ-проектами» является достижение результатов обучения, предусмотренных установленным в ОПОП индикаторами достижения компетенций. В процессе освоения дисциплины студент должен

Знать:

основы и роль проектного менеджмента в организации;

классификацию и особенности ИТ-проектов;

технологии разработки и реализации процессов жизненного цикла ИТ-проектов;

основные стандарты ИТ-сферы и их применение в ИТ-проектах;

подходы к формированию эффективной команды и взаимодействию с руководством.

Уметь:

применять методологию управления проектами;

выбирать методы управления проектами в соответствии с особенностями ИТ-проектов;

идентифицировать ключевые компоненты плана;

оценивать стоимость ИТ-проекта;

управлять рисками ИТ-проекта;

выбирать и использовать соответствующие метрические показатели;

отслеживать ход разработки ИТ-проекта с помощью метрических показателей.

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

1.2 Содержание дисциплины

Материал дисциплины сгруппирован по следующим разделам:

1. Процессы жизненного цикла ИТ-проекта.

1.1. Менеджмент процессов

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

Процесс – это ограниченный ряд взаимосвязанных действий, в ходе осуществления которых

4

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

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

Следует учитывать следующие факторы:

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

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

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

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

1.2. Связь 34 компетенций по областям применения с жизненным циклом (ЖЦ) разработки программного продукта (ПП).

На основе 34 компетенций по областям их применения строится модель ЖЦ разработки ПП в соответствии со стандартом IEEE 1074. Модель идентифицирует все стадии и перечисляет для каждой из них определенные действия по разработке ПО. Именно она является главной моделью ЖЦ разработки продукта [1].

2. Выбор модели жизненного цикла разработки ПО.

2.1. Модель SEI CMM и жизненные циклы

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

5

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

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

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

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

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

2.2. Модели жизненного цикла разработки ПО.

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

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

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

Модель быстрой разработки приложений ЖЦ разработки ПО (Rapid Application Development – RAD). Характерная черта – короткое время перехода от определения требований до создания полной системы. Метод основан на последовательности итераций эволюционной системы или прототипов, критический анализ обсуждается с заказчиком. Преимуществом является возможность сокращения цикла и количества специалистов. Недостатки связаны с требованиями участия пользователей на всем протяжении цикла и требованиям к высокой квалификации разработчиков.

6

Инкрементная модель ЖЦ разработки ПО

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

Спиральная модель ЖЦ разработки ПО

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

В связи со сложностью исходной спиральной модели, были разработаны адаптированные модели ЖЦ разработки ПО [1, 2, 5, 7].

3. Гибкие технологии: экстремальное программирование и унифицированный процесс разработки

3.1. Процессы и методы гибкой разработки в ИТ-проектах

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

7

систему, а потом приступать к ее созданию [8].

3.2. Особенности гибкого моделирования

Можно выбрать моделирование требований к системе (Use Case или набор бизнес-правил). Модели используются для помощи в исследованиях. Модель данных помогает объяснить структуру базы данных программистам, которые пишут код на Java, работающий с БД. Гибкое моделирование не является законченным процессом разработки ПО, поэтому его надо использовать с другими процессами, которые содержат методы и средства для других видов деятельности таких как ХР, DSDM, UP или SCRAM. Базовые методики гибкого моделирования делятся на 4 категории: работа в группе; итеративное и инкрементное моделирование; простота; подтверждение правильности. Дополнительные методики включают документацию, мотивацию и продуктивность. Относительно использования UML для моделирования следует отметить, что этого языка недостаточно для разработки бизнес-ПО, он сложнее, чем нужно большинству разработчиков и UML - это не методология или процесс. Его следует использовать в качестве основы моделирования для объектно-ориентированной и компонентной разработки, а далее к нему следует добавлять другие методики, соответствующие потребностям проекта. Применение гибкого моделирования в жизненных циклах проектов, выполняемых в рамках ХР, DSDM, UP или SCRAM требует учета особенностей этих методов и представляет интересную исследовательскую задачу [8,6,3].

4. Оценка длительности и стоимости разработки ИТ-проекта

4.1. Модели оценки стоимости COCOMO и COCOMO II

Оценка стоимости и разработки ИТ-проекта выполняется на ранних стадиях планирования, непосредственно после оценки размера программ для программного проекта или после определения функционала модернизируемой информационной системы. Оценка производится на основе ЖЦ проекта. Для описания действий по разработке продукта используется модель зрелости возможностей SEI CMM. При этом модель КРА второго уровня зрелости составляет основу процессов зрелости, которые имеют место на последующих уровнях. Планирование проектов является необходимым при поддержке программного инжиниринга, измерений и действий по непрерывному улучшению на всех уровнях. При оценивании затрат используется конструктивная модель затрат COCOMO. Простое вычисление затрат основываетс на хронологических данных: размер*хронологическая производитеьность=трудозатраты. Независимо от применяемой единицы измерения, использование хронологических данных обеспечивает лучший метод достижения требуемой точности. Базовая модель COCOMO позволяет оценить производительность и среднюю численность персонала. Промежуточная модель COCOMO использует значения размера и режимы подобно базовой модели, но дополнительно применяются 15 переменных, называемых драйверами затрат, помогающих объяснить и модифицировать уравнения трудозатрат. Концепция, связанная с фактором корректировки трудозатрат, заключается в том, что он создает эффект увеличения или уменьшения трудозатрат, а, следовательно, и затрат в зависимости от набора факторов среды. Модель COCOMO II является улучшенной версией исходной модели, облегчающей оценку для объектно-ориентированного ПО, программ, созданных с применением спиральной или эволюционной моделей, а также приложений. Модель поддерживает вероятностные диапазоны оценок, аккомодирующие факторы, а также учитывается изменчивость

8

требований для выполняемых оценок. Фактически COCOMO II включает три различные модели: композиционную прикладную модель, модель ранней разработки проекта, пост-архитектурную модель [2,4].

4.2. Математическая модель SLIM

Математическая модель SLIM использует линейное программирование, статистическое мооделирование, оценку программ, а также техники обзора, применяемые при оценке затрат на разработку ПО. Она позволяет выбирать «разработку проекта по затратам», а также при оценивании затрат реализовывать такие функции, как калибровка (точная настройка с целью представления локальной среды программной разработки), пострение (информационная модель программной системы, объединяющая характеристики ПО, атрибуты персонала, атрибуты компьютера и т.д.), измерение ПО (автоматизированная версия техники оценки затрат с помощью LOC). Модель ориентирована на работу с большими проектами, чувствительна к оценке размера, является сложным инструментом [1].

5. Отслеживание и контроль в процессе выполнения ИТ-проекта

5.1. Необходимость контроля и управления

Для обеспечения эффективной работы менеджера ИТ-проекта необходимо создание системы контроля и управления проектом. Важной частью системы является цепь обратной связи, проложенная от выхода до входа. Это обычно означает сбор данных, проверку их достоверности, анализ, подведение итогов и своевременный отчет. После анализа входных данных, имеющих отношение к параметрам проекта, следует определить индикаторы выходов, которые действительно прогнозируют то, что может произойти, прежде чем будут собраны все данные. Информационная система управления проектами должна обеспечивать своевременную обратную связь, которая включает, как минимум, элементы диаграммы тройных ограничений: область действия, график, затраты. Эти ограничения обусловливают качество проекта. При осуществлении контроля над менеджментом изменений целесообразно подготовить матрицу принятия решений, ориантированную на различные ситуации. Базовая линия стоимости демонстрирует расход ресурсов на протяжении ЖЦ проекта. Регулирование затрат проекта подразумевает управление активами и человеческими ресурсами, а также отслеживание денежных потоков. Любой ИТпроект должен иметь несколько качественных метрических показателей, определенных как ключевые индикаторы качества производимого командой продукта [1,2].

5.2. Инструменты для управления ИТ-проектом

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

9

уровнем издержек) и метод буферного менеджмента графика критической цепи Голдратта.

6. Определение рисков, связанных с выполнением ИТ-проекта

6.1. Управление рисками

Управление рисками включает ясное понимание внутренних и внешних причин, влияющих на проект, которые могут привести к его срыву [1].

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

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

План разработки программного проекта, как любого ИТ-проекта, представляет собой подготовленный прогноз относительно запланированных событий. На протяжении ЖЦ может происходить много событий, не внесенных в план, которые и составляют вариацию. Профессиональный менеджер в состоянии их минимизировать.

6.2. Модель управления рисками

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

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

Основными ключевыми рисками и угрозами, проявляющиеся ри разработке ПО являются

10