Задание 1. С помощью поиска в сети Интернет найдите информацию о современных методологиях управления ИТ-проектами. Представьте основания для их классификации. Для каждого основания приведите примеры методологий.
В отрасли разработки ПО к методологиям относятся: Waterfall; Agile и его разновидности: SCRUM, Lean, Kanban, XP...; MSF, RUP и другие

1. 
   Водопадная (каскадная Waterfall) модель.
   

Водопадная – наиболее старая из существующих. Представлена впервые была в 1970 г. Уинстоном У. Ройсом. Изобретена как ответ на активное развитие области ПО. Является наиболее простой и распространенной. Активно используется в сфере ИТ, а также во многих отраслях (на производстве или строительстве).

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

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

Сильные и слабые стороны.

Главное преимущество – универсальность плана. Почти любой план из реализованных ранее проектов может быть с небольшими корректировками применен к новой задаче.

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

Недостаток - «узкость». Требуется. чтобы после утверждения этапы оставались без изменений. В случае расширения масштабов проекта план не способен адаптироваться.

Применение.

Водопадная модель делает реализацию схожих проектов более простой. Подходит для промышленности, строительства, производства; применима к ИТ-проектам с четкими сроками и малым количеством ошибок.

2. 
   Agile.
   

Agile – это способ обхода недостатков водопадной модели. Концепции используются уже давно, но полноценно методика представлена в 2001 г. «Agile Manifesto». Разрабатывалась как альтернатива тяжелым, опирающимся на большой объем документации, моделям.

---

Основной фокус – на требующих скорости и гибкости проектах. Гибкость основана на краткосрочных рывках по достижению конкретной цели. а также на высокой стеепени сотрудничества.

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

Сильные и слабые стороны.

Обеспечивает высокую гибкость. Но реализация сильно зависит от нужд проекта.

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

Недостатки: отсутствие зафиксированного плана, сложности финансового контроля, перебои в планировании.

Применение.

Используется в маркетинге, строительстве, разработке и производстве, автомобильной промышленности. Внимательно относится к росту и развитию рынка.

3. 
   Scrum.
   

Основана на двухнедельных – тридцатидневных спринтах. Акцент – на команде. Во время спринта участники в течение 15 минут общаются для пересмотра результатов.

Цель подхода – не допустить переутомления и снижения креативности.

Сильные и слабые стороны.

Управление таким проектом и коммуникации в нем облегчены. Подход базируется на совершенствовании и постоянной оптимизации.

Применение.

Scrum подходит небольшим командам, работающим в условиях меняющегося окружения. Полезен в юриспруденции, дизайне продукта. Отрасли, ориентирующиеся на стабильность и повторение, метод использовать не смогут.

4. 
   Lean
   

На производстве Toyota в 1950-х гг. был использован принцип экономного производства. Цель: максимально увеличить ценность путем устранения и улучшения сторонних процессов и операций.

Подходит как для управления проектами, так и для оптимизации бизнес процессов.

5. 
   Kanban
   

Большой акцент делается на визуальную часть процесса разработки. Путём визуализации сигналами выявляются узкие места, мешающие повышению выработки:

Доска, отображающая этапы управления и разработки.

Карты каждого объекта и задания, отражающие сотрудничество, и предоставляющие максимальные данные (статусы, сроки).

---

Дорожки – способ классификации поставленных задач. Имеют горизонтальный вид и потоки.

Сильные и слабые стороны.

Метод помогает повышению производительности и дает руководителю возможность расставлять приоритеты и контролировать нагрузку.

Простая для понимания, Канбан позволяет командам быстрее подстраиваться под изменения.

Недостатком являются сложности в обслуживании доски и инструментов. Плохая обратная связь может усложнить рабочий процесс.

Применение.

Подходит для реализации проектов с известными этапами работы, мониторинга срочных задач. Будет полезна организациям, зависимым от выполнения разноплановых заданий.

6. 
   RUP
   

Один из самых известных процессов, использующих итеративную модель разработки – Rational Unified Process(RUP).

Rational Unified Process предлагает итеративную модель разработки, включающую 4 фазы: начало, исследование, построение и внедрение.

Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования.

Прохождение через фазы - цикл разработки, каждый цикл завершается генерацией версии системы.

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

Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML.

Термин RUP означает как методологию разработки, так и продукт компании IBM (ранее – Rational) для управления процессами разработки.

Методология RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать специализированный процесс, ориентированный на ее потребности.

Для полноценного внедрения RUP организация должна затратить значительные средства на обучение сотрудников.

При этом попытка обойтись своими силами скорее всего будет обречена на неудачу – необходимо искать специалиста по процессам (process engineer) с соответствующим опытом или привлекать консультантов.

7. 
   MSF
   

Посредством пакета руководств MSF (Microsoft Solutions Framework) гигант IT индустрии решил поделиться опытом и накопленной информацией в области проектирования, разработки, внедрения и сопровождения IT –проектов.

База знаний MSF состоит из оригинальных моделей, методов и взглядов на такие области знаний как управление проектами, персоналом, планирование, анализ рисков и другие смежные дисциплины.

---

Классификация методологий.

Традиционное управление проектами – это установленная методология, в которой проекты выполняются в последовательном цикле. Он следует фиксированной последовательности: инициация, планирование, исполнение, мониторинг и закрытие. Традиционный подход к управлению проектами уделяет особое внимание линейным процессам, документации, предварительному планированию и расстановке приоритетов. Для каждого шага существуют инструменты и методики, определенные стандартной методологией PMBOK, которой следуют руководители проектов. Такие методологии называются жесткими. К ним относятся Waterfall, V-model, RUP (Rational Unified Process), MSF (Microsoft Solutions Framework).

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

Существует множество гибких методологий для управления проектной деятельностью. Например, Scrum - это гибкая структура для разработки, поставки и поддержки сложных продуктов с акцентом на разработку ПО, однако использовалась и в других областях, включая исследования, продажи и маркетинг. Kanban - это визуальная система управления рабочим процессом, позволяющая выявить потенциальные узкие места в работе и устранить их, достигая максимальной экономической эффективности. Lean – это подход к разработке ПО, который поддерживает концепцию постоянного улучшения.
Задание 2. Из полученного списка тяжеловесных методологий управления ИТ-проектами выберите один. Проведите исследование методологии. Результат представьте в таблице.

Характеристика	Описание
Полное название методологии	Каскадная модель (англ. waterfall model, иногда переводят как модель «Водопад»)
Авторы	Американский ученый-информатик Уинстон Уокер Ройс придумал и описал ее еще в 1970 году, а в 1976 году ученые Томас Белл и Томас Тэйер дали ей название.
История возникновения	В 1970 году американский компьютерщик Винстон Ройс (Winston W. Royce), директор центра программных разработок компании Lockheed, опубликовал статью в научном журнале “Proceedings of IEEE”, изложив в ней принципы новой модели управления проектами, получившей название «Каскадная модель» (в оригинале Waterfall Model, поэтому прижилось и другое название – «Водопад».) Согласно Ройсу, процесс разработки прикладных программ может рассматриваться как поток последовательных работ, которые проходят через несколько стадий в своем развитии: анализ требований, проектирование, реализация, тестирование, интеграция и поддержка.
Страна появления	США
Основные принципы, подходы	Принципы: 1. жёсткая последовательность этапов разработки 2. переход к новому этапу — только после успешного завершения предыдущего 3. фиксированная стоимость продукта 4. заказчик не привлекается к непосредственному процессу разработки 5. изменения могут быть внесены только после завершения всего процесса разработки. Традиционный подход к управлению проектами уделяет особое внимание линейным процессам, документации, предварительному планированию и расстановке приоритетов. Для каждого шага существуют инструменты и методики, определенные стандартной методологией PMBOK, которой следуют руководители проектов.
Имеются ли программные средства реализации методологии, какие?	TFS - это продукт Microsoft, который обеспечивает управление исходным кодом (с Team Foundation Version Control или Git), отчетность, управление требованиями, управление проектами (для agile и waterfall разработки программного обеспечения), автоматизированные сборки, управление тестированием и управление релизами/
Используется ли в настоящее время	В настоящее время каскадную модель применяют в авиастроении, военной или космической отраслях, медицине и финансовом секторе.
Примеры успешных проектов, реализованных с помощью данной методологии	Cisco, AT Consulting, Parallels, Toyota (до 2010)

---

Задание 3. Из полученного списка легковесных (agile) методологий управления ИТ-проектами выберите один. Проведите исследование методологии. Результат представьте в таблице.

Характеристика	Описание
Полное название методологии	Crystal Clear
Авторы	Алистер Кокбёрн. Дальнейший вклад в разработку CC сделал системный администратор Марсель Вагерманн, написавший эссе об использовании принципов разработки ПО с помощью Crystal Clear, Agile и Scrum.
История возникновения	В 1991 году Алистер Кокбёрн, один из соавторов манифеста гибкого программирования, задался целью создать эффективную методологию разработки программного обеспечения. Для этого он опросил множество проектных команд и изучил их кейсы разработки. В 1994 году он воплотил эти идеи в жизнь как ведущий консультант проекта с фиксированной стоимостью в 15 млн. долларов и штатом из 45 человек под названием «Orange». Практика показала, что выработанные Алистером принципы послужили основой успеха проекта. Об этом опыте он написал книгу «Surviving Object Oriented Projects» (1997 г.), а через год разработал семейство методологий и назвал их «Crystal».
Страна появления	-
Основные принципы, подходы	В 2004 Кокбёрн определил 3 основные метода концепции: быстрая доставка полезного кода, переход от больших и редких развёртываний кода к меньшим и более частым релизам. усовершенствование через рефлексию — получение сведений о том, что работало хорошо и плохо в предыдущей версии программы для улучшения следующей версии ПО. «осмотическая» коммуникация — Алистер объяснил восприятие и обмен информацией между разработчиками приложения в одной комнате как фоновый шум, напоминающий явления осмоса. Большинство проектов по Crystal Clear состоит из 6 циклов, которые определяют список обязанностей и задач проектной команды: Проектный цикл — хоть проект сам по себе — единица продукта, за ним обычно следует другой проект, повторяющий цикл. Проектный цикл состоит из трёх частей: подготовка (сбор команды, исследование на 360°, определение методологии), серия из двух и более циклов доставки и «ритуала завершения». Длится от нескольких дней до недель. Цикл доставки — состоит из повторной калибровки плана выпуска ПО, серий из одной или нескольких итераций, в результате которых создаётся протестированный интегрированный код, доставки реальным пользователям и «ритуала завершения». Длительность — от 1 недели до 3 месяцев. Итерация — состоит из трёх больших частей: итерационное планирование, дневная и интеграционная деятельность цикла и «ритуал завершения» проекта. Рабочая неделя/день — выбор дня или недели в виде единицы времени цикла зависит от формата проекта и команды. Например, в таком формате проводятся еженедельные встречи отделов, отчётные встречи тимлидеров, «brown-bag» семинары (когда каждый приносит собственный ланч и за перекусом решаются вопросы по проекту). Период интеграции — разработка, интеграция и тестирование системы. В некоторых командах процесс сборки-тестирования проходит не прекращаясь, за что отвечает отдельная машина, другие идут по пути интеграции раз в день или три раза в неделю. Чем короче цикл интеграции, тем лучше. Длительность от 30 минут до 3 дней (зависимо от опыта команды). Разработка — написание и проверка части кода. Это по сути основа работы программиста в «гибкой разработке». Член команды берёт небольшую задачу, программирует решение (в идеале с тестированием) и проверяет её в конфигурации с целой системой. Занимает от 15 минут до нескольких дней.
Имеются ли программные средства реализации методологии, какие?	Метод Crystal – это гибкая структура, которая считается облегченной или гибкой методологией, которая фокусируется на отдельных лицах и взаимодействиях. Методы имеют цветовую кодировку, чтобы обозначить риск для жизни человека. Это в основном для краткосрочных проектов команды разработчиков, работающих в одном рабочем пространстве. Среди нескольких моделей Agile Software Development Life Cycle (SDLC) кристалл считается одной из моделей Agile SDLC. Crystal - это не просто методология, это целое семейство методологий, разработанное Алистером Коберном. Коберн - весьма незаурядный человек, который отличается оригинальными взглядами на создание ПО. Коберн рассматривает процесс создания ПО как конечную целенаправленную игру и утверждает, что у этой игры есть всего две цели: главная и вспомогательная. Главная цель заключается в том, чтобы успешно закончить проект, то есть создать работающий продукт. Второстепенная цель - подготовиться к следующей игре. Для достижения этой цели может понадобиться документация, качественное написание кода, то есть все, что облегчает дальнейшее развитие и поддержку продукта. Если в процессе разработки достигнуты обе цели, то проект считается успешным. Помимо конечного продукта, всегда создаются вспомогательные промежуточные продукты: модели, схемы, описания и т.п. Логично, что их должно быть ровно столько, сколько необходимо для достижения конечной цели. Проблема в том, что очень сложно заранее предсказать, какие промежуточные продукты нужны, а какие - нет.
Используется ли в настоящее время	Да
Примеры успешных проектов, реализованных с помощью данной методологии	Ну, конечно, семейство методологий Crystal построено на итеративной разработке. Продолжительность итерации может изменяться в пределах от 1 до 4 месяцев. Чем меньше итерация, тем лучше. Важной особенностью Crystal является непрерывная настройка методологии. Это позволяет постепенно адаптировать ее для конкретной команды и конкретного проекта. Пожалуй, ни в одной другой методологии настройке не уделяется такого внимания. После каждой итерации команда собирается вместе и обсуждает, какие практики полезны и надо продолжать их использовать в дальнейшем, а какие - исключить вовсе. Обсуждается необходимость промежуточных продуктов, имеющиеся недостатки и т.п. В результате принимается решение о том, какие практики помогут исправить недостатки, а затем, с согласия разработчиков, начинается их внедрение.

---

Смотрите также файлы

• Темы рефератов (до 20 стр.)и презентаций (до 30 слайдов) по дисциплине Стандартизация и управление качеством.docx

• Жин. Ну, конечно же, салат оливье.docx

• Контрольноизмерительное задание Методы оценки физического развития.docx

• Приложение Вопросы к мультфильму Азбука финансовой грамотности со Смешариками, серия Оракул.docx

• Задание Read the texts translate them and answer the questions about your favorite economist.docx