Jump to content

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

Управление программными проектами — это процесс планирования и руководства программными проектами. [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) .
    • Подмножеством управления выпусками, которое привлекает внимание, является Управление данными , поскольку очевидно, что пользователи могут тестировать только на основе известных им данных, а «реальные» данные находятся только в программной среде, называемой «производство». Поэтому для проверки своей работы программистам часто приходится создавать «фиктивные данные» или «заглушки данных». Традиционно для этой цели когда-то использовались старые версии производственной системы, но поскольку компании все больше и больше полагаются на внешних участников при разработке программного обеспечения, данные компании могут не передаваться группам разработчиков. В сложных средах могут создаваться наборы данных, которые затем переносятся между тестовыми средами в соответствии с графиком выпуска тестов, во многом похожим на общий график выпуска программного обеспечения.
  • Обслуживание и обновление — это процесс, в котором всегда учитываются требования и потребности клиентов. Они, несомненно, найдут ошибки, могут запросить новые функции, другие функции и дополнительные обновления. Таким образом, все эти запросы необходимо проверять и удовлетворять требованиям и удовлетворению клиентов.

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

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

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

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

Проблема

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

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

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

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

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

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

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

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

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

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

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

Философия

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

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

  1. ^ Перейти обратно: а б Стеллман, Эндрю; Грин, Дженнифер (2005). Управление проектами прикладного программного обеспечения . О'Рейли Медиа. ISBN  978-0-596-00948-9 . Архивировано из оригинала 9 февраля 2015 г.
  2. ^ «Почему программное обеспечение терпит неудачу» в IEEE Spectrum
  3. ^ Перейти обратно: а б «Производство программного обеспечения с открытым исходным кодом: как запустить успешный проект бесплатного программного обеспечения» (электронная книга, которую можно загрузить бесплатно), Карл Фогель
  4. ^ Перейти обратно: а б Роберт Фрезе и Вики Саутер , «Повышение ваших шансов на успех программного проекта», IEEE Engineering Management Review , Vol. 42, № 4, четвертый квартал, декабрь 2014 г.
  5. ^ Филип Гринспан , в книге Джессики Ливингстон «Основатели за работой» (2007), ISBN   1-59059-714-1
  6. ^ Дейн, Бертрам (2009). «Социальная природа отслеживания проблем в разработке программного обеспечения» (PDF) . Архивировано из оригинала (PDF) 8 ноября 2016 г. Проверено 7 октября 2023 г.
  7. ^ Джон К. Рейнольдс, Некоторые мысли об обучении программированию и языкам программирования , Уведомления SIGPLAN , том 43, выпуск 11, ноябрь 2008 г., стр. 108: «Некоторые утверждают, что можно управлять производством программного обеспечения, не умея программировать. Кажется, это убеждение возникают из ошибочного представления, что производство программного обеспечения является формой производства. к выпуску газеты [так в оригинале] — так что менеджер программного обеспечения, который не умеет программировать, сродни главному редактору, который не умеет писать».
Общий
[ редактировать ]

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

[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 903be066b6c3bdaa2a31ce2a7ceef7b7__1722391320
URL1:https://arc.ask3.ru/arc/aa/90/b7/903be066b6c3bdaa2a31ce2a7ceef7b7.html
Заголовок, (Title) документа по адресу, URL1:
Software project management - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)