Файл: Вопросы к дифзачету по дисциплине Управление проектами в области it.docx

Скачать файл (1,41Мб)

Заказать решение

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 26.10.2023

Просмотров: 47

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

4. Внедрение (Transition)

В фазе «Внедрение» создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.

14. Спиральная модель.

Спиральная модель - Материал из Википедии

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

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

определение целей,
оценка и разрешение рисков,
разработка и тестирование,
планирование следующей итерации.

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

Преимущества:

Быстрое получение результата
Повышение конкурентоспособности
Изменяющиеся требования — не проблема

Недостатки:

Отсутствие регламентации стадий.

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

Дефицит специалистов.
Нереалистичные сроки и бюджет.
Реализация несоответствующей функциональности.
Разработка неправильного пользовательского интерфейса.
«Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.
Непрекращающийся поток изменений.
Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.
Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
Недостаточная производительность получаемой системы.
Разрыв между квалификацией специалистов и требованиями проекта.

15. Технология Microsoft Solutions Framework.

Microsoft Solutions Framework - Материал из Википедии

Методология разработки ПО Microsoft Solutions Framework (MSF)

ЛЕКЦИЯ 7. МЕТОДОЛОГИЯ MICROSOFT SOLUTIONS FRAMEWORK

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

Легче почитать по ссылкам. Много букв.

16. Понятие «экстремального программирования» (Extreme Programming - XP). Основные особенности ХР.

Экстремальное программирование - Материал из Википедии

Просто хороший сайт с красивыми графиками
Название методологии исходит из идеи применить полезные традиционные методы и практики разработки программного обеспечения, подняв их на новый «экстремальный» уровень. Так, например, практика выполнения ревизии кода, заключающаяся в проверке одним программистом кода, написанного другим программистом, в «экстремальном» варианте представляет собой «парное программирование», когда один программист занимается написанием кода, а его напарник в это же время непрерывно просматривает только что написанный код.
XP отличается от других гибких методологий тем, что применимо только в области разработки программного обеспечения. Оно не может быть использовано в другом бизнесе или повседневной жизни, как scrum, kanban или lean.

Цель методики XP — справиться с постоянно меняющимися требованиями к программному продукту и повысить качество разработки. Поэтому XP хорошо подходит для сложных и неопределенных проектов
Методология XP строится вокруг четырех процессов: кодирования, тестирования, дизайна и слушания (аналитики). Кроме того, экстремальное программирование имеет ценности: простоту, коммуникацию, обратную связь, смелость и уважение.

Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:

Короткий цикл обратной связи (Fine-scale feedback)

— Разработка через тестирование (Test-driven development)

— Игра в планирование (Planning game) — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими

— Заказчик всегда рядом (Whole team, Onsite customer) — XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.

— Парное программирование (Pair programming) — предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего.

Непрерывный, а не пакетный процесс

— Непрерывная интеграция (Continuous integration) — В XP интеграция кода всей системы выполняется несколько раз в день, после того, как разработчики убедились в том, что все тесты модулей корректно срабатывают.

— Рефакторинг (Design improvement, Refactoring) — XP подразумевает, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан.

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

— Частые небольшие релизы (Small releases) — версии (releases) продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой версией должна занимать как можно меньше времени. При этом каждая версия должна быть достаточно осмысленной с точки зрения полезности для бизнеса.

Понимание, разделяемое всеми

— Простота (Simple design) — XP исходит из того, что в процессе работы условия задачи могут неоднократно измениться, а значит, разрабатываемый продукт не следует проектировать заблаговременно целиком и полностью. Проектирование должно выполняться небольшими этапами, с учётом постоянно изменяющихся требований. В каждый момент времени следует пытаться использовать наиболее простой дизайн, который подходит для решения текущей задачи, и менять его по мере того, как условия задачи меняются.

— Метафора системы (System metaphor) — Архитектура — это представление о компонентах системы и их взаимосвязях между собой. Разработчикам необходимо проводить анализ архитектуры программного обеспечения для того, чтобы понять, в каком месте системы необходимо добавить новую функциональность, и с чем будет взаимодействовать новый компонент.

Метафора системы (system metaphor) — это аналог того, что в большинстве методик называется архитектурой. Метафора системы даёт команде представление о том, каким образом система работает в настоящее время, в каких местах добавляются новые компоненты, и какую форму они должны принять.

— Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership) -означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы. Парное программирование поддерживает эту практику: работая в разных парах, все программисты знакомятся со всеми частями кода системы. Важное преимущество коллективного владения кодом — в том, что оно ускоряет процесс разработки, поскольку при появлении ошибки её может устранить любой программист.

— Стандарт кодирования (Coding standard or Coding conventions) — в рамках XP необходимо добиться того, чтобы было сложно понять, кто является автором того или иного участка кода, — вся команда работает унифицированно, как один человек. Команда должна сформировать набор правил, а затем каждый член команды должен следовать этим правилам в процессе кодирования. Перечень правил не должен быть исчерпывающим или слишком объёмным. Задача состоит в том, чтобы сформулировать общие указания, благодаря которым код станет понятным для каждого из членов команды.

Социальная защищённость программиста (Programmer welfare)

— 40-часовая рабочая неделя (Sustainable pace, Forty-hour week)

17. Практики XP.

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

Парное программирование. Два программиста, один компьютер, две клавиатуры, одна программа. Сначала один пишет код, а второй следит. Если что-то пошло не так, бьёт коллегу по рукам и сразу исправляет. Через 15 минут — смена. Плюс в том, что во время перерыва ты продолжаешь работать — пока коллега вбивает код, сложно отвлечься на Facebook или трёп у кулера. За полтора часа два программиста сделают меньше кода, чем поодиночке, но качество будет выше.

Непрерывная интеграция. Делать упор на автоматизацию и интегрировать изменения постоянно. Что-то сделали — внедрили. Ещё — внедрили.

Разработка test-first. Сначала пишем тест, а потом код, который делает тест «зеленым», то есть успешно пройденным.

Инкрементальный дизайн. Не продумывать дизайн целиком до идеального состояния, а менять максимально часто и маленькими шагами. Воспринимать оболочку как инструмент, который выполняет функцию. Как только он перестал её выполнять — сразу нужно менять. Нет идеального дизайна, есть удобный дизайн, который можно быстро масштабировать. Как нет и финального дизайна. Он делается под задачу, а наперёд ничего не продумывается.

18. Планирование и оценка проекта. Основные этапы/действия.

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

Уточнить, детализировать цели и результаты мероприятия.
Определить состав и объем работ.
Оценить сроки и бюджетную стоимость.
Составить календарный план и бюджет основных фаз или всего проекта.
Произвести уточненную оценку потребностей в ресурсах на каждой фазе или для всей задачи.
Составить план ресурсного обеспечения.
Выполнить оценку рисков и создать план реагирования на них.
Разъяснить детали мероприятия заказчику.
Согласовать план с основными участниками.
Распределить ответственность за работы и задачи между участниками.
Утвердить сводный план.
Уточнить планы взаимодействия, процедуры управления планирование

19. Метод Дельфи оценки проекта.

Метод «Дельфи» - Материал из Википедии

Позволяет учесть независимое мнение всех экспертов путем последовательного объединения идей, выводов и предложений и прийти к согласию. Метод дельфи предполагает, что эксперты по вопросам рисков проекта принимают в нем участие анонимно. Основан на многократных анонимных групповых интервью.

20. Экспертный метод оценки проекта. Отличия от метода Дельфи.

Экспертное оценивание - Материал из Википедии

Характеристика методов экспертных оценок

Экспе́ртное оце́нивание — процедура получения оценки проблемы на основе мнения специалистов (экспертов) с целью последующего принятия решения (выбора).

Существует две группы экспертных оценок:

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

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

Известны следующие методы экспертных оценок:

Метод ассоциаций. Основан на изучении схожего по свойствам объекта с другим объектом.
Метод парных (бинарных) сравнений. Основан на сопоставлении экспертом альтернативных вариантов, из которых надо выбрать наиболее предпочтительные.
Метод векторов предпочтений. Эксперт анализирует весь набор альтернативных вариантов и выбирает наиболее предпочтительные.
Метод фокальных объектов. Основан на перенесении признаков случайно отобранных аналогов на исследуемый объект.
Индивидуальный экспертный опрос. Опрос в форме интервью или в виде анализа экспертных оценок. Означает беседу заказчика с экспертом, в ходе которой заказчик ставит перед экспертом вопросы, ответы на которые значимы для достижения программных целей. Анализ экспертных оценок предполагает индивидуальное заполнение экспертом разработанного заказчиком формуляра, по результатам которого производится всесторонний анализ проблемной ситуации и выявляются возможные пути её решения. Свои соображения эксперт выносит в виде отдельного документа.
Метод средней точки. Формулируются два альтернативных варианта решения, один из которых менее предпочтителен. После этого эксперту необходимо подобрать третий альтернативный вариант, оценка которого расположена между значений первой и второй альтернативы.