4 Фазы rup:
1. Фаза начала проекта.
Цель - достичь компромисса между всеми заинтересованными лицами относительно задач проекта. На этой фазе определяются основные цели, руководитель, бюджет проекта, а также основные средства выполнения проекта – технологии, инструменты, ключевой персонал. На этом этапе может производиться проба выбранных технологий с целью подтверждения возможности достичь цели с их помощью, составляются предварительный план проекта. На эту фазу уходит около 10% времени и 5% трудоемкости одного цикла.
2. Фаза проработки.
Цель - на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру проекта, которая позволяет решать поставленную перед системой задачу, и в дальнейшем используется как основа разработки системы. На эту фазу может уходить 30% времени и 25% трудоемкости одного цикла.
3.Фаза построения.
Цель - детальное построение требований и разработка системы удовлетворяющей им на основе спроектированной ранее архитектуры В результате должна получиться система, реализующая все выделенные варианты использования. Уходит 50 % времени и 65% трудоемкости одного цикла.
4.Фаза передачи.
Цель- сделать систему доступной конечному пользователю. Здесь происходит окончательное развертывание системы в ее рабочей среде, подгонка мелких деталей под нужды пользователей. Уходит 10% времени и 10% трудоемкости одного цикла.
Дать определение Модели вариантов использования (Use-Case Model), Модель анализа (Analysis Model), как они соотносятся между собой, привести разновидности классов этих моделей. Кто такие актеры?
Сценарий использования, вариант использования, прецедент использования (use case) — в разработке программного обеспечения и системном проектировании это описание поведения системы, когда она взаимодействует с кем-то (или чем-то) из внешней среды. Система может отвечать на внешние запросы Актёра (англ. actor) (может применяться термин Актант), может сама выступать инициатором взаимодействия. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой системой, или что система может сделать с «кем» или «чем». Методика сценариев использования применяется для выявления требований к поведению системы, известных также как пользовательские и функциональные требования.
Актёр— множество логически связанных ролей в UML, исполняемых при взаимодействии с прецедентами или сущностями (система, подсистема или класс). Актёром может быть человек или другая система, подсистема или класс, которые представляют нечто вне сущности.
Прецедент (use-case) - описание отдельного аспекта поведения системы с точки зрения пользователя (Буч).
Прецедент (use case) - описание множества последовательных событий (включая варианты), выполняемых системой, которые приводят к наблюдаемому эктором результату. Прецедент представляет поведение сущности, описывая взаимодействие между экторами и системой. Прецедент не показывает, "как" достигается некоторый результат, а только "что" именно выполняется.
Анализ требований — часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению (ПО), их систематизацию, выявление взаимосвязей, а также документирование. В англоязычной среде также говорят о дисциплине «инженерия требований» (англ. Requirements Engineering). В процессе сбора требований важно принимать во внимание возможные противоречия требований различных заинтересованных лиц, таких как заказчики, разработчики или пользователи.
Полнота и качество анализа требований играют ключевую роль в успехе всего проекта. Требования к ПО должны быть документируемые, выполнимые, тестируемые, с уровнем детализации, достаточным для проектирования системы. Требования могут быть функциональными и нефункциональными.
Анализ требований включает три типа деятельности:
Сбор требований — общение с клиентами и пользователями, чтобы определить, каковы их требования; анализ предметной области.
Анализ требований — определение, являются ли собранные требования неясными, неполными, неоднозначными или противоречащими; решение этих проблем; выявление взаимосвязи требований.
Документирование требований — требования могут быть задокументированы в различных формах, таких как простое описание, сценарии использования, пользовательские истории, или спецификации процессов.
Анализ требований может быть длинным и трудным процессом, во время которого вовлечены много тонких психологических навыков. Новые системы изменяют окружающую среду и отношения между людьми, поэтому важно определить все заинтересованные лица, принять во внимание все их потребности и гарантировать, что они понимают значения новых систем. Аналитики могут использовать несколько методов, чтобы выявить следующие требования от клиента: проведение интервью, использование фокус-групп или создание списков требований. Более современные методы включают создание прототипов и сценариев использования. Где необходимо, аналитик будет использовать комбинацию этих методов, чтобы выявить точные требования заинтересованных лиц так, чтобы была создана система, которая удовлетворяет деловые потребности.
Унифицированный процесс разработки и экстремальное программирование.Что такое модель реализации в рамках RUP и UML, дать определение компонента. Определить модель развертывания и модель тестирования.
Модель реализации в рамках RUP и UML — набор компонентов результирующей системы и связей между ними.
Компонент — минимальный по размерам кусок кода системы, который может участвовать или не участвовать в данной конфигурации, единица конфигурационного управления.
Модель развертывания — набор узлов системы, являющихся физически отдельными устройствами, способными обрабатывать информацию — серверами, рабочими станциями, принтерами, контроллерами датчиков и пр., со связями между ними, образованными различного рода сетевыми соединениями.
Модель тестирования — определение тестовых вариантов или тестовых примеров и тестовых процедур.
Тестовые варианты — определенные сценарии работы одного или нескольких действующих лиц с системой, разворачивающимися в рамках одного из вариантов использования.
Тестовая процедура представляет собой способ выполнения одного или нескольких тестовых вариантов и их составных элементов (отдельных шагов и проверок).
Основными понятиями и задачами моделирования предметной области (оно же бизнес-моделирование) являются:
Задача – понять предметную область или бизнес-контекст, для которого разрабатывается ПО, выяснить, как контекст воспринимается участниками взаимодействий, выявление имеющихся проблем и их возможное разрешение, последствия этих проблем для организации, которая будет пользваться разрабатываемым ПО.
Результатом моделирования предметной области появляется её представление в виде набора диаграмм классов (объекты предметной области) и диаграмм взаимодействий, диаграмм деятельностей (представляют бизнес-операции и бизнес-процессы).
Если по-простому, модель предметной области представляется в виде описанных классов, отражающих участников реальных процессов, и диаграммы деятельностей, по-сути, схемы событий и действий, которые происходят в системе.
Должна быть адекватной моделью бизнес-процесса.
Далее более подробно.
Операция – элементарное (неделимое) действие, выполняемое на одном рабочем месте.
Функция – совокупность операций, сгруппированных по определенному признаку.
Бизнес-процесс — связанная совокупность функций, в ходе выполнения которой потребляются определенные ресурсы и создается продукт (предмет, услуга, научное открытие, идея), представляющая ценность для потребителя.
Подпроцесс – это бизнес-процесс, являющийся структурным элементом некоторого бизнес-процесса и представляющий ценность для потребителя.
Бизнес-модель – структурированное графическое описание сети процессов и операций, связанных с данными, документами, организационными единицами и прочими объектами, отражающими существующую или предполагаемую деятельность предприятия.
Язык моделирования – это нотация, в основном графическая, которая используется для описания проектов. Нотация представляет собой совокупность графических объектов, используемых в модели. Нотация является синтаксисом языка моделирования . Язык моделирования, с одной стороны, должен делать решения проектировщиков понятными пользователю, с другой стороны, предоставлять проектировщикам средства достаточно формализованного и однозначного определения проектных решений, подлежащих реализации в виде программных комплексов, образующих целостную систему программного обеспечения.
Состоит из: