Реферат на тему Методы управления проектами при разработке программных систем

Содержание:

Введение 3
Раздел 1 «Обзор литературы» 4
1. История 4
2. Подходы 5
2.1. Непрерывная интеграция 5
2.2. Прототипирование 5
2.3. Поэтапное развитие 6
2.4. Быстрая разработка приложений 6
Раздел 2 «Описание применяемых методов» 9
2.1. Методологии 9
2.1.1. Гибкая разработка 9
2.1.2. Модель водопада 9
2.1.3. Спиральная разработка 11
2.1.4. Оффшорная разработка 12
2.1.5. Другое 12
Раздел 3 «Анализ российского и зарубежного опыта» 14
3.1. Метамодели процесса 14
3.2. На практике 15
Заключение 16
Литература 17

Введение:

Планирование — это ключ к успеху.
Выбранная вами методология управления проектом будет определять, как будет работать остальная часть проекта. Это включает в себя подготовку, планирование, мониторинг и контроль действий, необходимых для выполнения задач.
Когда дело доходит до управления проектами, существует множество вариантов, и каждый из них имеет свой собственный набор правил, принципов, процессов, плюсов и минусов и многое другое.
Однако важно помнить, что не существует «идеальной» или универсальной методологии. Каждая методология управления проектами имеет свои собственные требования и практики, которые делают ее идеальной для конкретного случая.
Специально для разработки программного обеспечения много говорят о том, как руководить разработкой. Каждый девелоперский проект и клиент разные. Различия варьируются по срокам, срокам, бюджету и многому другому.
Вот почему необходимо подумать о конкретных требованиях и целях проекта, прежде чем углубляться в него. В свою очередь, это повлияет на ход сеансов кодирования и разработку задач на проект.
Смысл выбора правильной методологии управления проектами заключается в максимизации эффективности и сокращении использования ресурсов и времени в каждом проекте. Другими словами, необходимо быть эффективными в своей оперативной деятельности.
Лучший способ сделать это — перенести акцент на цели и требования проекта заранее.
Чтобы успешно управлять проектом, нужно выбрать правильную методологию разработки программного обеспечения, которая будет работать для конкретного проекта.
Проекты различаются по объему и требованиям, как и методологии.
В связи со всем вышеперечисленным актуальность данной темы реферата очевидна.
Целью данного проекта является раскрыть вопрос организации и управления проектами по разработке программного обеспечения.
Основные задачи:
1. Краткое описание истории развития.
2. Дать описание основных подходов.
3. Проанализировать основные методологии

Заключение:

В целом, существует множество методологий управления проектами, когда речь идет о разработке программного обеспечения, каждая из которых имеет свои уникальные и нишевые применения.
Выбор правильной методологии управления проектами имеет решающее значение для способности вашей команды успешно выполнять проекты в срок и в рамках бюджета.
Между тем, использование неправильной стратегии разработки программного обеспечения может привести вас к дальнейшей дилемме.
Чтобы избежать этого, вам нужно сделать шаг назад и сначала определить:
• Требования проекта и клиента.
• Сроки выполнения задач.
• Размер команды.
• Процедуры общения и гибкости.
Затем вы можете посмотреть, как часто вы ожидаете изменений в процессе разработки проекта. Например, если вы собираетесь работать над проектом по разработке веб-приложений, где изменения будут частыми, гибкие и экономичные методы могут быть идеальными.
Между тем, для проектов, в которых вы прогнозируете стабильность и предсказуемость, модель Водопад может работать лучше.
Проекты по разработке программного обеспечения в свои первые годы делают идеальных кандидатов на Scrum. Если проект новый, практически не требуется никаких работ по техническому обслуживанию, и команда может сосредоточиться на предоставлении новой рабочей функции для каждого спринта. В этом случае команда стремится к нескольким функциям каждого спринта, которые они могут предоставить без каких-либо перерывов.
Наконец, для проектов с максимальной гибкостью и меньшим количеством межфункциональных команд — Kanban работает лучше всего, если другие методологии имеют свои ограничения.
Независимо от выбранной методологии управления проектом, важно быть гибким и готовым к адаптации на ходу.
Хотя не существует идеального способа управления проектом, предварительно определив требования и оценив основные ключевые компоненты проекта, можно выбрать эффективную методологию, основанную на потребностях проекта.

Фрагмент текста работы:

Структура методологии разработки программного обеспечения (также известная как SDM) появилась только в 1960-х годах. Согласно Elliott (2004), жизненный цикл разработки систем (SDLC) можно считать самой старой формализованной методологической основой для построения информационных систем. Основная идея SDLC заключалась в том, чтобы «проводить разработку информационных систем очень осознанно, структурированно и методично, требуя, чтобы каждый этап жизненного цикла — от зарождения идеи до поставки окончательной системы — — был бы осуществляется жестко и последовательно » [2] в контексте применяемой основы. Основной целью этой методологической основы в 1960-х годах было «развитие крупномасштабных функциональных бизнес-систем».в эпоху крупных бизнес-конгломератов. Информационные системы деятельности вращалась вокруг тяжелой обработки данных и номер хруст процедуры». [2]
Методологии, процессы и структуры варьируются от конкретных обязательных шагов, которые могут использоваться непосредственно организацией в повседневной работе, до гибких структур, которые организация использует для создания настраиваемого набора шагов, адаптированных к потребностям конкретного проекта или группа. В некоторых случаях организация «спонсора» или «технического обслуживания» распространяет официальный набор документов, описывающих процесс. Конкретные примеры включают в себя:
1970-е годы
Структурированное программирование с 1969 года
Cap Gemini SDM, родом из PANDATA, первый перевод на английский язык был опубликован в 1974 году. SDM означает методологию разработки систем.
1980-е годы
Метод анализа и проектирования структурированных систем (SSADM) с 1980 года
Анализ требований к информации / методология мягких систем
1990-е годы
Объектно-ориентированное программирование (ООП) было разработано в начале 1960-х годов и стало доминирующим подходом к программированию в середине 1990-х годов.
Быстрая разработка приложений (RAD), с 1991 года
Метод разработки динамических систем (DSDM), с 1994 г.
Скрам, с 1995 года
Командный процесс, с 1998 года
Rational Unified Process (RUP), поддерживаемый IBM с 1998 года
Экстремальное программирование, с 1999 года
2000-е годы
Agile Unified Process (AUP), поддерживаемый Скоттом Эмблером с 2005 года
Дисциплинированная гибкая доставка (DAD) заменяет AUP
2010-е годы
Scaled Agile Framework (SAFe)
Крупномасштабная схватка (LeSS)
DevOps
Примечательно, что с момента появления DSDM в 1994 году все методологии, перечисленные в приведенном выше списке, за исключением RUP, были гибкими методологиями, однако многие организации, особенно правительства, все еще используют пре-гибкие процессы (часто водопад или аналогичные). Процесс программного обеспечения и качество программного обеспечения тесно взаимосвязаны; некоторые неожиданные аспекты и эффекты наблюдались на практике [3]
С начала 2000-х годов масштабирование гибких процессов доставки стало самой большой проблемой для команд, использующих гибкие процессы. [4]
Среди них еще один процесс разработки программного обеспечения был создан с открытым исходным кодом. Принятие этих лучших практик известных и устоявшихся процессов в рамках компании называется внутренним источником.