Материал: Ответы на вопросы к экзамену
Жизненный цикл разработки по
Понятие ЖЦ разработки ПО. Основные понятия, связанные с ЖЦ разработки ПО.
Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.
Понятия
процессы ЖЦ - различные виды деятельности, которые могут выполняться в течение ЖЦ программных систем. Каждый из процессов описывается в терминах цели и желаемых выходов, списков действий и задач, которые необходимо выполнять для достижения этих результатов. Каждый процесс включает в себя ряд действий. Каждое действие включает в себя ряд задач.
модель ЖЦ - структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Модель ЖЦ включает в себя стадии, результаты выполнения работ на каждой стадии и ключевые события - точки завершения работ и принятия решений.
Двойственность понятия разработки\проектирования ПО.
Существует два основных аспекта разработки\проектирования ПО: статический и динамический. UML предлагает использовать для описания архитектуры 8 видов диаграмм. Диаграммы UML делятся на две группы — статические и динамические диаграммы.
Статические диаграммы представляют постоянно присутствующие в системе сущности и связи между ними. К этому типу относятся диаграммы классов, объектов, компонентов и диаграммы развертывания.
Диаграммы классов (classdiagrams) показывают классы или типы сущностей системы, характеристики классов (поля и операции) и возможные связи между ними.
Диаграммы объектов (objectdiagrams) показывают часть объектов системы и связи между ними в некотором конкретном состоянии или суммарно, за некоторый интервал времени.
Диаграммы компонентов (componentdiagrams) представляют компоненты в нескольких смыслах — атомарные составляющие системы с точки зрения ее сборки, конфигурационного управления и развертывания.
Диаграммы развертывания (deploymentdiagrams) показывают декомпозицию системы на физические устройства различных видов — серверы, рабочие станции, терминалы, принтеры, маршрутизаторы и пр.
Динамические диаграммы описывают происходящие в системе процессы. К ним относятся диаграммы деятельности, сценариев, диаграммы взаимодействия и диаграммы состояний.
Диаграммы деятельности (activitydiagrams) иллюстрируют набор процессов-деятельностей и потоки данных между ними, а также возможные их синхронизации друг с другом.
Диаграммы сценариев (или диаграммы последовательности, sequencediagrams) показывают возможные сценарии обмена сообщениями или вызовами во времени между различными компонентами системы.
Диаграммы взаимодействия (collaborationdiagrams) показывают ту же информацию, что и диаграммы сценариев, но привязывают обмен сообщениями/вызовами не к времени, а к связям между компонентами.
Диаграммы состояний (statechartdiagrams) показывают возможные состояния отдельных компонентов или системы в целом, переходы между ними в ответ на какие-либо события и выполняемые при этом действия.
Понятие модели ЖЦ и ее роль в разработке ПО.
Модель ЖЦ - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, использования и сопровождения программного продукта. Роль ЖЦ - помогает понять, на что можно рассчитывать при заказе или приобретении программного обеспечения и что нереально требовать от него, выстраивает свои методы и инструменты вокруг фаз и этапов жизненного цикла, общие знания того, как развивается программный проект, дают наиболее надежные ориентиры для его планирования, позволяют экономнее расходовать ресурсы, добиваться более высокого качества управления.
Каскадная модель ЖЦ и ее особенности.
Каскадная модель.
Каскадная модель (англ. waterfall model) — модель, жизненный цикл которой выглядит как поток, последовательно проходящий фазы анализа требований, проектирования. реализации, тестирования, интеграции и поддержки.
Жизненный цикл традиционно разделяют на следующие основные этапы:
Анализ требований,
Проектирование,
Кодирование (программирование),
Тестирование и отладка,
Эксплуатация и сопровождение.
Достоинства модели:
стабильность требований в течение всего жизненного цикла разработки;
на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
определенность и понятность шагов модели и простота её применения;
выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие ресурсы (денежные. материальные и людские).
Недостатки модели:
сложность чёткого формулирования требований и невозможность их динамического изменения на протяжении пока идет полный жизненный цикл;
низкая гибкость в управлении проектом;
последовательность линейной структуры процесса разработки, в результате возврат к предыдущим шагам для решения возникающих проблем приводит к увеличению затрат и нарушению графика работ;
непригодность промежуточного продукта для использования;
Каскадная модель хорошо зарекомендовала себя при построении относительно простых ПО, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к продукту.
Реализовать Каскадную модель жизненного цикла затруднительно ввиду сложности разработки ПО без возвратов к предыдущим шагам и изменения их результатов для устранения возникающих проблем.
Итерационная модель ЖЦ и ее особенности.
Инкрементная модель
Инкрементная модель (англ. increment — увеличение, приращение) подразумевает разработку программного обеспечения с линейной последовательностью стадий, но в несколько инкрементов (версий), т.е. с запланированным улучшением продукта за все время пока Жизненный цикл разработки ПО не подойдет к окончанию.
Достоинства:
затраты, которые получаются в связи с изменением требований пользователей, уменьшаются, повторный анализ и совокупность документации значительно сокращаются по сравнению с каскадной моделью;
легче получить отзывы от клиента о проделанной работе — клиенты могут озвучить свои комментарии в отношении готовых частей и могут видеть, что уже сделано. Т.к. первые части системы являются прототипом системы в целом.
у клиента есть возможность быстро получить и освоить программное обеспечение — клиенты могут получить реальные преимущества от системы раньше, чем это было бы возможно с каскадной моделью.
Недостатки:
менеджеры должны постоянно измерять прогресс процесса.
в случае быстрой разработки не стоит создавать документы для каждого минимального изменения версии;
структура системы имеет тенденцию к ухудшению при добавлении новых компонентов — постоянные изменения нарушают структуру системы. Чтобы избежать этого требуется дополнительное время и деньги на рефакторинг. Плохая структура делает программное обеспечение сложным и дорогостоящим для последующих изменений. А прерванный Жизненный цикл ПО приводит еще к большим потерям.
Схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к ПО. Согласование результатов разработки с пользователями производится только в точках, планируемых после завершения каждого этапа работ, а общие требования к ПО зафиксированы в виде технического задания на всё время её создания.
Сравнение каскадной и водопадной моделей жц.
SCRUM
Общее описание фреймворка SCRUM
Scrum - это методология управления проектами, относящаяся к Agile-методам, то есть гибким подходам к разработке программного обеспечения. О Scrum, как правило, говорят именно в IT-контексте, хотя применяться он может много где. Это фреймворк, то есть каркас, структура, и оплетать этот эффективный каркас индивидуальными особенностями проекта можно в разных областях, если по самой своей сути проект и Scrum «совместимы».
Scrum – это такой процесс, который помогает выявить настоящий процесс, структуру, режим работы, которые постоянно адаптируются под актуальный контекст и текущие обстоятельства. Scrum - это фреймворк, описывающий роли и правила, опираясь на принципы, которые содействуют и помогают людям выполнять свои задачи при минимуме предписаний.
Краткая характеристика артефактов фреймворка SCRUM
Основные артефакты:
burndown-диаграмма - диаграмма, демонстрирующая количество сделанной и оставшейся работы относительно времени на разработку проекта.
backlog проекта - список требований к функциональности проекта, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются пользовательскими историями (user story) или элементами беклога (backlog items). Журнал пожеланий проекта открыт для редактирования для всех участников скрам-процесса.
backlog спринта - содержит функциональность, выбранную владельцем продукта из журнала пожеланий проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой.
канбан-доска - должна состоять как минимум из трех колонок: «сделать» (англ. to-do), «в процессе» (in progress), «сделано»(done). При разработке ПО SCRUM канбан-доска обычно включает следующие колонки в соответствии со статусом задач: обсуждается (backlog), согласовано (ready), кодируется (coding), тестируется (testing), подтверждается (approval) и сделано (done).
цель спринта - это краткое описание бизнес-цели, ради которой выполняется данный спринт.
инкремент продукта - это готовый продукт в конце спринта. Показывают заинтересованным на демонстрации, чтобы собрать отзывы и решить, что делать с продуктом дальше.
история пользователя - требуемую бизнес-функциональность, которую добавляют в бэклог, часто называют историей. Зачастую история имеет следующую структуру: «Будучи пользователем <тип пользователя> я хочу сделать <действие>, чтобы получить <результат>».
очки за пользовательскую историю (story points) - абстрактная метрика оценки сложности истории, которая не учитывает затраты в человекочасах.
задачи истории спринта - добавляются к историям спринта. Выполнение каждой задачи оценивается в часах. Каждая задача не должна превышать 12 часов.
Краткая характеристика процессов фреймворка SCRUM
спринт - время, в течение которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении все жизни продукта.
планирование спринта - производится перед началом каждого спринта, во время него производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте.
daily scrum (scrum-митинг) - производится каждый день, каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint'а.
обзор спринта - проводится в конце спринта. Команда демонстрирует прирост инкремента продукта всем заинтересованным лицам. Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт). Нельзя демонстрировать незавершенную функциональность. Ограничена четырьмя часами в зависимости от продолжительности итерации и прироста функциональности продукта.
ретроспектива - проводится в конце спринта. Члены скрам-команды, скрам-мастер и продукт-оунер высказывают свое мнение о прошедшем спринте. Скрам-мастер задает два вопроса всем членам команды: Что было сделано хорошо в прошедшем спринте? Что надо улучшить в следующем? Выполняют улучшение процесса разработки (обсуждают варианты решения проблем, фиксируют удачные решения и вызвавшегося владельца продукта). Ограничена четырьмя часами для спринта любой длины.
груминг бэклога - скрам-команда и владелец могут добавить, убрать или разбить элементы бэклога продукта, уточнить или дать новые оценки, изменить порядок следования элементов бэклога продукта, обсудить и проявить требования.
Краткая характеристика ролей фреймворка SCRUM
скрам-мастер - проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.
скрам-владелец продукта - представляет интересы конечных пользователей и других заинтересованных в продукте сторон.
скрам-команда - кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды составляет от 5 до 9 человек. Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Никто, кроме скрам-команды, скрам-мастера и владельца продукта не может вмешиваться в процесс разработки на протяжении спринта.
Отличия ролей владельца продукта от скрам-мастера на примере среды DEVPROM.
В среде Devprom владелец продукта не видит состава команды, в то время как скрам-мастер не только видит состав команды, но и может назначать задачи участникам проекта. Скрам-мастер отвечает за то, чтобы владелец продукта и команда правильно действовали при разработке продукта.
Понятие гибких методологий, используемых для разработки ПО.
Agile-методы - обобщающий термин для целого ряда подходов и практик, основанных на ценностях Манифеста гибкой разработки программного обеспечения и 12 принципах, лежащих в его основе.
Основные идеи:
люди и взаимодействие важнее процессов и инструментов;
работающий продукт важнее исчерпывающей документации;
сотрудничество с заказчиком важнее согласования условий контракта;
готовность к изменениям важнее следования первоначальному плану.
Принципы:
удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);
тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
работающее программное обеспечение — лучший измеритель прогресса;
спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
постоянное внимание улучшению технического мастерства и удобному дизайну;
простота — искусство не делать лишней работы;
лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Принцип декомпозиции задач и его реализация в среде DEVPROM.
Принцип декомпозиции задач - это последовательное разбиение более крупных задач на более мелкие. В Devprom это реализовано следующим образом: крупные истории преобразуются владельцем продукта в эпики (самый верхний уровень декомпозиции), эпик состоит из некоторого количества пользовательских историй, в каждой пользовательской истории указаны задачи, выполнение которых необходимо для достижения цели истории.
Сравнение типов проектов поддерживаемых средой DEVPROM
Это из кр1) Основные типы:
Легковесные процессы разработки (поиск или создание продукта, развитие продукта, сопровождение продукта)
Процессы с предварительным проектированием (разработка по требованиям, разработка по ГОСТ)
Поддержка пользователей
Легковесные процессы предназначены для проектов с незначительными рисками, ориентированные больше на скорость поставки работающего продукта. Процессы с предварительным проектированием предназначены для проектов с повышенными рисками (много участников, высокая сложность, жесткие требования по срокам и т.п.), ориентированные на более глубокую проработку требований, перед их реализацией. Это позволяет лучше прогнозировать стоимость работ, меньше усилий тратить на программирование, создавать более качественный продукт.
Механизм оценки скорости разработки команды в среде DEVPROM с использованием фреймворка SCRUM
Burndown-диаграмма показывает текущее состояние итерации, исходя из общего объема запланированной на итерацию работы (в часах, желтая линия), выполненного объема работы (в часах, зеленая линия) и длины итерации. Красная линия показывает идеальную скорость, с которой должна работать проектная команда. Синяя линия показывает прогноз по сроку, к которому оставшийся объем работ по итерации будет выполнен, исходя из текущей скорости команды.
График скорости команды в devprom отображает скорость работы команды в разрезе спринтов проекта. Скорость вычисляется на основе суммарных плановых оценок пожеланий, выполненных в спринтах.
Принципы совместной работы по созданию документации в среде DEVPROM
Над созданием документации могут работать одновременно несколько участников команды. Над одним разделом (подразделом) в одно и то же время может работать только один человек. Удобнее всего назначать задачи на заполнение каждого раздела конкретному участнику, так можно избежать рассогласованности действий.
UP
Краткая характеристика UP проектирования.
Унифицированный процесс как процесс разработки программного обеспечения представляет собой методологию, содержащую детальное описание работ по созданию и внедрению ПО. Содержит описание: технологических процессов, видов деятельности, исполнителей, артефактов.