|
|
Программирование алгоритмов формирования. ЛР1 Васильева А.А. Лабораторная работа 1 по дисциплине Программная инженерия студентк группы убст2002 Нартов Дмитрий Игоревич Москва, 2021
Лабораторная работа №1
по дисциплине «Программная инженерия»
Выполнила: студентк группы УБСТ2002:
Нартов Дмитрий Игоревич
Москва, 2021
Лабораторная работа №1
Методологии управления ИТ-проектами
Цель: знакомство с методологиями управления ИТ-проектами.
Ход работы
Задание 1. С помощью поиска в сети Интернет я нашла информацию о современных методологиях управления ИТ-проектами. Ниже, в блок-схеме, я представила основания для их классификации (Рис. 1). Для каждого основания привела примеры методологий.
Рис. 1 «Блок-схема выбора методологии»
Краткое описание основных элементов блок-схемы:
● Наличие серьезных рисков
Несомненно, каждый проект имеет свои риски. Здесь же имеется в виду такие риски, которые изначально могут ставить под вопрос конечный успех проекта. Если такие риски имеются, то проект следует начинать с прототипирования, моделирования и разработки концепции проекта. В таком случае хорошо подойдет спиральная модель, главной особенностью которой является концентрация на подробном анализе рисков.
● Изменение требований во времени
Если требования известны заранее и высока вероятность того, что они не изменятся в процессе реализации проекта, следует выбирать водопадную модель. Однако продолжительные сроки проекта повышают вероятность возникновения технических рисков. В таком случае водопадная модель будет работать не очень хорошо. Например, разработка неправильной архитектуры или выбор не тех инструментов, скорее всего, обнаружится в конце проекта, когда времени на исправление будет уже мало, цена поправки ошибки будет большой. Если на первоначальном этапе исправление ошибок допускается, то в конечной стадии проекта, на это уйдет много времени и денег.
● Сложность требований
В начале проекта, на этапах анализа и проектирования, зачастую, бывает полезно продумать, как будет осуществляться тестирование. Это помогает выявить вероятные проблемы, лучше продумать архитектуру и более тщательно проработать требования. Сложные требования заставляют подробно продумывать сценарии тестирования. С такой задачей хорошо справляется V-Model, являющаяся продвинутым вариантом каскадной модели, которая предусматривает глубокий контроль текущего процесса перед переходом на следующий этап. Если V-Model будет применяться на простых проектах, то это значительно увеличит затраты на реализацию проекта.
● Степень формализованности
Формализованность означает детальную регламентацию жизненного цикла проекта. Это требуется в сложных проектах с большой командой.
Например, в проектах транспортной, энергетической и медицинской отраслях, где разработка происходит согласно стандартам, где продукт многократно тестируется и лицензируется. Формализованный подход наиболее хорошо реализуют такие методологии как RUP, OpenUp.
● Приоритет: качество или быстрота
Быстрота предполагает ориентир на скорейшее добавление функционала в разрабатываемый продукт. Качество – высокий уровень организации разработки, применение сложных практик, требующих высокий уровень подготовки и самоорганизации команды. Например, практики экстремального программирования: разработка, основанная на тестировании, парное программирование, коллективное владение кодом и т.д.
Использование всех практик экстремального программирования обеспечивает высокое качество получаемого продукта, однако может оказаться затратным.
● Необходимость постоянного совершенствования
Методология Скрам направлена на постоянное улучшение продукта и процесса работы. Это достигается за счет ретроспективы спринтов, на которых обсуждаются положительные и отрицательные стороны работы команды.
Однако у опытной команды с хорошо отлаженными процессами Скрам может занимать слишком много времени, которое могло бы быть потрачено более продуктивно. Если же команда неопытная или реализует продукт в незнакомой для себя сфере или использует непроверенные инструменты, то в таком случае Скрам отлично подойдет. Когда процесс работы над проектом стабилизируется, можно перейти к другим методологиям, например, Канбан.
● Ограничение проекта во времени
Если процессы работы над проектом отлажены и необходима концентрация на выполнении задач, то отлично подойдет Kanban или RAD. RAD имеет черты гибких методологий, однако ограничен по срокам, обычно это 60 - 90 дней. Kanban же представляет собой непрерывный конвейер, работающий бесконечно. Kanban хорошо показывает себя на проектах поддержки ПО и тестирования, но плохо работает с проектами, требующими разработку сложной архитектуры, так как ориентирован на быстрое добавление функциональных элементов продукта. Также Kanban хорошо применим для стартапов, где нет четкого плана, но активно ведется разработка продукта.
Задание 2. Из полученного списка легковесных (agile) методологий управления ИТ-проектами я выбрала один. Провела исследование методологии и результат представила в таблице.
Характеристика
|
Описание
|
Полное название методологии
|
Rational Unified Process (RUP)
|
Авторы
|
Основными разработчиками были Филипп Крачтен, Грейди Буч, Джеймс Рамбо и Айвар Якобсон
|
История возникновения
|
Rational Software изначально разработала рациональный унифицированный процесс как программный продукт. В 1996 году, когда Rational приобрела Objectory Process, который был написан Иваром Якобсоном и компанией. В последующих выпусках он был переименован в Rational Unified Process (RUP).
Эти начальные версии объединили обширный практический опыт организации Rational Software в создании объектно-ориентированных систем (именуемых полевыми сотрудниками Rational как Rational Approach) с руководством Objectory по таким практикам, как варианты использования, и включили обширный контент от Джима. Подход Рамбо Object Modeling Technology (OMT) к моделированию, метод Grady Booch Booch и недавно выпущенный UML0.8.
В 1997 г. к подходу были добавлены требования и дисциплина тестирования, большая часть дополнительных материалов была получена из метода Requirements College, разработанного Дином Леффингвеллом и др. в Requisite, Inc., и метод SQA Process, разработанный в SQA Inc., обе компании были приобретены Rational Software.
В 1998 году Rational Software добавила две новые дисциплины:
бизнес-моделирование, большая часть этого контента уже была в Objectory Process
дисциплина Configuration and Change Management, полученная за счет приобретения Pure Atria Corporation.
В 1999 г. была введена дисциплина управления проектами, а также методы поддержки разработки программного обеспечения в реальном времени и обновлений для отражения UML 1.3. Кроме того, в том же году была издана первая книга, описывающая этот процесс, «Унифицированный процесс разработки программного обеспечения» (ISBN 0-201-57169-2 ).
Между 2000 и 2003 годами был внесен ряд изменений, основанных на текущем полевом опыте Rational в области итеративной разработки, в дополнение к инструментальной поддержке для внедрения экземпляров RUP и настройки структуры RUP.
IBM приобрела Rational Software в феврале 2003 года.
В 2006 году IBM создала подмножество RUP, предназначенное для реализации проектов Agile - выпущен как метод OpenSource под названием OpenUP на веб-сайте Eclipse.
|
Страна появления
|
Америка
|
Основные принципы, подходы
|
Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.
Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования).
Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.
|
Имеются ли программные средства реализации методологии, какие?
|
Rational Rose — CASE-средство визуального моделирования информационных систем, имеющее возможности генерирования элементов кода.
Rational Requisite Pro — средство управления требованиями, позволяющее создавать, структурировать, устанавливать приоритеты, отслеживать, контролировать изменения требований, возникающие на любом этапе разработки компонентов приложения;
Rational ClearQuest — продукт для управления изменениями и отслеживания дефектов в проекте тесно интегрирующийся со средствами тестирования и управления требованиями и представляющий собой единую среду для связывания всех ошибок и документов между собой;
Rational SoDA — продукт для автоматического генерирования проектной документации, позволяющий установить корпоративный стандарт на внутрифирменные документы.
Rational Purify, Rational Quantify Rational PureCoverage, — средства тестирования и отладки.
|
Используется ли в настоящее время
|
Да, используется
|
Примеры успешных проектов, реализованных с помощью данной методологии
| IBM - американская компания, один из крупнейших в мире производителей и поставщиков аппаратного и программного обеспечения, а также IТ-сервисов и консалтинговых услуг.
Oracle - американская корпорация, второй по величине доходов производитель программного обеспечения (после Microsoft), крупнейший производитель программного обеспечения для организаций, крупный поставщик серверного оборудования. Borland - компания по производству программного обеспечения, наиболее известна как создатель разработческих инструментов Turbo Pascal и Delphi.
Computer Associates - американская корпорация, разработчик программного обеспечения. |
Задание 3. Из полученного списка тяжеловесных методологий управления ИТ-проектами я выбрала один. Провела исследование методологии. Результат представила в таблице (по аналогии с заданием 2).
Особенности методики
Характеристика
|
Описание
|
Полное название методологии
|
SCRUM
|
Авторы
|
Джефф Сазерленд и Кен Швабер
|
История возникновения
|
Первоисточниками методологии Scrum послужили: производственная система компании Toyota и цикл OODA (OODA loop, или петля OODA, или петля Бойда) концепции применения боевой авиации, включающий в себя четыре составляющих: observe («наблюдать»), orient («ориентироваться»), decide («решать»), act («действовать»).
Сам подход впервые описали Хиротака Такэути и Икудзиро Нонака в статье The New Product Development Game (Harvard Business Review, январь-февраль 1986). Они отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, обычно систематически производят лучшие результаты, и объяснили это как «подход регби».
В 1991 году ДеГрейс и Шталь в книге «Нечестивые проблемы, праведные решения» называли подобный подход словом «scrum» (буквальный перевод — «толкотня», в регбийной терминологии — схватка), спортивный термин, приведённый в статье Такэути и Нонакой. Кен Швабер в начале 1990-х использовал подход, который привёл SCRUM в его компанию. Впервые методология SCRUM была представлена на общее обозрение задокументированной, чётко сформированной и описанной совместно Швабером и Джефом Сазерлендом на OOPSLA’95 в Остине. К. Швабер и Д. Сазерленд на протяжении следующих лет работали вместе, чтобы обработать и описать весь свой опыт и лучшие практические образцы для индустрии в одно целое, в ту методологию, что известна сегодня как SCRUM.
Швабер объединил усилия с Майком Бидлом в 2001 году, чтобы детально описать метод в книге «Agile Software Development with SCRUM».
В 2002 году Швабер вместе с другими основал Альянс Scrum и создал серию сертифицированных аккредитаций Scrum. Швабер покинул Scrum Alliance в конце 2009 года и основал Scrum.org, который курирует параллельную серию аккредитаций Professional Scrum.
С 2009 года публичный документ под названием The Scrum Guide официально определяет Scrum. Он был пересмотрен более 5 раз. В 2018 году Швабер и сообщество Scrum.org вместе с лидерами сообщества Kanban опубликовали Руководство по Kanban для групп Scrum.
|
Страна появления
|
Америка
|
Основные принципы, подходы
|
Scrum всегда ориентируется на клиента, который должен получить желаемый продукт вовремя и с минимальными затратами. Этого можно достичь при соблюдении нескольких обязательных принципов.
Работа короткими циклами (спринтами)
Планируйте один спринт, а не весь проект сразу. Каждый спринт — период, в который команда работает над полностью законченной частью продукта.
Гибкость. «Проверять и адаптироваться»
Гибкость процесса и тестирование продукта после каждого спринта. Если что-то идёт не так, команда всегда готова сменить стратегию разработки или пересмотреть бэклог продукта.
Участие заказчика и пользователей в создании продукта
Заказчик не стоит в стороне, а полностью задействован в работе. Для этого существует роль владельца продукта, которую выполняет сам заказчик или его представитель. Именно через него команда взаимодействует с пользователями. Так как разработка ведётся короткими этапами, пользователи подключаются к тестированию почти сразу.
После первичного тестирования им открывают доступ к продукту, а владелец продукта собирает обратную связь. Так команда может совершенствовать результат.
Взаимодействие команды
Scrum-команда — это несколько человек, которые работают на один результат и как единое целое. Каждый стремится к общей цели.
|
Имеются ли программные средства реализации методологии, какие?
|
Wrike - Лучшее для Scrum и гибких шаблонов
Работа в команде - Лучшее для документации по API
monday.com - Лучшее для команд Scrum с высокой степенью совместной работы
ClickUp - Лучшее бесплатное программное обеспечение Scrum
Jira - Лучшее программное обеспечение scrum для предприятий
Targetprocess - Лучшее программное обеспечение Scrum для ретроспективы спринта
VivifyScrum - Лучшее для небольших команд и стартапов
Axosoft - Лучшая панель управления Sprint
Orangescrum - Лучшее программное обеспечение Scrum с управлением ресурсами
SwiftKanban - лучший инструмент Scrum для инженерии
|
Используется ли в настоящее время
|
Да, используется
|
Примеры успешных проектов, реализованных с помощью данной методологии
|
Salesforce - американская компания, разработчик одноимённой CRM-системы, предоставляемой заказчикам исключительно по модели SaaS.
Valve - американская компания-разработчик компьютерных игр, создавшая такие серии игр как: Half-Life, Portal, Counter-Strike, Team Fortress, Day of Defeat.
WIKISPEED - Автомобильный производитель, выпускающий автомобили модульной конструкции. |
Задание 4. Выберите любую из проанализированных методологий. Создайте о ней презентацию на 10-15 слайдов. Выступите в группе, будьте готовы ответить на вопросы. |
|
|
Скачать 121.37 Kb.