|
|
ЛР1. Программам бакалавриата Кафедра Информатика
Федеральное Агентство Связи
Ордена Трудового Красного Знамени федеральное государственное
бюджетное образовательное учреждение высшего образования
«Московский технический университет связи и информатики»
Центр заочного обучения по программам бакалавриата
Кафедра «Информатика»
Дисциплина: Программная инженерия
Лабораторная работа №1
«Методологии управления ИТ-проектами»
Выполнил: Сапаров У.Н.,
студент группы БСТ2055
Москва 2021
Задание 1.
В 1994 году консорциумом из 17 британских компаний на основе концепции быстрой разработки приложений RAD создается фреймворк (от англ. «framework» – каркас) разработки программного обеспечения «Dynamic Systems Development Method» (DSDM). Фреймворк представляет собой набор принципов, предопределённых типов ролей и следующих техник [6]:
таймбокс,
принцип назначения приоритетов «MoSCoW»,
семинары,
построение прототипов.
Методика таймбоксов является основной техникой DSDM, использующаяся для того, чтобы выполнить проект в срок, уложиться в бюджет и сохранить качество. Таймбокс представляет собой итерацию, в рамках которых проект делится на логичные участки, разнесенные во времени. Таймбоксы не делятся на под события, а функционал не критичен, в следствие чего он может быть частично исключен в целях экономии времени, в порядке, определенном методом расстановки приоритетов «MoSCoW». Метод расстановки приоритетов «MoSCoW» определяет 4 уровня приоритетов:
должно быть (must have),
следует чтобы было (should have),
нужно (could have) и
можно (want have).
Методика построение прототипов подразумевает разработку функциональных, производительных и прочих моделей на различных стадиях работы над проектом, что позволяет выявить сложности, с которыми придется столкнуться, оценить производительность, удобство интерфейса и функциональность, в том числе с коммерческой точки зрения.
В DSDM уделяется особое внимание участию в процессе разработки пользователя (потребителя), что закреплено в принципах, являющихся неотъемлемой частью фреймворка [7]:
Активное вовлечение пользователей в процесс разработки;
Команда разработчиков может принимать решения;
Частая поставка результатов;
Критерием приемлемости результатов является их соответствие бизнесу;
Итеративная и инкрементальная разработка;
Любые действия могут быть отменены;
Стабильность высокоуровневых требований;
Тестирование выполняется постоянно и непрерывно;
Взаимодействие и кооперация.
Как писалось выше, методология DSDM определяет набор стандартных ролей, каждой из которых, в свою очередь, соответствует определенная зона ответственности, такие как:
менеджер проекта – общее руководство;
провидец – следит за соответствием коммерческим целям и задачам;
чемпион проекта – распоряжение ресурсами;
лидер команды – руководит разработчиками;
технический координатор – архитектура;
разработчик – разработка;
тестировщик – тестирование;
представительный пользователь – представляет интересы потребителей;
пользователь консультант – консультирует по вопросам использования продукта;
секретарь – отвечает за протоколирование;
посредник – отвечает за взаимодействие между членами команды;
Последняя версия методологии, вышедшая в 2007 году и именуемая DSDM Atern, предполагает следующие 7 этапов жизненного цикла проекта:
1. Пре-проект. На первом этапе жизненного цикла проекта определяется целесообразность проекта и помимо прочего допускается выпуск акта об инициации проекта.
2. Осуществимость. На данном этапе определяется технико-экономическая возможность реализации проекта, в том числе возможность эффективного достижения целей бизнеса.
3. Определение бизнес процессов – подразумевает определение требований, стратегии, архитектуры, используемых стандартов и возможных рисков сопутствующих процессу реализации проекта.
4. Разведка. На данном этапе предполагается построение бизнес-прототипов и формирование списка функциональных требований.
5. Инжиниринг. Проектно-конструкторские изыскания направленные на решение нефункциональных требований (например, производительности, безопасности, возможностей поддержки и сопровождения). В том числе реализация всех требований для успешной работы продукта.
6. Развертывание – подразумевает цикл работ для предоставления продукта конечному потребителю, обучение и написание документации. Также выявляется соответствует ли продукт всем установленным бизнес требованиями.
7. Пост-проект. На данном этапе подводятся итоги и оценивается эффективность принятых решений, рекомендуется делать это спустя 3-6 месяцев чтобы обладать большим количеством информации о результатах работы проекта.
Задание 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 |
|
|
Скачать 27.03 Kb.