Материал: [3 курс] Вопросы к экзамену Программная инженерия

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

Каждая область знаний содержит все, либо некоторые процессы управления проектом. К примеру, правление закупками включает в себя:

1. Планирование закупок

2. Управление запросами на покупку

3. Ходатайство

4. Выбор источника

5. Контроль над исполнением контракта

6. Завершение контракта

Институт управления проектами (PMI) является издателем свода знаний по управлению проектами PMBOK (последняя версия - пятая) и предоставляет два уровня сертификации:

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. Ошибки планирования и ценообразования.

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

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

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

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

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

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

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

1. Методология Microsoft Solutions Framework

— методология, разработанная на основе практического опыта Microsoft. Это скорее, даже целая система управления проектами разработки, состоящая из множества моделей и правил. Она сочетает в себе каскадную и спиральную модели разработки, универсальна, поскольку не включает в себя жёсткие процедуры. MSF ориентирована на вехи, учитывает изменения проектных требований, основана на коротких итеративных циклах всей системы разработки: дизайна, кода, документации. Методология охватывает все стадии разработки продукта, включая внедрение, в результате которого и формируется бизнес-ценность. MSF во многих крупных компаниях как для внешней (заказной) разработки, так и для разработки по техническим заданиям внутренних заказчиков.

2. Методология Microsoft Operations Framework

состоит из набора взаимосвязанных «рекомендованных практик», основополагающих принципов и процедур, которые вместе предоставляют полные руководства по достижению надежности ИТ-решений и услуг. В составе MOF вы найдете инструкции в форме вопросов, помогающие определить, что необходимо вашему ИТ-подразделению сегодня, а также мероприятия, которые позволят ему эффективно и результативно работать в будущем. Цель MOF заключается в предоставлении ИТ-подразделениям руководств, помогающих создавать, эксплуатировать и поддерживать ИТ-услуги, обеспечивая получение ожидаемых коммерческих преимуществ от конкретных инвестиций в ИТ с приемлемым уровнем риска.

3. Microsoft Dynamics Sure Step

Методология Microsoft Dynamics Sure Step (MDSS) представляет собой комплексную методологию внедрения, содержащую в себе рекомендации, стратегии управления проектами, инструменты и шаблоны, которые партнеры корпорации Microsoft могут использовать для внедрения продуктов Microsoft Dynamics для своих клиентов.

Данная методология выделяет 6 основных этапов внедрения: диагностика, анализ, дизайн, разработка, развертывание, эксплуатация. Инструменты и рекомендуемые методологией подходы помогают улучшить качество и повышают вероятность успешного внедрения.

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

Microsoft Solutions Framework — это набор концепций и рекомендуемых моделей, которые позволяют разрабатывать и внедрять распределенные информационные системы масштаба предприятия на основе технологий и инструментальных средств фирмы Microsoft. MSF базируется на практических результатах организации распределенных вычислений и применения клиент-серверных технологий, полученных как в самой фирме Microsoft, так и ее партнерами, и заказчиками. Многие концепции MSF хорошо известны, однако основное достоинство MSF — это систематизация и структуризация информации в форме базы знаний, удобной для ознакомления и использования.

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

Модель, рекомендуемая SDD, предусматривает для выполнения проектов организовать команду специалистов по шести направлениям:

• Управление продуктом;

• Управление программой;

• Разработка;

• Тестирование;

• Обучение пользователей;

• Сопровождение (логистика).

Каждое из этих направлений называется ролью. В зависимости от размеров проекта либо один человек может совмещать несколько ролей, либо каждая роль выполняется группой людей. Т.е. группа д.б. небольшой, не более 6 человек. Назначается руководитель (лидер) группы, который выполняет руководство и согласование по всем работам, члены же группы являются исполнителями.

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

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

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

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

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

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

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

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