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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Планирование проекта
• Управление областью
• Оценка проекта

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

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

Управление областью

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

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

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

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

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

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

• Оценка размера программного обеспечения

  Размер программного обеспечения может быть оценен либо в единицах KLOC (Kilo Line of Code), либо путем расчета количества функциональных точек в программном обеспечении. Строки кода зависят от практики кодирования, а функциональные точки различаются в зависимости от требований пользователя или программного обеспечения.

• Оценка усилий

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

• Оценка времени

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

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

• Оценка затрат

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

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

Размер программного обеспечения может быть оценен либо в единицах KLOC (Kilo Line of Code), либо путем расчета количества функциональных точек в программном обеспечении. Строки кода зависят от практики кодирования, а функциональные точки различаются в зависимости от требований пользователя или программного обеспечения.

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

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

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

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

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

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

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

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

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

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

• Оценка строки кода производится от имени ряда строк кода в программном продукте.
• Оценка функциональных точек выполняется от имени количества функциональных точек в программном продукте.

Методика эмпирической оценки

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

• Модель Putnam

  Эта модель сделана Лоуренсом Х. Путнэмом, который основан на распределении частот Нордена (кривая Рэлея). Модель Putnam отображает время и усилия, необходимые с размером программного обеспечения.

• COCOMO

  COCOMO расшифровывается как COnstructive COst MOdel, разработанная Barry W. Boehm. Он делит программный продукт на три категории программного обеспечения: органическое, полуотдельное и встроенное.

Эта модель сделана Лоуренсом Х. Путнэмом, который основан на распределении частот Нордена (кривая Рэлея). Модель Putnam отображает время и усилия, необходимые с размером программного обеспечения.

COCOMO расшифровывается как COnstructive COst MOdel, разработанная Barry W. Boehm. Он делит программный продукт на три категории программного обеспечения: органическое, полуотдельное и встроенное.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эти меры включают в себя —

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

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

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

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

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

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

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

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

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

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

базисный

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

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

Смени управление

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

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

• Идентификация — запрос на изменение поступает из внутреннего или внешнего источника. Когда запрос на изменение идентифицирован формально, он надлежащим образом документируется.

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

• Анализ — Влияние запроса на изменение анализируется с точки зрения графика, стоимости и необходимых усилий. Общее влияние предполагаемого изменения на систему анализируется.

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

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

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

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

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

Анализ — Влияние запроса на изменение анализируется с точки зрения графика, стоимости и необходимых усилий. Общее влияние предполагаемого изменения на систему анализируется.

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

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

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

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

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

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

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

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

Диаграмма PERT

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

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

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

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

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

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

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