Файл: 1) в чем отличие решения технологических и функциональных задач Опишите этапы решения задач на эвм (блоксхема).docx

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

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

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

Добавлен: 26.10.2023

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

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

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


20) Опишите основные принципы и преимущества методологии разработки

ПО - Agile.

Методология Agile – Гибкая (адаптивная) методология разработки (agile software

development, agile-разработка) - обобщающий термин для целого ряда подходов и

практик, основанных на ценностях Манифеста гибкой разработки программного

обеспечения и 12 принципах, лежащих в его основе. Семейство методологий Agile

включает в себя методологии: SCRUM, Kanban, XP

12 принципов Agile:

1.Главное для Agile-команды - удовлетворенность клиентов, поэтому они обязательно представляют результаты своей работы через регулярные промежутки времени.

2.Изменение требований приветствуется даже на поздних стадиях разработки.

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

4.Agile-команды ценят постоянное общение, а не жестко распланированный выпуск

обновлений.

5.Над проектом должны работать мотивированные профессионалы. Чтобы работа

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

6.Непосредственное общение - наиболее практичный и эффективный способ обмена

информацией как с самой командой, так и внутри команды.

7.Работающий продукт - основной показатель прогресса.

8.Agile помогает наладить устойчивый процесс разработки.

9.Постоянное внимание к техническому совершенству и качеству проектирования

повышает гибкость проекта. Каждый новый проект - это возможность для

инноваций, а не для повтора одних и тех же идей.

10.Простота как искусство сократить до минимума лишнюю работу крайне

необходима.

11.Самые лучшие требования, архитектурные и технические решения рождаются у

самоорганизующихся команд. Лучшие команды - это те команды, у которых есть

лидер, предоставляющий им свободу самовыражения.

12.Команда должна систематически анализировать возможные способы улучшения

эффективности и соответственно корректировать стиль своей работы. Непрерывное

совершенствование - сама суть Agile.

21) Опишите базовые роли методологии SCRUM, применяемые при

разработке ПО.

В классическом Scrum существует 3 базовые роли:

1.Владелец продукта (Product owner, PO) - является связующим звеном между

командой разработки и заказчиком. Задача PO - максимальное увеличение ценности


разрабатываемого продукта и работы команды.

2.Скрам-мастер (Scrum master, SM) является «служащим лидером». Задача Scrum

Master помочь команде максимизировать ее эффективность посредством устранения

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

3.Команда разработки (Development team, DT) состоит из специалистов,

производящих непосредственную работу над производимым продуктом. DT должны

обладать следующими качествами и характеристиками:

· Быть самоорганизующейся.

· Быть многофункциональной, обладать всеми необходимыми навыками для

выпуска работающего продукта.

· За выполняемую работу отвечает вся команда, а не индивидуальные члены

команды.

22) Опишите процесс разработки по методологии SCRUM, основные

преимущества и недостатки.



Достоинство и недостатки методологии Scrum:

+ Scrum позволяет получить потенциально рабочий продукт в конце каждого Sprint'а.

+ Scrum делает упор на самоорганизующуюся, многофункциональную команду,

способную решить необходимые задачи с минимальной координацией.

-Scrum задает небольшое количество довольно жестких правил, которые могут

вступить в конфликт с идеей клиентоориентированности.

-особенностью Scrum является упор на самоорганизующуюся, многофункциональную

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

эффективной Scrum команды может быть невозможным.

-----------------------

23.Опишите основные принципы методологии разработки ПО - Kanban,

укажите преимущества и недостатки.

Kanban – японский термин (рекламный щит, вывеска) - метод управления

разработкой, реализующий принцип «точно в срок» и способствующий

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

разработчик может извлечь требуемую задачу.

Канбан основан на четырёх основных принципах:

1.Канбан начинается с существующих методов разработки и стимулирует в них

повышающие эффективность разработки изменения.

2.Команда разработчиков должна учитывать, что постоянные изменения - это способ

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



3. Уважение к существующему порядку, ролям и обязанностям.

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

Достоинство и недостатки методологии Канбан:

+ Гибкость планирования. Команда сконцентирована на текущих процессах, но при

необходимости можно изменить приоритеты.

+ Высокая вовлечённость команды. Совместное обсуждение всех вопросов и поиск

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

+ Команда всегда видит, у кого задание «не идёт» и может помочь, чтобы восстановить плавный поток.

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

-Ограничение по размеру команды. Метод подходит для команд до 5-10 человек. При

большем числе сотрудников становится сложно отслеживать выполнение работ.

-Краткосрочность планирования. Канбан-методология не предназначена для

долгосрочного планирования.

24) Опишите основные практики экстремального программирования по

методологии XP.

13 практик экстремального программирования:

1. Одна команда. Все участники проекта с применением XP работают как одна команда.

В нее обязательно входит представитель заказчика. Заказчик выдвигает требования к продукту

и расставляет приоритеты в реализации функциональности.

2. Игра в планирование. Планирование в XP проводят в два этапа — планирование релиза

и планирование итераций.

2.1. На планировании релиза команда программистов встречается с заказчиком, чтобы

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

В XP если команда не успевает выполнить все задачи к дате релиза, то релиз

не отодвигается, а режется часть функционала, наименее важная для заказчика.

2.2. Планирование итераций проводится каждые две недели. Заказчик обязательно

присутствует: он определяет функциональность на следующую итерацию и вносит

изменения в требования к продукту.

3. Частые релизы версий. В XP версии выпускаются часто, но с небольшим функционалом.

4. Пользовательские тесты. Заказчик сам определяет автоматизированные приемочные

тесты, чтобы проверить работоспособность очередной функции продукта. Команда пишет эти

тесты и использует их для тестирования готового кода.


5. Коллективное владение кодом. В XP любой разработчик может править любой кусок

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

6. Непрерывная интеграция кода. Это значит, что новые части кода сразу же встраиваются

в систему.

7. Стандарты кодирования. Когда кодом владеют все, важно принять единые стандарты

оформления, чтобы код выглядел так, как будто он написан одним профессионалом.

8. Метафора системы. Метафора системы - это ее сравнение с чем-то знакомым, чтобы

сформировать у команды общее видение.

9. Устойчивый темп. XP команды работают на максимуме продуктивности, сохраняя

устойчивый темп. При этом экстремальное программирование негативно относится

к переработкам и пропагандирует 40-часовую рабочую неделю.

10. Разработка, основанная на тестировании. В XP тесты пишутся самими программистами,

причем до написания кода, который нужно протестировать. При таком подходе каждый кусок

функционала будет покрыт тестами на 100%.

11. Парное программирование. Два разработчика работают над одним куском

функциональности продукта.

12. Простой дизайн. Простой дизайн в XP означает делать только то, что нужно сейчас,

не пытаясь угадать будущую функциональность.

13. Рефакторинг. Рефакторинг - это процесс постоянного улучшения дизайна системы, чтобы

привести его в соответствие новым требованиям.

25) Опишите процесс разработки программного обеспечения по методологии

XP. Укажите преимущества и недостатки метода.



Достоинство и недостатки методологии XP:

+ заказчик получает именно тот продукт, который ему нужен, даже если в начале

разработки сам точно не представляет его конечный вид;

+ код всегда работает за счет постоянного тестирования и непрерывной интеграции;

+ снижаются риски, связанные с разработкой, так как ответственность за проект

распределяется равномерно; + затраты на разработку ниже, так как команда ориентирована

на код, а не на документацию и собрания.

-успех проекта зависит от вовлеченности заказчика, которой не так просто добиться

трудно предугадать затраты времени на проект, так как в начале никто не знает полного


списка требований;

-успех XP сильно зависит от уровня программистов;

-менеджмент негативно относится к парному программированию, не понимая, почему

он должен оплачивать двух программистов вместо одного;

-регулярные встречи с программистами дорого обходятся заказчикам;

-отсутствие структуры и документации не подходит для крупных проектов