2) Модели разработки - Часть 2

Распределение объемов работ (рабочие потоки каждой итерации - изображение)

схема =

подробнее о стадиях (этапах)читайте ниже

1) Этап начала проекта (Inception) = начальная стадия

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

Этап Inception может занимать около 10% времени и 5% трудоемкости одного цикла

Ход работ для этапа Inception на схеме=

2) Этап развития (Elaboration) = стадия Уточнения

(соответствует "стадии уточнения" на схеме по распределению объёмов работ выше)

Основная цель данного этапа — исходя из основных требований разработать стабильную базовую архитектуру продукта
Эта архитектура в дальнейшем используется как основа разработки системы
На этап проектирования может уходить около 30% времени и 20% трудоемкости одного цикл

Ход работ для этапа Elaboration на схеме =

3) Этап конструирования (Construction) = стадия Конструирования

Основная цель данного этапа — детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры
В результате должна получиться система, реализующая все выделенные варианты использования
На этот этап уходит около 50% времени и 65% трудоемкости одного цикла

Ход работ для этапа(стадия) Конструирование Construction на схеме =

4) Этап перехода (Transition) = стадия Внедрения

Цель данного этапа — сделать систему полностью доступной конечным пользователям
Здесь происходит развертывание системы в ее рабочей среде, бета-тестирование, подгонка мелких деталей под нужды пользователей.

На этап внедрения может уходить около 10% времени и 10% трудоемкости одного цикла

Ход работ для этапа(стадия) Transition представлен на схеме =

============

Артефакты рабочего потока

Каждый рабочий поток определяет набор связанных с ним артефактов

Артефакты, вырабатываемые в ходе проекта, могут быть представлены:

1. в виде баз данных и таблиц с информацией различного типа,
2. разных видов документов,
3. исходного кода и объектных модулей,
4. моделей, состоящих из отдельных элементов

Зависимости между артефактами представлены на схеме =

Модели RUP

Наиболее важные с точки зрения RUP артефакты проекта — это модели, описывающие различные аспекты будущей системы и представляемые наборами диаграмм UML

Виды моделей

Основными являются следующие виды моделей:

1. модель вариантов использования (Use-Case Model),
2. модель анализа (Analysis Model),
3. модель проектирования (Design Model),
4. модель реализации (Implementation Model),
5. модель тестирования (Test Model),
6. модель развертывания (Deployment Model)

Модель вариантов использования

Определяет требования к ПО в виде набора вариантов использования

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

Модель вариантов использования служит основой для проектирования и оценки готовности системы к внедрению

Модель анализа

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

Выделяемые классы разбиваются на три разновидности:

1. интерфейсные,
2. управляющие,
3. классы данных

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

Интерфейсные классы

Интерфейсные классы (boundary classes) соответствуют устройствам или способам обмена данными между системой и ее окружением, в том числе пользователями.

Классы данных

Классы данных (entity classes) соответствуют наборам данных, описывающих некоторые однотипные сущности внутри системы

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

Управляющие классы

Управляющие классы (control classes) соответствуют алгоритмам, реализующим какие-то значимые преобразования данных в системе и управляющим обменом данными с ее окружением в рамках вариантов использования

--------------

Роли классов

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

----------------

Модель проектирования

Является детализацией и специализацией модели анализа

Также состоит из классов, но более четко определенных, с более точным и детальным распределением обязанностей, чем классы модели анализа
Классы модели проектирования должны быть специализированы для конкретной используемой платформы

Используемая платформа может включать:

1. операционные системы;
2. языки программирования;
3. интерфейсы и классы конкретных компонентных сред (J2EE, .NET, COM или CORBA);
4. интерфейсы выбранных для использования СУБД (Oracle или MS SQL Server);
5. используемые библиотеки разработки пользовательского интерфейса (swing или swt в Java, MFC или gtk);
6. интерфейсы взаимодействующих систем и пр.

Модель реализации

Под моделью реализации в рамках RUP и UML понимают набор компонентов сборки результирующей системы и связей между ними

Компонент сборки — это минимальный по размерам кусок кода системы, который может участвовать или не участвовать в определенной ее конфигурации, единица сборки и конфигурационного управления

Связи между компонентами представляют собой зависимости между ними. Если компонент зависит от другого компонента, он не может быть поставлен отдельно от него
Часто компоненты представляют собой отдельные файлы с исходным кодом

Модель развертывания

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

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

1. серверами,
2. рабочими станциями,
3. принтерами,
4. контроллерами датчиков и пр.

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

Модель тестирования

В рамках этой модели определяются тестовые варианты или тестовые примеры (test cases) и тестовые процедуры (test scripts)
Тестовые примеры являются определенными сценариями работы одного или нескольких действующих лиц с системой, разворачивающимися в рамках одного из вариантов использования

Тестовый вариант

Тестовый вариант включает в себя:

1. входные данные на каждом шаге, где они могут быть введены;
2. условия выполнения отдельных шагов;
3. корректные ответы системы для всякого шага, на котором ответ системы можно наблюдать

В отличие от вариантов использования тестовый вариант обычно не имеет альтернативных сценариев

Тестовая процедура

Представляет собой способ выполнения одного или нескольких тестовых вариантов и их составных элементов (отдельных шагов и проверок)

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

=============================

Управление рисками в RUP

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

При разработке ПО неудовлетворительным результатом может быть:

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

Итерации и риски

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

Началу следующей итерации предшествует пересмотр и новая оценка рисков

Показатель риска

Для ранжирования рисков по степени значимости используют величину показатель риска RE (Risk Exposure) , которая
определяется по формуле =

	RE=P*L

где =

• P – вероятность неудовлетворительного результата
• L – потеря при получении неудовлетворительного результата

Для оценки потерь обычно вводят 10 или 100-балльную шкалу

Управление рисками

Управление рисками Включает 6 действий:

1. идентификация риска – выявление риска в проекте;
2. анализ риска – оценка вероятности и величины потери;
3. ранжирование рисков – упорядочение по степени влияния;
4. планирование управления рисками – подготовка к работе с каждым риском;
5. разрешение риска – устранение риска;
6. наблюдение рисков – отслеживание динамики изменения рисков, выполнение корректирующих действий

Выбор модели разработки

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

Выбор модели определяется:

1. объемом и сложностью проекта;
2. количеством и качеством команды разработчиков
3. квалификацией заказчика, его способностью обеспечить достаточно четкую постановку задачи

Руководство проектом

Руководство проектом определяет сущность процесса разработки от его начала до конца. Оно обеспечивает :

1. оценку объема предстоящих работ
2. оценку требуемых ресурсов
3. оценку возможных рисков
4. составляет или корректирует план работ
5. определяет первоочередные задачи
6. устанавливает вехи – точки контроля промежуточных результатов

Начало проекта

В начале работы над проектом необходимо:

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

Процесс оценки

Оценка объема предстоящих работ производится в человеко-месяцах

Исходя из нее определяют необходимые ресурсы:

1. продолжительность работ (в календарных датах)
2. число разработчиков
3. стоимость (в тыс. рублей)

При оценках используется опыт предыдущих собственных разработок, либо опыт других разработчиков

Анализ рисков

Риском называется возможная потеря в процессе разработки. Это может быть=

1. потеря качества продукта,
2. рост затрат на разработку,
3. отставание от графика и т.д.

Задачей руководства является анализ возможных рисков и планирование мер по минимизации их влияния на выполнение разработок.

Планирование процесса разработки

Основная задача планирования – определение структуры распределения работ. Типовая структура распределения работ включает:

1. системный анализ
2. анализ требований
3. предварительное проектирование
4. разработку модулей
5. тестирование интеграции
6. аттестацию продукта

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

1) Системный анализ

Проводится с целью:

1. выяснения потребностей заказчика
2. оценки реализуемости системы
3. экономического и технического анализа
4. распределения функций по элементам системы (аппаратура, программы, базы данных, люди)
5. определения стоимости и ограничений планирования

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

Анализ требований

Имеет своей целью:

1. определить функции и характеристики программного продукта
2. обозначить его интерфейс с другими системными элементами
3. определить проектные ограничения программного продукта
4. построить модели режимов функционирования продукта
5. выбрать формы представления информации в ходе проектирования

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

Границы времени выполнения

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

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

Распределение времени выполнения

Рекомендуемое распределение времени выполнения проекта:

1. на анализ и проектирование 40% временных затрат (из них 5% на анализ и планирование)
2. на кодирование – 20%
3. на тестирование и отладку – 40%

-----------------------

Оценки, меры и метрики

• Для оценки различных свойств процесса создания программного продукта, а также и самого продукта, применяются количественные характеристики, называемые мерами
• Путем непосредственного измерения определяются опорные свойства.
• Остальные свойства оцениваются путем вычисления функций от опорных значений. Такие функции называются метриками.

Размерно-ориентированные метрики

Размерно-ориентированные метрики Основаны на LOC-оценках, т.е. на количестве строк в текстах программ (Lines Of Code (LOC)). К числу размерно-ориентированных метрик относятся:

1. производительность
2. качество
3. удельная стоимость
4. документированность

Метрики производительности и качества

Метрики производительности и качества рассчитываются в виде следующих отношений:

Производительность =

Производительность = 	 [число строк кода(LOC)]	/[Затраты]

где затраты измеряются в человеко-месяцах (работа одного человека в течении месяца)
Качество =

Качество = [число ошибок] / [число строк кода(LOC)]

Метрики стоимости и документированности

Удельная Стоимость = [Стоимость в тыс. рублей] / [число строк кода(LOC)]
_________
Документированность = [число страниц документации] / [число строк кода(LOC)]

Достоинства и недостатки Размерно-ориентированные метрик

Достоинства:

1. основаны на объективных данных
2. просты и легко вычислимы

Недостатки:

1. зависят от языка программирования
2. трудновыполнимы на начальной стадии проекта
3. не приспособлены к непроцедурным языкам программирования

-------------------

Функционально-ориентированные метрики (FP-оценки)

Исходят не из размера программного продукта, а из его функциональности.
Оценивают:

1. характер пользовательского интерфейса
2. сложность выполняемой обработки
3. распространенность используемой конфигурации
4. степень сложности инсталляции
5. условия эксплуатации
6. степень модифицируемости

FP-оценки

Вместо количества строк в текстах используется количество функциональных указателей (Function Points)
следующая формула взята из слайдов лекций=

FP=UI*(0.65+0.01*E[F(i)])

где =

1. UI - оценка сложности пользовательского интерфейса,
2. F(i) ("эф итое") – коэффициенты регулировки сложности, основанные на эмпирической оценке ряда системных параметров и принимающие целые значения в диапазоне от 0 до 5.
3. E[F(i) - сумма всех коэффициентов по i параметру.

FP-оценки
К числу параметров, учитываемых коэффициентами регулирования сложности относятся:

1. объем используемых средств передачи данных
2. степень распределенности обработки
3. степень распространенности используемой аппаратной платформы
4. степень жесткости требований к производительности
5. частота выполнения транзакций

FP-оценки

1. Кроме того учитываются:
2. процент информации, вводимой в режиме on-line
3. сложность обработки данных, наличие значительной логической и математической обработки
4. легкость инсталляции
5. степень переносимости
6. степень модифицируемости

Область применения метода функциональных указателей ((Function Points) – коммерческие информационные системы

Для продуктов с высокой алгоритмической сложностью (системного и встроенного ПО, ПО реального времени) используется метод указателей свойств (Features Points).
При расчете указателя свойств учитывается количество используемых в ПО алгоритмов

Функционально-ориентированные метрики

Функционально-ориентированные метрики аналогичны соответствующим размерно-ориентированным метрикам с точностью до замены =

• параметра длины на количество функциональных указателей
• или параметра длины на указатель свойств в зависимости от выбранного метода FP-оценки

Достоинства и недостатки Функционально-ориентированных метрик

Достоинства:

1. не зависят от выбора языка программирования
2. вычисляются на любой стадии проекта

Недостатки:

1. используют не прямые, а косвенные измерения
2. основаны на субъективных оценках

Конец лекции