Управление проектами программного обеспечения - это искусство и наука планирования и управления проектами программного обеспечения. Это подраздел управления проектами, в котором проекты программного обеспечения планируются, реализуются, контролируются и контролируются.
Содержание
- 1 История
- 2 Процесс разработки программного обеспечения
- 3 Планирование, выполнение, мониторинг и контроль проекта
- 4 Проблема
- 5 Философия
- 6 Ссылки
- 7 Внешние ссылки
История
В 1970-х и 1980-х годах индустрия программного обеспечения росла очень быстро, поскольку компьютерные компании быстро осознали относительно низкую стоимость производства программного обеспечения по сравнению с производством оборудования. и схемотехника. Для управления новыми усилиями по разработке компании применяли установленные методы управления проектами, но расписания проекта проскальзывали во время тестовых прогонов, особенно когда в серой зоне возникала путаница между пользовательскими спецификациями и поставленным программным обеспечением.. Чтобы избежать этих проблем, методы управления проектами программного обеспечения были сосредоточены на согласовании требований пользователей к поставляемым продуктам в методе, известном теперь как водопадная модель.
По мере развития отрасли анализ ошибок управления проектами программного обеспечения показал что следующие причины являются наиболее частыми:
- Недостаточное участие конечного пользователя
- Плохое общение между клиентами, разработчиками, пользователями и руководителями проектов
- Нереалистичные или невысказанные цели проекта
- Неточные оценки необходимых ресурсов
- Плохо определенные или неполные системные требования и спецификации
- Плохая отчетность о статусе проекта
- Плохо управляемые риски
- Использование незрелой технологии
- Неспособность справиться со сложностью проекта
- Небрежная практика разработки
- Политика заинтересованных сторон (например, отсутствие поддержки со стороны руководства или политика между заказчиком и конечной -пользователи)
- Коммерческое давление
Первые пять пунктов в списке выше показать трудности, связанные с формулированием потребностей клиента таким образом, чтобы соответствующие ресурсы могли обеспечить надлежащие цели проекта. Конкретные инструменты управления программными проектами полезны и часто необходимы, но истинное искусство управления программными проектами - это применение правильного метода, а затем использование инструментов для его поддержки. Без метода инструменты бесполезны. С 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.
Внешние ссылки
Сбой проекта
- Роберт Фрезе (16 декабря 2003 г.). «УСПЕХ И НЕИСПРАВНОСТЬ ПРОЕКТА: ЧТО ТАКОЕ УСПЕХ, ЧТО ТАКОЕ НЕУДАЧА, И КАК ВЫ МОЖЕТЕ УЛУЧШИТЬ СВОИ ДОСТИЖЕНИЯ УСПЕХА?». Университет Миссури-Св. Луи. Проверено 13 мая 2015 г.
- Джозеф Гулла (февраль 2012 г.). «Семь причин провала ИТ-проектов». Журнал IBM Systems. Проверено 13 мая 2015 года.