Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Жизненный цикл программного обеспечения 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) .

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

Философия [ править ]

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

Ссылки [ править ]

  1. ^ a b Стеллман, Эндрю; Грин, Дженнифер (2005). Управление прикладными программными проектами . O'Reilly Media. ISBN 978-0-596-00948-9. Архивировано из оригинала на 2015-02-09.
  2. ^ "Почему программное обеспечение не работает" , в IEEE Spectrum
  3. ^ a b Производство программного обеспечения с открытым исходным кодом: как запустить успешный проект свободного программного обеспечения (электронная книга, которую можно бесплатно загрузить), Карл Фогель.
  4. ^ a b Роберт Фрезе и Вики Заутер , «Повышение шансов на успех программного проекта», IEEE Engineering Management Review , Vol. Четвертый квартал, 42, No. 4, декабрь 2014 г.
  5. ^ Филип Гринспан , Основатели Джессики Ливингстон в работе (2007), ISBN 1-59059-714-1 
  6. ^ Джон С. Рейнольдс, Некоторые мысли об обучении программированию и языкам программирования ,Уведомления SIGPLAN , Том 43, Выпуск 11, ноябрь 2008 г., стр.108: «Некоторые утверждают, что можно управлять производством программного обеспечения, не имея возможности программировать. возникают из ошибочного представления о том, что производство программного обеспечения - это форма производства. Но производство - это повторное конструирование идентичных объектов, а производство программного обеспечения - это конструирование уникальных объектов, т. е. весь процесс - это форма проектирования. Как таковое, оно ближе к производству газеты [sic] - так что менеджер программного обеспечения, который не может программировать, сродни управляющему редактору, который не может писать ".
Общий
  • 16326: 2019 (E) - Международный стандарт ISO / IEC / IEEE - Системная и программная инженерия - Процессы жизненного цикла - Управление проектами . 2019 DOI : 10,1109 / IEEESTD.2019.8932690 . ISBN 978-1-5044-6299-0.
  • 1058-1998 - Стандарт IEEE для планов управления проектами программного обеспечения . 1998. DOI : 10,1109 / IEEESTD.1998.88822 . ISBN 978-0-7381-1448-4.
  • Джалоте, Панкадж (2002). Управление программными проектами на практике . Эддисон-Уэсли. ISBN 0-201-73721-3.
  • Мурали Chemuturi, Томас М. Кэгли младший и (2010). Управление программными проектами: передовой опыт, инструменты и методы . Издательство J.Ross. ISBN 978-1-60427-034-1.

Внешние ссылки [ править ]

  • Ресурсы по управлению программными проектами от Дэна Галората

Сбой проекта [ править ]

  • Роберт Фрезе (2003-12-16). «УСПЕХ И НЕИСПРАВНОСТЬ ПРОЕКТА: ЧТО ТАКОЕ УСПЕХ, ЧТО ТАКОЕ НЕУДАЧА, И КАК ВЫ МОЖЕТЕ УЛУЧШИТЬ СВОИ ДОСТИЖЕНИЯ УСПЕХА?» . Университет Миссури-Св. Луи . Проверено 13 мая 2015 .
  • Джозеф Гулла (февраль 2012 г.). «Семь причин провала ИТ-проектов» . Журнал IBM Systems . Проверено 13 мая 2015 .