Методологии управления ИТ-проектами. ЛР 1. Программам бакалавриата Кафедра Информатика

• Название: Программам бакалавриата Кафедра Информатика
• Анкор: Методологии управления ИТ-проектами
• Дата: 28.03.2022
• Размер: 198.58 Kb.
• Имя файла: ЛР 1.docx
• Тип: Программа; #422056

Федеральное Агентство Связи

Ордена Трудового Красного Знамени федеральное государственное

бюджетное образовательное учреждение высшего образования

«Московский технический университет связи и информатики»

Центр заочного обучения по программам бакалавриата

Кафедра «Информатика»

Дисциплина: Программная инженерия

Лабораторная работа №1

«Методологии управления ИТ-проектами»

Выполнил: Алябьев Е.Н.,

студент группы БСТ2055

Москва 2021

Задание 1.

В 1997 году выходит статья «MESSY, EXCITING, AND ANXIETY-RIDDEN: ADAPTIVE SOFTWARE DEVELOPMENT» Джима Хигсмита, в которой он описывает адаптивную методологию разработки программного (Adaptive software development, сокращенно ASD). Ключевой особенностью данной методологии является новый взгляд на отношение к требованиям и проекту, подразумевается возможность их постоянного изменения, к чему она и стремиться адаптироваться. Превалирующий классический жизненный цикл проекта: планирование-проектирование-конструирование здесь модифицирован и представлен последовательностью: обдумывание-взаимодействие-обучение (speculate-collaborate-learn).

В 1999 году выходит книга «Extreme Programming Explained: Embrace Change» [12], описывающая методологию экстремального программирования, авторами которой являются Кент Бек, Уорд Каннингем и Мартин Фаулер. Экстремальное программирование, как и ASD ориентируется на постоянное изменение требований и предлагает 12 методик способствующих эффективному процессу разработки в подобных условиях:

• 
  Игра в планирование (planning game) – быстрое создание приблизительного плана работы и его постоянное обновление;
  
• 
  Небольшие версии (small releases) – частый выпуск небольших версий продукта;
  
• 
  Метафора (metaphor) – краткое описание работы системы;
  
• 
  Простой дизайн (simple design) – применительно к архитектуре;
  
• 
  Тестирование (testing) – стоит отметить что данная методика в дальнейшем выделилась в отдельную методологию разработки именуемую «Test Driving Development» (TDD);
  
• 
  Переработка (refactoring);
  
• 
  Парное программирование (pair programming) – одновременное участие в работе над задачей двух разработчиков;
  
• 
  Коллективное владение кодом (collective ownership);
  
• 
  Непрерывная интеграция (continuous integration) – частое внедрение разработок;
  
• 
  40-часовая неделя (40-hour week);
  
• 
  Заказчик на месте разработки (on-site customer);
  
• 
  Стандарты кодирования (coding standards).
  

В 2001 году в США, штате Юта, подписывается манифест гибкой методологии разработки программного обеспечения «Agile Manifesto», Agile представляет собой семейство методологий разработки в которое вошли такие как: экстремальное программирование, SCRUM, DSDM, ASD, мало известная методология Crystal, FDD, Pragmatic Programming и прочие. Agile определяет 12 принципов, которых стоит придерживаться :

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, обеспечиваемой посредством регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

В том же 2001 году выходит методология разработки от компании IBM, называющаяся Rational Unified Process (RUP), которая описывает как эффективно использовать коммерчески проверенные подходы к разработке программного обеспечения. RUP обеспечивает членов команды руководящими принципами, шаблонами и инструментальными наставлениями, необходимыми для всей команды, чтобы в полной мере воспользоваться следующими практиками:

• 
  Разрабатывайте программное обеспечение итеративно;
  
• 
  Управляйте требованиями;
  
• 
  Используйте компонентную архитектуру;
  
• 
  Визуализируйте модель программы;
  
• 
  Проверяйте качество программы;
  
• 
  Контролируйте изменения программы.
  

Рис. 2. Рабочие процессы RUP

Ядро RUP составляют следующие рабочие процессы, пересечение которых показано на рисунке 2., среди которых 6 процессов инжиниринга и 3 вспомогательных процесса:

• 
  Бизнес моделирование (Business Modeling);
  
• 
  Требования (Requirements);
  
• 
  Анализ и дизайн (Analysis & Design);
  
• 
  Реализация (Implementation);
  
• 
  Тестирование (Test);
  
• 
  Развертывание (Deployment);
  
• 
  Управление проектами (Project Management);
  
• 
  Конфигурация и изменение (Configuration & Change);
  
• 
  Управление (Management);
  
• 
  Среда (Environment).
  

К самым последним новшествам в области методологий разработки программного обеспечения можно отнести вышедшую в 2006 году книгу компании 37signals «Getting Real» , в которой описывается одноименная методология, всецело направленная на минимизацию каких либо бюрократических издержек, вроде составления спецификации или штатного расписания. В данном подходе к разработке рекомендуется начинать разработку с дизайна интерфейса, затем переходить к самому интерфейсу и уже в конце к программированию. Таким образом, подразумевается в кратчайшие сроки выпустить минимальную версию продукта и развивать ее, что в наибольшей степени подходит для веб проектов.

Getting Real предлагается в первую очередь для использования в небольших компаний и командах, где различные организационные обязательства не являются необходимым условием выживания и лишь обременяют коллектив. В целом данная методология соответствует, либо способствует большей части принципов описанных в экстремальном программирование и манифесте гибких методологий. Помимо этого, методология затрагивает такие области знаний, как:

• 
  Управление приоритетами;
  
• 
  Управление коммуникациями;
  
• 
  Управление персоналом;
  
• 
  Управление ценообразованием;
  
• 
  Продвижение;
  
• 
  Поддержка.
  

Заключение.

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

На протяжение развития методологий можно наблюдать изменения в расстановке приоритетов от время-функционал к время-ресурсы. Более того, последние версии методологий подразумевают постоянное изменение функциональных требований. Наибольшая формализация методологий и процессов наблюдалась к концу первой полвины 90-х годов, после чего стали набирать популярность облегченные версии.

Задание 2

Характеристика	Описание
Полное название методологии	Microsoft Solutions Framework (MSF)
Авторы	Компания Microsoft
История возникновения	90-е годы стали временем расцвета новых подходов к разработке. Модель «Водопад», которую использовали больше двух десятилетий, уже в полной мере не отвечала требованиям в IT: была слишком жесткой и формализованной, медленно реагировала на новые потребности пользователей. У Microsoft был обширный опыт в создании программных продуктов и продвижении масштабных IT-проектов. Компания суммировала накопленные знания и навыки, проанализировала опыт конкурентов и в 1993 году выпустила серию руководств, посвященных организации труда разработчиков — «белые книги» MSF.
Страна появления	США
Основные принципы, подходы	Способствуйте открытому общению Модель MSF предусматривает свободный и открытый обмен информацией между всеми членами команды и заинтересованными сторонами. Это помогает исключить недопонимание между заказчиком и исполнителем и снижает вероятность того, что работу придется переделывать. Все этапы разработки обстоятельно описываются, обеспечивается доступность документации для всех участников проекта — так налаживается эффективное взаимодействие. Работайте над общим видением Данный принцип Microsoft Solutions Framework подразумевает, что все члены команды должны детально понимать цели и задачи, над которыми работает коллектив. Общий взгляд на то, каким должен быть результат, гарантирует, что усилия разработчиков будут согласованными. Зачастую к успеху приводит именно умение правильно понять и сформулировать достоинства выработанного решения. Кроме того, эффективность труда в команде повышается, когда все сотрудники видят картину проекта в целом. Это стимулирует их интересоваться даже теми областями проекта, которые не относятся непосредственно к их задачам. Благодаря этому сотрудники глубже вникают в принципы работы программного продукта, обмениваются идеями и решениями, помогают друг другу и нарабатывают новые компетенции и командный опыт.  Расширяйте полномочия членов команды Каждому члену команды должны быть предоставлены все полномочия, необходимые для выполнения его обязанностей. Если его работа зависит от коллег, он должен быть уверен, что с их стороны не будет задержек и проволочек. Для дисциплины следует использовать графики, в которых будут обозначены сроки для каждой задачи. Разделяйте ответственность Все участники проекта принимают и осознают свою ответственность за порученную задачи и собственные решения.
Имеются ли программные средства реализации методологии, какие?	MSF разработана как комплекс отдельных компонентов — моделей и дисциплин. Всего их пять, и они описаны в пяти «белых книгах» (white papers) MSF.  Моделей используется две: модель команды; модель процесса. А дисциплин в MSF три: управление проектами; управление рисками; управление готовностью.
Используется ли в настоящее время	Данная методология Востребована и по сей день. Она встроена в среду разработки visual studio от той же компании microsoft
Примеры успешных проектов, реализованных с помощью данной методологии	Проект разработки игровой консоли Xbox; Проект разработки игры для ПК и Xbox “Halo”, а также последующие части всей франшизы; Проекты по разработке ОС Windows.

Задание 3.

Характеристика	Описание
Полное название методологии	Scrum
Авторы	Кен Швабер и Джефом Сазерлендом
История возникновения	Сам подход впервые описали Хиротака Такэути и Икудзиро Нонака в статье The New Product Development Game (Harvard Business Review, январь-февраль 1986). Они отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, обычно систематически производят лучшие результаты, и объяснили это как «подход регби». В 1991 году ДеГрейс и Шталь в книге «Нечестивые проблемы, праведные решения» называли подобный подход словом «scrum» (буквальный перевод — «толкотня», в регбийной терминологии — схватка), спортивный термин, приведённый в статье Такэути и Нонакой. Кен Швабер в начале 1990-х использовал подход, который привёл SCRUM в его компанию. Впервые методология SCRUM была представлена на общее обозрение задокументированной, чётко сформированной и описанной совместно Швабером и Джефом Сазерлендом на OOPSLA’95 в Остине. К. Швабер и Д. Сазерленд на протяжении следующих лет работали вместе, чтобы обработать и описать весь свой опыт и лучшие практические образцы для индустрии в одно целое, в ту методологию, что известна сегодня как SCRUM.
Страна появления	Япония, США
Основные принципы, подходы	Scrum не требует внедрения каких-либо дорогостоящих инструментов. Схему методики Scrum вкратце можно описать следующим образом: Для начала необходимо выбрать «Владельца продукта» — человека, обладающего видением того, что вы собираетесь создать или достигнуть. Затем нужно собрать «Команду», в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь. Нужно выбрать «Скрам-мастера» — того, кто будет следить за ходом реализации проекта, обеспечивать проведение коротких собраний и помогать команде устранять препятствия на пути достижения цели. Приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели. Пункты этого списка должны быть расставлены по приоритету. Список носит название «Бэклог продукта». Он может развиваться и изменяться на протяжении всего срока реализации проекта. Участники команды должны оценить по своей системе оценок каждый пункт на предмет сложности и затрат, которые потребуются для его выполнения. Затем участники, скрам-мастер и владелец продукта должны провести первое скрам-собрание, на котором они запланируют спринт — определенное время для выполнения части заданий. Продолжительность спринта не должна превышать один месяц. За каждый спринт команда нарабатывает определенное количество баллов. Команда должна постоянно стремиться к тому, чтобы превзойти в новом спринте количество наработанных баллов за предыдущий спринт, то есть ее цель — постоянно превосходить свои собственные результаты — «наращивать динамику производительности». Чтобы все участники были в курсе состояния дел нужно завести скрам-доску с тремя колонками: «Нужно сделать, или бэклог»; «В работе»; «Сделано». На доску участники клеят стикеры с заданиями, которые в процессе работы поочередно перемещаются из колонки «Бэклог» в колонку «в работе», а затем в «сделано». Ежедневно проводится скрам-собрание. По выражению Джеффа Сазерленда «это пульс всего процесса Scrum». Суть его проста — ежедневно, на ходу, пятнадцать минут на то, чтобы все дали ответы на три вопроса: «Что ты делал вчера, чтобы помочь команде завершить спринт?», «Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?», «Какие препятствия встают на пути команды?». По завершении спринта команда делает его обзор — проводит встречу, на которой участники рассказывают, что сделано за спринт. После показа результатов работы за спринт участники проводят ретроспективное собрание, на котором обсуждают, что команда делала хорошо, что можно сделать лучше, что можно улучшить прямо сейчас.
Имеются ли программные средства реализации методологии, какие?
Используется ли в настоящее время	Так как методология является гибкой и не трудоемкой, ее пользуются большинство маленьких it-стартапов
Примеры успешных проектов, реализованных с помощью данной методологии	Philip Morris Ukraine, Watsons, Multiplex

Задание 4.

Презентация на методологию SCRUM.