Презентация на тему Сопровождение программных средств на основе технологии RUP

совокупность взаимосвязанных технологических процессов в рамках ЖЦ ПО.
Технологический процесс

– это совокупность взаимосвязанных технологических операций.

определенной ролью, которая:
• подразумевает четко определенную ответственность роли;
• дает

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

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

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

конфигурацией и изменениями;
тестирование;
управление проектом.

применения;
поддержка поставщика;
простота использования;
удовлетворительные стоимостные характеристики.

ответных мер. В начале каждой стадии ЖЦ составляется список

рисков (примеры: неосвоенная СП, интеграция с унаследованным кодом, орг. проблемы). По каждому риску из списка составляется перечень ответных мер. RUP учитывает изменчивость рисков – на разных этапах проекта списки рисков разные.
Выполнение требований заказчиков. Требования описываются вариантами использования. Варианты использования – это отправная точка создания для модели анализа и проектной модели. Планирование и управление проектом ведется на основе вариантов использования. Варианты использования являются «сырьем» для тестов и пользовательской документации.

тому, какая часть системы готова и работает. Практика –

лучший критерий проверки правильности того или иного решения. Все рабочие продукты проекта за исключением работающего кода являются вспомогательными, поэтому не следует слепо их создавать лишь из-за того, что они указаны в руководствах по RUP.
Готовность к изменениям с самого начала проекта и управление ими. Система слишком сложна, чтобы с самого начала получить верное и окончательное проектное решение. Изменения позволяют улучшать принятые решения. Итеративный процесс позволяет исправлять дефекты, допущенные на ранних итерациях. Стоимость изменений в ходе проекта увеличивается. Управление изменениями позволяет уложиться в бюджет и сроки.

преимуществами инкапсуляции: повышает модифицируемость системы и возможности повторного использования

ее частей. Стоимость разработки системы может быть снижена за счет использования компонентных платформ (J2EE, NET).
Визуальное моделирование. Графические модели более наглядны и удобны, чем тексты на естественных и формальных языках. UML – стандартный язык, так что модели понятны большой аудитории (состоящей не только из людей, но и из CASE-средств). По той же причине имеется больше возможностей для повторного использования моделей.
Обеспечение качества в течение всего ЖЦ. Используется упреждающее тестирование, лозунг которого: «Тесты раньше программ!» Регрессионное тестирование и первоочередная реализация приоритетных вариантов использования обеспечивают надежность ключевой функциональности системы. Качество создается в течение всего жизненного цикла за счет того, что все рабочие продукты критически оцениваются при рецензировании.

ввода в действие (transition).

80%);
перечень дополнительных требований, включая требования нефункционального характера и требования,

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

продукта, готовая к передаче конечным пользователям. В её составе

содержится как минимум следующее:

ПО, интегрированное на требуемых платформах;
Руководства пользователя;
Описание текущей реализации.

эксплуатационной версии и передача готового продукта в распоряжение пользователей.

Данная стадия включает:

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

роли;
• виды работ;
• рабочие продукты;
• дисциплины (процессы).

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

играть в проекте много различных ролей.
Вид работы – технологическая операция, выполняемая конкретным исполнителем.
Дисциплина (discipline) соответствует понятию технологического процесса (или процесса ЖЦ) и представляет собой последовательность работ, приводящую к получению значимого результата.

требований;
анализ и проектирование;
реализация;
тестирование;
развертывание;

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

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

бизнеса;
глоссарий деятельности предприятия;
модель бизнес-процессов (описывающая контекст бизнеса и бизнес-процессы

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

координирующий работу по деловому моделированию, отвечающий за модель бизнес-процессов;
бизнес-проектировщик,

моделирующий отдельные бизнес-процессы под руководством бизнес-аналитика (результатом совместной работы бизнес-проектировщиков является модель бизнес-анализа).
Полученные модели предприятия служат основой для моделей требований и анализа.

система, и убедиться во взаимопонимании по этому поводу между

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

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

системы, дополнительной спецификации, отражающей нефункциональные требования.

вариантов использования,
рецензент по требованиям,
разработчик пользовательского интерфейса.

на основе требований, убедиться, что данная архитектура может быть

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

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

вариантов использования, начальная версия модели развёртывания.

БД,
разработчик систем реального времени,
разработчик пользовательского интерфейса,
технический рецензент.

кода системы, разработать код ее компонентов и протестировать их,

интегрировать систему в работающее целое.

к модели реализации, представленной в виде диаграмм компонент и

диаграмм пакетов).
Выработку плана сборки для каждой итерации.
Распределение компонентов системы по узлам вычислительной среды.
Реализацию кода классов и подсистем.
Покомпонентное тестирование.

проектных классов, пакетов и подсистем в компоненты и установлении

связей (зависимостей) между компонентами.

в билде (сборке) и те компоненты, которые входят в

билд. Планы составляет системный интегратор.

это раздельное тестирование компонент системы. Осуществляет его кодировщик путем

тестирования на основе спецификации («черный ящик») и/или тестирования на основе структуры («белый ящик»).

уточненное описание архитектуры, записи ревью, тесты и их результаты.

системы (проявления недостатков ее качества),
оценить ее качество в целом,
оценить

выполнены или нет гипотезы, лежащие в основе проектирования,
оценить степень соответствия системы требованиям.

вариантов (test-case) и тестовых сценариев (test scripts).
Тестирование с целью

обнаружения дефектов.

системы для всякого шага, на котором ответ системы можно

наблюдать.

наборов в рамках тестового варианта. Выполняется вручную или автоматически.