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

редактировать

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

Содержание

  • 1 История
  • 2 Процесс разработки программного обеспечения
  • 3 Планирование, выполнение, мониторинг и контроль проекта
  • 4 Проблема
    • 4.1 Уровни серьезности
  • 5 Философия
  • 6 Ссылки
  • 7 Внешние ссылки
    • 7.1 Провал проекта

История

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

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

  1. Недостаточное участие конечного пользователя
  2. Плохое общение между клиентами, разработчиками, пользователями и руководителями проектов
  3. Нереалистичные или невысказанные цели проекта
  4. Неточные оценки необходимых ресурсов
  5. Плохо определенные или неполные системные требования и спецификации
  6. Плохая отчетность о статусе проекта
  7. Плохо управляемые риски
  8. Использование незрелой технологии
  9. Неспособность справиться со сложностью проекта
  10. Небрежная практика разработки
  11. Политика заинтересованных сторон (например, отсутствие поддержки со стороны руководства или политика между заказчиком и конечной -пользователи)
  12. Коммерческое давление

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

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

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

  • Межличностное общение и управление и разрешение конфликтов. Активное, частое и честное общение является наиболее важным фактором повышения вероятности успеха проекта и смягчения проблемных проектов. Команда разработчиков должна стремиться к вовлечению конечных пользователей и поощрять их участие в процессе разработки. Отсутствие участия пользователей может привести к неправильному толкованию требований, невосприимчивости к изменяющимся потребностям клиентов и нереалистичным ожиданиям со стороны клиента. Разработчики программного обеспечения, пользователи, менеджеры проектов, клиенты и спонсоры проектов должны общаться регулярно и часто. Информация, полученная в результате этих обсуждений, позволяет команде проекта анализировать сильные и слабые стороны, возможности и угрозы (SWOT) и действовать на основе этой информации, чтобы извлечь выгоду из возможностей и минимизировать угрозы. Даже плохие новости могут быть хорошими, если они сообщаются относительно рано, потому что проблемы можно смягчить, если они не будут обнаружены слишком поздно. Например, случайный разговор с пользователями, членами команды и другими заинтересованными сторонами часто может выявить потенциальные проблемы раньше, чем официальные встречи. Все коммуникации должны быть интеллектуально честными и достоверными, и необходима регулярная, частая, качественная критика работы по развитию, если она предоставляется в спокойной, уважительной, конструктивный, без обвинений, без злости. Частые случайные коммуникации между разработчиками и конечными пользователями, а также между менеджерами проектов и клиентами необходимы для того, чтобы проект оставался актуальным, полезным и эффективным для конечных пользователей и в рамках того, что может быть выполнено. Эффективное межличностное общение, управление и разрешение конфликтов являются ключом к управлению проектами программного обеспечения. Никакая методология или стратегия улучшения процесса не могут преодолеть серьезные проблемы в общении или неправильное управление межличностным конфликтом. Более того, результаты, связанные с такими методологиями и стратегиями улучшения процессов, улучшаются за счет лучшего взаимодействия. Коммуникация должна быть сосредоточена на том, понимает ли команда устав проекта и добивается ли команда прогресса в достижении этой цели. Конечные пользователи, разработчики программного обеспечения и менеджеры проектов должны часто задавать элементарные простые вопросы, которые помогают идентифицировать проблемы, прежде чем они перерастут в катастрофу. Хотя участие конечного пользователя, эффективное общение и командная работа недостаточны, они необходимы для обеспечения хорошего результата, и их отсутствие почти наверняка приведет к плохому результату.
  • Управление рисками является процесс измерения или оценки риска с последующей разработкой стратегии управления риском. Как правило, используемые стратегии включают передачу риска другой стороне, избегание риска, уменьшение негативного воздействия риска и принятие некоторых или всех последствий конкретного риска. Управление рисками в управлении проектами программного обеспечения начинается с бизнес-обоснования для начала проекта, которое включает анализ затрат и выгод, а также список альтернативных вариантов для отказа проекта, называемых план на случай непредвиденных обстоятельств.
    • Подмножество управления рисками - это Управление возможностями, что означает то же самое, за исключением того, что потенциальный результат риска будет иметь положительное, а не отрицательное влияние. Хотя теоретически с этим можно справиться таким же образом, использование термина «возможность», а не несколько отрицательного термина «риск» помогает удерживать команду сосредоточенной на возможных положительных результатах любого заданного реестра рисков в своих проектах, например побочные проекты, непредвиденные доходы и бесплатные дополнительные ресурсы.
  • Управление требованиями - это процесс выявления, выявления, документирования, анализа, отслеживания, определения приоритетов и согласования требований, а затем контроль изменений и обмен информацией с соответствующими заинтересованными сторонами. Новая или измененная компьютерная система Управление требованиями, которое включает анализ требований, является важной частью процесса разработки программного обеспечения ; посредством чего бизнес-аналитики или разработчики программного обеспечения определяют потребности или требования клиента; идентифицировав эти требования, они затем могут разработать решение.
  • Управление изменениями - это процесс выявления, документирования, анализа, определения приоритетов и согласования изменений в области (управление проектом) а затем контролировать изменения и общаться с соответствующими заинтересованными сторонами. Анализ воздействия изменений новой или измененной области, который включает анализ требований на уровне изменений, является важной частью процесса разработки программного обеспечения ; посредством чего бизнес-аналитики или разработчики программного обеспечения идентифицируют изменившиеся потребности или требования клиента; После определения этих требований они могут перепроектировать или модифицировать решение. Теоретически каждое изменение может повлиять на сроки и бюджет программного проекта, и поэтому по определению должно включать анализ рисков и выгод перед утверждением.
  • Управление конфигурацией программного обеспечения - это процесс идентификации, и документирование самой области действия, которая представляет собой разрабатываемый программный продукт, включая все подпродукты и изменения, и обеспечение возможности сообщения о них соответствующим заинтересованным сторонам. Как правило, используемые процессы включают контроль версий, соглашение об именах (программирование) и соглашения об архивировании программного обеспечения.
  • Управление выпуском - это процесс идентификации, документирования, определения приоритетов согласование выпусков программного обеспечения, а затем контроль графика выпуска и обмен информацией с соответствующими заинтересованными сторонами. Большинство программных проектов имеют доступ к трем программным средам, в которых может быть выпущено программное обеспечение; Разработка, тестирование и производство. В очень больших проектах, где распределенным командам необходимо интегрировать свою работу перед выпуском для пользователей, часто будет больше сред для тестирования, называемых модульным тестированием, тестированием системы или интеграционное тестирование, перед выпуском в пользовательское приемочное тестирование (UAT).
    • Подмножество управления выпусками, которое привлекает внимание, - это Управление данными, поскольку очевидно, что пользователи могут тестировать только на основе данных, которые им известны, а «настоящие» данные находятся только в программной среде. называется «производство». Поэтому для проверки своей работы программисты должны также часто создавать «фиктивные данные» или «заглушки данных». Традиционно для этой цели когда-то использовались более старые версии производственной системы, но поскольку компании все больше и больше полагаются на внешних участников для разработки программного обеспечения, данные компании могут не передаваться группам разработчиков. В сложных средах могут быть созданы наборы данных, которые затем переносятся в тестовые среды в соответствии с графиком выпуска тестов, во многом аналогичным общему графику выпуска программного обеспечения.
  • Сопровождение и обновление - это процесс, в котором всегда задействованы требования и потребности клиентов. Они, несомненно, найдут ошибки, могут запросить новые функции, другие функции и дополнительные обновления. Таким образом, все эти запросы должны проверять и удовлетворять требования и удовлетворенность клиентов.

Планирование, выполнение, мониторинг и контроль проекта

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

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

Проблема

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

Например, OpenOffice.org использовался для вызова своей модифицированной версии Bugzilla IssueZilla. По состоянию на сентябрь 2010 года они называют свою систему отслеживанием проблем.

Уровни серьезности

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

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

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

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

Философия

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

Ссылки

Общие
  • 1058-1998 - Стандарт IEEE для планов управления проектами программного обеспечения. 1998. doi : 10.1109 / IEEESTD.1998.88822. ISBN 978-0-7381-1448-4.
  • Джалоте, Панкадж (2002). Управление программными проектами на практике. Эддисон-Уэсли. ISBN 0-201-73721-3.
  • Murali Chemuturi, Thomas M. Cagley Jr. (2010). Управление программными проектами: передовой опыт, инструменты и методы. J.Ross Publishing. ISBN 978-1-60427-034-1.

Внешние ссылки

Сбой проекта

Последняя правка сделана 2021-06-08 08:27:56
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте