Уровень 4, управляемый (manageable)

 В этих организациях, помимо установленного и описанного процесса, используются измеримые показатели качества продуктов и результативности процессов, которые позволяют достаточно точно предсказывать объем ресурсов (времени, денег, персонала), необходимый для разработки продукта с определенным качеством

Уровень 5, совершенствующийся (optimizing)

Билет

1. Прогностические модели процесса разработки: каскадная, RAD, спиральная.

Ответ

прогнозирующие ( тяжеловесным ) процессы разработки ПС предполагают планирование всего объема работ и, соответственно, достаточно большой объем документации Основная цель таких процессов –отделить успешные практики разработки и сопровождения ПО от конкретных людей, умеющих их применять

 Спиральная модель определяет четыре действия:

-Планирование(заключается в определении целей очередной итерации процесса разработки, выборе вариантов решения и оценки ограничений)

-анализ рисков(анализ вариантов решения и оценка связанных с ними рисков, т.е. возможностей получения неудовлетворительных результатов)

-конструирование(это основное действие, заключающееся в создании следующей версии ПО)

-оценивание.( оценка заказчиком качества очередной версии ПО, внесение им предложений по модификации продукта, корректировка требований)

Данная модель отображает процесс разработки ПО в наиболее реальном виде; позволяет явно учитывать риски на каждом витке эволюционного процесса и принимать различные управленческие решения вплоть до прекращения работ

Недостатки модели:

-повышенные требования к заказчику;

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

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

Набор документов, созданный на предыдущем этапе, передается в качестве входных данных для следующего этапа

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

-упорядоченность процесса разработки

-возможность его строгого планирования во времени.

Недостатки модели:

-необходимость точной и полной формулировки требований к ПС перед началом разработки

-невозможность изменения решений, принятых на предыдущих этапах

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

RAD-модель Модель быстрой разработки приложений..

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

Ее основной недостаток заключается в наличии риска увеличения срока разработки из-за подготовки большого числа версий

Предполагает выделение в системе нескольких основных бизнес-функций и разработку каждой из них отдельной группой разработчиков с последующей интеграцией в целую систему

RAD-модель используется при работе с мощными инструментальными средствами разработки – визуальными средами проектирования и программирования.

Основным достоинством модели является уменьшение сроков разработки

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

Билет

Адаптивные модели процесса разработки: экстремальное программирование, Scrum.

Ответ

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

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

Экстремальное программирование ( XP-процесс) адаптивная модель- ориентирован на группы малого и среднего размера, разрабатывающих ПС в условиях неопределенных или быстро меняющихся требований

Основная идея XP- процесса – устранить высокую стоимость внесения изменений. Это достигается путем резкого (до двух недель) сокращения длительности отдельных итераций.

Базовыми действиями являются:

-кодирование,

-тестирование,

-выслушивание заказчика,

-проектирование

Принципы разработки:

-непрерывная связь с заказчиком,

-простота выбираемых решений,

-быстрая обратная связь на основе оперативного тестирования,

-профилактика рисков

Реализация этих принципов достигается за счет использования следующих методов:

Метафора – вся разработка ведется на основе простой, общедоступной истории о том, как работает система

Простое проектирование – принимаются наиболее простые из возможных проектные решения

Непрерывное тестирование как отдельных модулей, так и системы в целом; входным критерием для написания кода является отказавший тестовый вариант

Реорганизация ( Refactoring ) – улучшение структуры системы при сохранении ее поведения

Парное программирование – код пишется двумя программистами на одном компьютере

Коллективное владение кодом – любой разработчик может улучшить код любого модуля системы

Непрерывная интеграция – система интегрируется как можно чаще; непрерывное регрессионное тестирование гарантирует сохранение функциональности при изменении требований

Локальный заказчик – в группе все время должен находиться компетентный представитель заказчика

Стандарты кодирования – должны выдерживаться правила, обеспечивающие одинаковое представление кода во всех частях системы

Scrum-модель пример адаптивного процесса разработки

Основная идея: Экспериментальный факт: проекты, над которыми работают небольшие, кросс-функциональные команды

Главные действующие роли:

- ScrumMaster, тот кто занимается процессами и работает в качестве руководителя проекта,

- Владелец Продукта, человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон,

- Команда, которая включает разработчиков

Процесс разработки разбивается на отдельные этапы определенной длительности – спринты (обычно, 15-30 дней) 

Каждому спринту предшествует этап, который называется product backlog –документирование запросов на выполнение работ

Планирование спринта Запросы на выполнение работ определяются на этапе совета по планированию спринта

На протяжении этого собрания Владелец Продукта информирует о заданиях, которые должны быть выполнены

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

Во время спринта команда выполняет определенный фиксированный список заданий - backlog items, наращивая функциональность программного продукта

На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать, как заморозку требований (requirements) во время спринта

Билет

1. Руководство программным проектом. Предварительные оценки проекта. Системный анализ и анализ требований. Анализ рисков. Планирование процесса разработки. Типовая структура распределения работ.

Ответ

Начало проекта

Перед планированием проекта следует:

· установить цели и проблемную область проекта;

· обсудить альтернативные решения;

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

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

Процесс оценки. При планировании программного проекта надо оценить людские ресурсы, продолжительность (в календарных датах), стоимость

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

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

Трассировка и контроль

 

Билет

1. Анализ предметной области: цели и задачи. Модели предметной области. Формальные определения. Классификация моделей.
2. Методология IDEF0, синтаксис IDEF0-моделей.

Ответ

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

Анализ предметной области – это первый шаг этапа системного анализа, с которого начинается разработка программной системы.

В результате

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

- выявить цели их деятельности;

- определить набор решаемых ими задач;

-определить набор сущностей, с которыми приходится иметь дело при решении этих задач

Модели предметной области

Анализом предметной области занимаются системные аналитики или бизнес-аналитики

Они передают полученные ими знания другим членам проектной команды, сформулировав их на более понятном разработчикам языке

Для передачи этих знаний обычно служит некоторый набор моделей, в виде графических схем и текстовых документов 

Под системой подразумевается совокупность взаимодействующих компонентов и взаимосвязей между ними

Моделью M некоторой системы S называется информационный объект, который может быть использован для получения ответов на некоторый круг вопросов относительно S

Характеристики модели

К ним относятся:

-цель моделирования,

-объект моделирования,

-точка зрения модели,

-средство моделирования

Модель должна быть адекватна целям и объекту моделирования

Цель моделирования

-Получение ответов на эту совокупность вопросов

-Цель моделирования формулируется на самом раннем этапе разработки модели

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

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

Виды моделей

Формальные модели, используемые на этапе анализа предметной области можно разделить на две группы:

-модели, зависящие от подхода к разработке (структурного или объектно-ориентированного)

-модели, не зависящие от подхода к разработке

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

Объектный подход

В основе объектного подхода к разработке программного обеспечения лежит объектная декомпозиция, предполагающая объединение процедур и структур данных

процедуры + структуры данных = классы

Классификация моделей

◦ . IDEF0 – методология создания функциональной модели системы (основана на методе SADT Росса);

Синтаксис IDEF0-моделей

Основной формой представления IDEF0-модели является диаграмма

Каждая IDEF0-диаграмма содержит блоки (работы) и дуги (стрелки).

◦ Блоки изображают функции моделируемой системы.

◦ Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними.

Функциональные блоки на диаграмме изображаются прямоугольниками, а дуги – стрелками 

⇐ Предыдущая123456789Следующая ⇒

Поделиться: