Папиллярные узоры пальцев рук - маркер спортивных способностей: дерматоглифические признаки формируются на 3-5 месяце беременности, не изменяются в течение жизни...
Кормораздатчик мобильный электрифицированный: схема и процесс работы устройства...
Топ:
Техника безопасности при работе на пароконвектомате: К обслуживанию пароконвектомата допускаются лица, прошедшие технический минимум по эксплуатации оборудования...
Основы обеспечения единства измерений: Обеспечение единства измерений - деятельность метрологических служб, направленная на достижение...
Комплексной системы оценки состояния охраны труда на производственном объекте (КСОТ-П): Цели и задачи Комплексной системы оценки состояния охраны труда и определению факторов рисков по охране труда...
Интересное:
Инженерная защита территорий, зданий и сооружений от опасных геологических процессов: Изучение оползневых явлений, оценка устойчивости склонов и проектирование противооползневых сооружений — актуальнейшие задачи, стоящие перед отечественными...
Принципы управления денежными потоками: одним из методов контроля за состоянием денежной наличности является...
Что нужно делать при лейкемии: Прежде всего, необходимо выяснить, не страдаете ли вы каким-либо душевным недугом...
Дисциплины:
2019-06-06 | 225 |
5.00
из
|
Заказать работу |
|
|
Сдвиг важности каждого потока работ в течении итераций и фаз процесса разработки
Проверка команды с помощью итеративного подхода
· Тенденция переходить к написанию кода. Строки кода – то, что менеджеры способны сосчитать.
· Сопротивление изменениям. Изменения замедляют написание кода.
· Нет заинтересованности в многократном использовании анализа, проекта или кода. Возможно, потому что работу оценивают по написанию нового кода.
Изменение:
· Теперь основное:
o Уменьшение рисков
o Создание фундамента архитектуры
o Реализация функциональности
· Прогресс изменяется в рисках, прецедентах, и компонентах, реализующих прецедент.
Последствия итеративного подхода
Для создания бизнес-плана в фазах анализа и определения требований, необходимо снижать риски и создание демонстрационной версии системы.
Для создания законченного бизнес-плана в конце фазы Elaboration организация должна быть уверена, что не осталось невыясненных рисков и спланировать дальнейшие действия исходя из существующего фундамента архитектуры и требований к системе.
Для минимизации затрат организация должна использовать многократно используемые компоненты полученные в результате ранней разработки архитектуры.
Для избегания задержки разработки и роста цены разработки организация должна делать сначала сложные вещи.
Для избегания устаревания продукта к моменту выхода на рынок организация должна соглашаться на внесение изменений в систему.
Разбитый на фазы Итеративный подход позволяет вносить изменения в течение всего времени разработки системы.
Типовая итерация
· Исполнители и артефакты могут участвовать более чем в одном потоке работ.
|
Например, разработчик компонент (component engineer) участвует в потоках работ по анализу, проектированию и реализации.
· После завершения итерации
o Регрессионное тестирование
o Оценка изменений требований
o Оценка появления новых требований
4. Поток работ для получения требований к системе. Получение требований к разрабатываемой системе. Проблемы, возникающие при получении требований к системе. Цели потока работ на этапе получения требований. Роль требований в жизненном цикле программного обеспечения. Понимание контекста системы с использованием модели предметной области. Понимание контекста системы с использованием бизнес - модели. Дополнительные требования.
Сбор требований к системе, как построение модели прецедентов использования системы
Основная задача потока работ по определению требований – построение модели прецедентов использования системы.
Функциональные требования структурируются на прецеденты использования.
Нефункциональные требования привязываются к конкретным прецедентам использования системы.
Общие для нескольких прецедентов нефункциональные требования выделяются в отдельный документ, называемый дополнительные требования (supplementary requirements).
Построение модели прецедентов
Построение модели прецедентов требует от системного аналитика привязывать функциональность системы к конкретному пользователю системы – актеру (actor).
Требует от системного аналитика выявлять категории пользователей системы – актеров.
Какие задачи (прецеденты использования должна выполнить система для конкретных категорий пользователей).
Затем построенная модель прецедентов управляет всей разработкой.
5. Поток работ для получения требований к системе как сценариев использования системы.
Артефакты: Модель сценариев использования; Актер; Сценарий использования; Описание архитектуры; Глоссарий; Прототип интерфейса пользователя.
Участники: Системный аналитик; Спецификатор сценариев использования; Проектировщик интерфейса пользователя; Архитектор
|
Деятельности: Поиск актеров и сценариев использования; Определение приоритетов для сценариев использования; Детализация сценариев использования; создание прототипа интерфейса пользователя; Структурирование модели сценариев использования;
Схема описания потока работ
· Описание артефакта: артефакт – общий термин для любого вида информации (создаваемой, изменяемой, используемой) исполнителями (workers) при работе по созданию системы.
· Описание исполнителя (worker) – сотрудника фирмы, участник потока работ. Обозначение роли, которая может быть поручена одному человеку или группе лиц имеющих для этого соответствующие навыки.
· Описание деятельности (activity) – часть работы за выполнение которой отвечает исполнитель в потоке работ и имеет результат в виде набора артефактов.
Исполнители и артефакты
Модель прецедентов
Позволяет разработчикам системы договориться с заказчиками и пользователями системы о требованиях к разрабатываемой системе.
Позволяет заключить соглашение (контракт) на разработку системы.
Структурировать требования на пакеты содержащие прецеденты и диаграммы прецедентов.
Модель прецедентов – исходная модель для построения моделей анализа, проектирования, реализации, тестирования.
Актер
Модель прецедентов описывает действия системы для каждой категории пользователей – актеров.
Актером может быть внешняя программная система.
Актером может быть внешнее устройство: часы, телефонная карта, …
Актерами могут быть сотрудники или клиенты фирмы, для которой разрабатывается система. И сотрудники, и клиенты могут быть взяты из бизнес-модели.
Примеры артефактов – актеров
Примеры артефактов – актеров и прецедентов
Примеры отношений прецедентов
|
|
Механическое удерживание земляных масс: Механическое удерживание земляных масс на склоне обеспечивают контрфорсными сооружениями различных конструкций...
Типы оградительных сооружений в морском порту: По расположению оградительных сооружений в плане различают волноломы, обе оконечности...
Биохимия спиртового брожения: Основу технологии получения пива составляет спиртовое брожение, - при котором сахар превращается...
История развития пистолетов-пулеметов: Предпосылкой для возникновения пистолетов-пулеметов послужила давняя тенденция тяготения винтовок...
© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!