Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
[3 курс] Вопросы к экзамену Программная инженерия.docx
Скачиваний:
18
Добавлен:
20.08.2020
Размер:
646.37 Кб
Скачать
  1. Сертифицированный специалист по управлению проектами (CAPM - Certified Associate in Project Management ) – это тот, кто демонстрирует понимание основных знаний и терминов в области управления проектами. Данная сертификация требует либо 1500 часов работы в проектной команде или 23 официальных часов формального образования по управлению проектами.

  2. Статья про pmBoK:

    https://blog.alevi.ru/management/upravlenie-proektami-po-pmbok/

    Профессионал в управлении проектами (PMP - Project Management Professional) – это тот, кто соответствует конкретным требованиям к опыту и образованию, кто принял кодекс профессионального поведения и прошел экзамен, разработанный для объективной оценки и измерения знаний в управлении проектами. В дополнение, профессионал должен соответствовать постоянно обновляющимся требованиям сертификации, иначе он потеряет право считаться сертифицированным профессионалом.

План ответа на вопрос 6.

  1. Причины возникновения авторских подходов к управлению ит-проектами

Усилилось влияние следующих факторов:

  1. Требования заказчиков и увеличение их компетентности.

  2. Собственная сложность конечных продуктов проектов.

  3. Взаимосвязь и взаимовлияние с внешним окружением проектов (эконо­мическое, политическое, экологическое, социальное, культурное окружение).

  4. Степень неопределенности и риска.

  5. Организационные перестройки.

  6. Частота смены технологий.

  7. Ошибки планирования и ценообразования.

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

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

  1. Методология ibm Rational Unified Process

Рациональный унифицированный процесс (Rational Unified Process, RUP) — методология разработки программного обеспечения которая представлена в виде гипертекстовой базы знаний, оформленной как web-сайт и просматриваемой через браузер. В основе методологии лежит итерационный подход к разработке ПО, то есть проект разбивается на более мелкие проекты с прописанными целями, реализуемые последовательно.

RUP хорошо формализован, и наибольшее внимание уделяется начальным стадиям разработки проекта — анализу и моделированию. Таким образом, эта методология направлена на снижение коммерческих рисков (risk mitigating) посредством обнаружения ошибок на ранних стадиях разработки. Технические риски (assesses) оцениваются и «расставляются» согласно приоритетам на ранних стадиях цикла разработки, а затем пересматриваются с течением времени и с развитием проекта в течение последующих итераций. Новые цели появляются в зависимости от приоритетов данных рисков. Релизы версий распределяются таким образом, что наиболее приоритетные риски устраняются первыми. Для успешного процесса разработки необходимы три составляющие: процесс (process), нотация (notation) и набор утилит (tools). Процесс описывает, что мы делаем, в каком порядке и каким образом; нотация является средством общения; набор утилит помогает автоматизировать процесс и управлять им.

6. Причины возникновения авторских подходов к управлению ИТ-проектами. Методология IBM Rational Unified Process 

Рациональный унифицированный процесс (Rational Unified Process, RUP) — методология разработки программного обеспечения которая представлена в виде гипертекстовой базы знаний, оформленной как web-сайт и просматриваемой через браузер. В основе методологии лежит итерационный подход к разработке ПО, то есть проект разбивается на более мелкие проекты с прописанными целями, реализуемые последовательно.

В основе RUP лежат следующие принципы:

  • Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

  • Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)).

  • Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

  • Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

  • Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

  • Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

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