Управление программным проектом - Software project management

IEEE жизненный цикл программного обеспечения

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

История

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

По мере развития отрасли анализ сбоев в управлении программными проектами показал, что наиболее распространенными причинами являются следующие:[2][3][4]

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

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

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

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

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

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

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

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

Проблема

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

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

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

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

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

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

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

Философия

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

Рекомендации

  1. ^ а б Стеллман, Эндрю; Грин, Дженнифер (2005). Управление прикладным программным обеспечением. O'Reilly Media. ISBN  978-0-596-00948-9. Архивировано из оригинал на 2015-02-09.
  2. ^ «Почему программное обеспечение не работает», в IEEE Spectrum
  3. ^ а б Производство программного обеспечения с открытым исходным кодом: как запустить успешный проект свободного программного обеспечения (электронная книга, которую можно бесплатно загрузить), Карл Фогель
  4. ^ а б Роберт Фрезе и Вики Заутер, "Повышение шансов на успех программного проекта", Обзор инженерного менеджмента IEEE, Vol. Четвертый квартал, 42, No. 4, декабрь 2014 г.
  5. ^ Филип Гринспан, в книге Джессики Ливингстон Основатели за работой (2007), ISBN  1-59059-714-1
  6. ^ Джон С. Рейнольдс, Некоторые мысли об обучении программированию и языкам программирования, СИГПЛАН Уведомления, том 43, выпуск 11, ноябрь 2008 г., стр.108: «Некоторые утверждают, что можно управлять производством программного обеспечения, не имея возможности программировать. Такое мнение, кажется, возникает из ошибочного представления о том, что производство программного обеспечения является формой производства. Но производство - это повторное создание идентичных объектов, в то время как производство программного обеспечения - это создание уникальных объектов, т. е. весь процесс - это форма проектирования. По сути, он ближе к созданию газеты [sic] - так что менеджер программного обеспечения, который не умеет программировать, сродни управляющему редактору, который не умеет писать ".
Общий

внешняя ссылка

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