Методология разработки ИС. Унифицированный процесс

Унифицированный процесс был разработан Филиппом Крачтеном (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+. Функциональные и

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

Системы.

Требования (requirements):

· подробное описание того, что должно быть реализовано

· возможности или условия, которым должна соответствовать система или проект

Выработка требований (requirements engineering) —

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

Виды (FURPS+)

• функциональные: свойства, возможности, безопасность

• удобство: человеческий фактор, справочная система, документация

• надежность: частота сбоев, возможность восстановления

• производительность

возможность поддержки: адаптивность, соответствие стандартам, конфигурирование

• реализация: ресурсы, языки и средства, аппаратное обеспечение

• интерфейс: взаимодействие с внешними системами

• операции: управление системой и ее параметры

• юридические вопросы

 

Треб: