Управление программными проектами

Схема работы ИТ-компании, занимающейся разработкой программного обеспечения, можно разделить на две части:

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

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

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

Программный проект

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

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

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

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

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

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

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

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

Давайте посмотрим на несколько обязанностей, которые берет на себя руководитель проекта -

Управление людьми

Действовать как руководитель проекта
Связь с заинтересованными сторонами
Управление человеческими ресурсами
Настройка иерархии отчетов и т. Д.

Управление проектом

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

Деятельность по управлению программным обеспечением

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

Project Planning
Scope Management
Project Estimation

Планирование проекта

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

Управление объемом

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

Во время управления содержанием проекта необходимо:

Определите объем
Решаем его проверку и контроль
Разделите проект на несколько более мелких частей для упрощения управления.
Проверить объем
Контролируйте объем, внося изменения в объем

Оценка проекта

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

Оценка проекта может включать следующее:

Software size estimation
Размер программного обеспечения можно оценить либо в единицах KLOC (килограммовая строка кода), либо путем подсчета количества функциональных точек в программном обеспечении. Строки кода зависят от практики кодирования, а функциональные точки различаются в зависимости от требований пользователя или программного обеспечения.
Effort estimation
Менеджеры оценивают усилия с точки зрения потребности в персонале и человеко-часах, необходимых для создания программного обеспечения. Для оценки усилий необходимо знать размер программного обеспечения. Это может быть получено на основе опыта менеджеров, исторических данных организации или размера программного обеспечения, которые можно преобразовать в усилия с помощью некоторых стандартных формул.
Time estimation
После оценки размера и усилий можно оценить время, необходимое для создания программного обеспечения. Требуемые усилия разделены на подкатегории в соответствии со спецификациями требований и взаимозависимостью различных компонентов программного обеспечения. Программные задачи делятся на более мелкие задачи, действия или события по структуре рабочего прорыва (WBS). Задачи расписаны на ежедневной основе или в календарных месяцах.

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

Размер программного обеспечения
Качество программного обеспечения
Hardware
Дополнительное программное обеспечение или инструменты, лицензии и т. Д.
Квалифицированный персонал со специальными навыками
Вовлеченные путешествия
Communication
Обучение и поддержка

Методы оценки проекта

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

Менеджер проекта может оценить перечисленные факторы, используя два широко известных метода:

Техника разложения

Этот метод предполагает, что программное обеспечение является продуктом разного состава.

Есть две основные модели -

Line of Code Оценка выполняется по количеству строк кодов в программном продукте.
Function Points Оценка выполняется по количеству функциональных точек в программном продукте.

Техника эмпирической оценки

В этом методе для оценки используются формулы, полученные эмпирическим путем. Эти формулы основаны на LOC или FP.

Putnam Model
Эта модель сделана Лоуренсом Х. Патнэмом и основана на частотном распределении Нордена (кривая Рэлея). Модель Патнэма отображает время и усилия, требуемые с размером программного обеспечения.
COCOMO
COCOMO - это сокращение от COnstructive COst MOdel, разработанное Барри У. Боем. Он делит программный продукт на три категории программного обеспечения: обычное, автономное и встроенное.

Планирование проекта

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

Для планирования проекта необходимо:

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

Управление ресурсами

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

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

Управление ресурсами включает в себя -

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

Управление рисками проекта

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

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

Процесс управления рисками

В процесс управления рисками вовлечены следующие виды деятельности:

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

Выполнение проекта и мониторинг

На этом этапе задачи, описанные в планах проекта, выполняются в соответствии с их графиками.

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

Эти меры включают:

Activity Monitoring - Все действия, запланированные в рамках некоторой задачи, можно отслеживать на ежедневной основе. Когда все действия в задаче завершены, она считается завершенной.
Status Reports - Отчеты содержат статус действий и задач, выполненных в течение заданного периода времени, обычно за неделю. Статус может быть отмечен как завершенный, ожидающий или незавершенный и т. Д.
Milestones Checklist - Каждый проект разделен на несколько этапов, в которых выполняются основные задачи (этапы) на основе этапов SDLC. Этот контрольный список этапов составляется раз в несколько недель и сообщает о состоянии этапов.

Управление коммуникациями проекта

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

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

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

После закрытия команда переходит к следующему этапу или проекту.

Управление конфигурацией

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

IEEE определяет его как «процесс идентификации и определения элементов в системе, управления изменением этих элементов на протяжении их жизненного цикла, регистрации и предоставления отчетов о состоянии элементов и запросов на изменение, а также проверки полноты и правильности элементов».

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

Исходный уровень

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

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

Изменить управление

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

Изменение конфигурации продукта происходит через следующие шаги -

Identification- Запрос на изменение поступает из внутреннего или внешнего источника. Когда запрос на изменение идентифицируется формально, он должным образом документируется.
Validation - Проверяется действительность запроса на изменение и подтверждается порядок его обработки.
Analysis- Влияние запроса на изменение анализируется с точки зрения графика, стоимости и требуемых усилий. Анализируется общее влияние предполагаемого изменения на систему.
Control- Если предполагаемое изменение либо затрагивает слишком много субъектов в системе, либо оно неизбежно, необходимо получить одобрение высокопоставленных властей до того, как изменение будет включено в систему. Решается, стоит ли вносить изменения. Если это не так, запрос на изменение формально отклоняется.
Execution - Если предыдущая фаза определяет выполнение запроса на изменение, на этой фазе предпринимаются соответствующие действия для выполнения изменения, при необходимости выполняется тщательная проверка.
Close request- Изменение проверяется на предмет правильности внедрения и слияния с остальной системой. Это недавно внесенное изменение в программное обеспечение должным образом задокументировано, и формально запрос закрыт.

Инструменты управления проектами

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

Доступны инструменты, помогающие эффективно управлять проектами. Некоторые описаны -

Диаграмма Ганта

Диаграммы Ганта были разработаны Генри Ганттом (1917). Он представляет собой график проекта по временным периодам. Это горизонтальная столбчатая диаграмма с полосами, представляющими действия и время, запланированное для мероприятий проекта.

Диаграмма PERT

Диаграмма PERT (Program Evaluation & Review Technique) - это инструмент, который отображает проект в виде сетевой диаграммы. Он способен графически отображать основные события проекта как параллельно, так и последовательно. События, происходящие одно за другим, показывают зависимость более позднего события от предыдущего.

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

Гистограмма ресурсов

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

Анализ критического пути

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

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