Методология разработки ИС. Унифицированный процесс
Унифицированный процесс был разработан Филиппом Крачтеном (Philippe Kruchten), Иваром Якобсоном (Ivar Jacobson) и другими сотрудниками компании “Rational Software” в качестве дополнения к языку моделирования UML. RUP представляет собой каркас для процессов, и таким образом, включает в себя огромное их количество. Основной идеей унифицированного процесса является разбиение процесса разработки на короткие итерации фиксированной длительности, а также обеспечение ее адаптивности и эволюционности. К числу других важных принципов и концепций унифицированного процесса относят следующие. Оценка рисков и ключевых моментов проекта на ранних итерациях. Постоянный отклик пользователей, обратная связь и модификация требований. Построение общей базовой архитектуры на ранних итерациях. Постоянный контроль качества, раннее и частое тестирование в реальных условиях. Визуализация программной модели. Внимательное управление требованиями. Обработка запросов на внесение изменений и управление конфигурацией.
Как уже отмечалось, RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получитьпромежуточную, но функциональную версию конечного продукта. Полный жизненный цикл разработки продукта состоит из четырех фаз, каждая из которых включает в себя одну или несколько итераций: Начало (Inception) На этом этапе: формируются видение и границы проекта; создается экономическое обоснование (business case); определяются основные требования, ограничения и ключевая
функциональность продукта; создается базовая версия модели прецедентов; оцениваются риски. Проектирование (Elaboration; Уточнение, Развитие) документирование требований (включая детальное описание для большинства прецедентов); проектирование, реализацию и тестирование исполняемой архитектуры; обновление экономического обоснование и более точные оценки сроков и стоимости; снижение основных рисков (за счет, например, создания наиболее критичных компонентов). Конструирование (Construction) Внедрение (Transition) Унифицированный процесс предполагает выполнение различных видов деятельности в рамках определенных дисциплин. Дисциплина (discipline) — это набор видов деятельности (и связанных с ним артефактов) в рамках одного этапа, например в рамках анализа требований. В контексте унифицированного процесса артефактом (artifact) называется любой результат работы: код, графическое изображение для веб, схема базы данных, текстовые документы, диаграммы, модели и т. д. В рамках унифицированного процесса существует несколько дисциплин. В этом курсе внимание будет сосредоточено на некоторых артефактах следующих четырех дисциплин. Бизнес-моделирование (Business Modeling). Эта дисциплина подразумевает разработку модели предметной области, которая является визуальным представлением наиболее важных сущностей из предметной области и их взаимосвязей. Требования (Requirements). В рамках этой дисциплины создается модель прецедентов и дополнительная спецификация. В этих двух артефактах отражаются функциональные и нефункциональные требования. Проектирование (Design). Сюда относится модель проектирования, которая отражает программные объекты. Реализация (Implementation) Язык UML. Способы использования UML. Model Driven Architecture. Executable UML. Диаграммы UML.
UML (Unified Modeling Language): · универсальный язык визуального моделирования систем · визуальный язык для определения, конструирования и документирования артефактов систем. Поддерживается OMG (Object Management Group) Способы использования: · для черновиков · для создания проектной документации · в качестве языка программирования Model Driven Architecture Model Driven Architecture (MDA) — архитектура, управляемая моделью. Executable UML Диаграммы UML · диаграммы структуры (structure diagrams) o классов (Class) o составных структур (Composite structure) (декомпозиция класса во время исполнения) o компонентов (Component) o развертывания (Deployment) o объектов (Object) o пакетов (Package) · диаграммы поведения (Behavior) o деятельности (Activity) o состояний (State Machine) o прецедентов (Use Case) o взаимодействия (Interaction) § последовательности (Sequence) § коммуникационная (Communication) § временная (Timing) § обзора взаимодействий (Interaction Overview) 11. Анализ требований. Модель требований FURPS+. Функциональные и
Воспользуйтесь поиском по сайту: ©2015 - 2024 megalektsii.ru Все авторские права принадлежат авторам лекционных материалов. Обратная связь с нами...
|