Модель XP экстремального программирования разработки ПО?

 

Экстремальное программирование является примером, так называемого метода «живой» разработки. Экстремальное программирование– сравнительно молодая методология разработки программных систем, основанная на постепенном улучшении системы и разработки ее очень короткими итерациями [7]. По своей сути экстремальное программирование (XP) – это одна из так называемых «гибких» методологий разработки ПО, представляющая собой небольшой набор конкретных правил, позволяющих максимально эффективно выполнять требования современной теории управления программными проектами.

XP ориентирована на:

· командную работу с тесными связями внутри команды и с заказчиком;

· разработку наиболее простых работающих решений;

· гибкое адаптивное планирование;

· оперативную обратную связь (путем модульного и функционального тестирования).

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

Основными фазами модели можно считать:

1. «Вброс» архитектуры – начальный этап проекта, на котором создается видение продукта, принимаются основные решения по архитектуре и применяемым технологиям. Результатом начального этапа является метафора (metaphor) системы, которая в достаточно простом и понятном команде виде должна описывать основной механизм работы системы.

2. Истории использования (User Story) – этап сбора требований, записываемых на специальных карточках в виде сценариев выполнения отдельных функций. User Story являются требованиями для планирования очередной версии и одновременной разработки приемочных тестов (Acceptance tests) для ее проверки.

3. Планирование версии (релиза). Проводится на собрании с участием заказчика путем выбора User Stories, которые войдут в следующую версию. Одновременно принимаются решения, связанные с реализацией версии. Цель планирования - получение оценок того, что и как можно сделать за 1-3 недели создания следующей версии продукта.

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

5. Тестирование проводится с участием заказчика, который участвует в составлении тестов.

6. Выпуск релиза – разработанная версия передается заказчику для использования или бета-тестирования.

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

 

 

16. Структурная декомпозиция работ и какие планы существуют при структурной декомпозиции работ?

 

Структурная декомпозиция работ – графическое изображение иерархической структуры всех работ проекта

Структурная декомпозиция работ (СДР) проекта (Work Breakdown Structure – WBS)

– разбиение проекта на составные части (элементы, модули, работы и др.), необходимые и достаточные для его эффективного планирования и контроля.

При построении ИСР необходимо соблюдать следующие правила:

1.Работы нижнего уровня являются способом достижения работ верхнего уровня.

2. У каждой родительской работы может иметься несколько дочерних работ, достижение которых автоматически обеспечивает достижение родительской работы.

3.У каждой дочерней работы может быть только одна родительская работа.

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

5.На одном уровне дочерние работы, декомпозирующие родительскую должны быть равнозначны. В качестве критерия равнозначности могут выступать: объем и время выполнения работ, пр.

6.При построении иерархической структуры работ на различных уровнях

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

7. Последовательность критериев декомпозиции работ следует выбирать таким образом, чтобы как можно большая часть зависимостей и взаимодействий между работами оказалась на самых нижних уровнях ИСР. На верхних уровнях работы должны быть автономны.

8. Декомпозиция работ прекращается тогда, когда работы нижнего уровня удовлетворяют следующим условиям:

•работы ясны и понятны менеджеру и участникам проекта (являются элементарными),

•понятен конечный результат работы и способы его достижения,

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

 

17. Фазы обеспечения качества ПО: «отбраковки», «управления продуктом» и «планирования качества», «управление программой» и «Анализ рисков» согласно MSF?

 

Ролевой кластер	Цель	Область компетенции	Функции
Управление продуктом	Удовлетворенные заказчики	Маркетинг. Бизнес-отдача (бизнес-приоритеты). Представление интересов заказчика. Планирование продукта.	выступает в роли представителя заказчика; формирует общее видение/рамки проекта; организует работу с требованиями заказчика; развивает сферы применения в бизнесе; формирует ожидания заказчика; определяет компромиссы между параметрами «возможности продукта / время / ресурсы»; организует маркетинг и PR; разрабатывает, поддерживает и исполняет план коммуникаций
Управление программой	Достижение результата в рамках проектных ограничений	Управление проектом. Выработка архитектуры решения. Контроль производственного процесса. Административные службы.	управляет процессом разработки с целью получения готового продукта в отведенные сроки; формулирует спецификацию продукта и разрабатывает его архитектуру; регулирует взаимоотношения и коммуникацию внутри проектной группы; следит за временным графиком проекта и готовит отчетность о его состоянии; проводит в жизнь важные компромиссные решения; разрабатывает, поддерживает и исполняет сводный план и календарный график проекта; организует управление рисками
Отбраковка	Создание продукта в соответствии со спецификацией	Технологическое консультирование. Проектирование и осуществление реализации. Разработка приложений. Разработка инфраструктуры.	определяет детали физического дизайна; оценивает необходимые время и ресурсы на реализацию каждого элемента дизайна; разрабатывает или контролирует разработку элементов; подготавливает продукт к внедрению; консультирует команду по технологическим вопросам
Тестирование	Одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены	Планирование тестов. Разработка тестов. Отчетность по тестам.	обеспечивает обнаружение всех дефектов; разрабатывает стратегию и планы тестирования; осуществляет тестирование
Удовлетворение потребителя	Повышение эффективности пользователя, увеличение потребительской ценности продукта	Обеспечение технической поддержки. Обучение. Эргономика. Графический дизайн. Интернационализация. Общедоступность (обеспечение возможности работы для пользователей с ограниченными физическими возможностями).	представляет интересы потребителя в команде; организует работу с требованиями пользователя; проектирует и разрабатывает системы поддержки производительности; определяет компромиссы, относящиеся к удобству использования и потребительским качествам продукта; определяет требования к системе помощи и её содержание; разрабатывает учебные материалы и осуществляет обучение пользователей
Анализ рисков	Беспроблемное внедрение и сопровождение продукта	Инфраструктура. Сопровождение. Бизнес-процессы. Управление выпуском готового продукта.	представляет интересы отделов поставки и обслуживания продукта; организует снабжение проектной группы; организует внедрение продукта; вырабатывает компромиссы в управляемости и удобстве сопровождения продукта; организует сопровождение и инфраструктуру поставки; организует логистическое обеспечение проектной группы

 

Основные понятия положены в основу стандарта качества СММ?

 

Самым именитым стандартом качества следует считать Capability Maturity Model (CMM) – модель оценки уровня зрелости процессов разработки вместе с его производными.