- •Введение
- •От издательства
- •Глава 1. Организация процесса конструирования
- •Определение технологии конструирования программного обеспечения
- •Классический жизненный цикл
- •Макетирование
- •Стратегии конструирования по
- •Инкрементная модель
- •Быстрая разработка приложений
- •Спиральная модель
- •Компонентно-ориентированная модель
- •Тяжеловесные и облегченные процессы
- •Модели качества процессов конструирования
- •Контрольные вопросы
- •Глава 2. Руководство программным проектом
- •Процесс руководства проектом
- •Начало проекта
- •Измерения, меры и метрики
- •Планирование проектных задач
- •Размерно-ориентированные метрики
- •Функционально-ориентированные метрики
- •Выполнение оценки в ходе руководства проектом
- •Выполнение оценки проекта на основе loc- и fp-метрик
- •Конструктивная модель стоимости
- •Модель композиции приложения
- •Модель раннего этапа проектирования
- •Модель этапа постархитектуры
- •Предварительная оценка программного проекта
- •Анализ чувствительности программного проекта
- •Сценарий понижения зарплаты
- •Сценарий наращивания памяти
- •Сценарий использования нового микропроцессора
- •Сценарий уменьшения средств на завершение проекта
- •Контрольные вопросы
- •Глава 3. Классические методы анализа
- •Структурный анализ
- •Диаграммы потоков данных
- •Описание потоков данных и процессов
- •Расширения для систем реального времени
- •Расширение возможностей управления
- •Модель системы регулирования давления космического корабля
- •Методы анализа, ориентированные на структуры данных
- •Метод анализа Джексона
- •Методика Джексона
- •Шаг объект-действие
- •Шаг объект-структура
- •Шаг начального моделирования
- •Контрольные вопросы
- •Глава 4. Основы проектирования программных систем
- •Особенности процесса синтеза программных систем
- •Особенности этапа проектирования
- •Структурирование системы
- •Моделирование управления
- •Декомпозиция подсистем на модули
- •Модульность
- •Информационная закрытость
- •Связность модуля
- •Функциональная связность
- •Информационная связность
- •Коммуникативная связность
- •Процедурная связность
- •Временная связность
- •Логическая связность
- •Связность по совпадению
- •Определение связности модуля
- •Сцепление модулей
- •Сложность программной системы
- •Характеристики иерархической структуры программной системы
- •Контрольные вопросы
- •Глава 5. Классические методы проектирования
- •Метод структурного проектирования
- •Типы информационных потоков
- •Проектирование для потока данных типа «преобразование»
- •Диаграмма потоков данных пдд
- •Проектирование для потока данных типа «запрос»
- •Диаграмма потоков данных
- •Метод проектирования Джексона
- •Доопределение функций
- •Учет системного времени
- •Контрольные вопросы
- •Глава 6. Структурное тестирование программного обеспечения
- •Основные понятия и принципы тестирования по
- •Тестирование «черного ящика»
- •Тестирование «белого ящика»
- •Особенности тестирования «белого ящика»
- •Способ тестирования базового пути
- •Потоковый граф
- •Цикломатическая сложность
- •Шаги способа тестирования базового пути
- •Способы тестирования условий
- •Тестирование ветвей и операторов отношений
- •Способ тестирования потоков данных
- •Тестирование циклов
- •Простые циклы
- •Вложенные циклы
- •Объединенные циклы
- •Неструктурированные циклы
- •Контрольные вопросы
- •Глава 7. Функциональное тестирование программного обеспечения
- •Особенности тестирования «черного ящика»
- •Способ разбиения по эквивалентности
- •Способ анализа граничных значений
- •Способ диаграмм причин-следствий
- •Контрольные вопросы
- •Глава 8. Организация процесса тестирования программного обеспечения
- •Методика тестирования программных систем
- •Тестирование элементов
- •Тестирование интеграции
- •Нисходящее тестирование интеграции
- •Восходящее тестирование интеграции
- •Сравнение нисходящего и восходящего тестирования интеграции
- •Тестирование правильности
- •Системное тестирование
- •Тестирование восстановления
- •Тестирование безопасности
- •Стрессовое тестирование
- •Тестирование производительности
- •Искусство отладки
- •Контрольные вопросы
- •Глава 9. Основы объектно-ориентированного представления программных систем
- •Принципы объектно-ориентированного представления программных систем
- •Абстрагирование
- •Инкапсуляция
- •Модульность
- •Иерархическая организация
- •Объекты
- •Общая характеристика объектов
- •Виды отношений между объектами
- •Видимость объектов
- •Агрегация
- •Общая характеристика классов
- •Виды отношений между классами
- •Ассоциации классов
- •Наследование
- •Полиморфизм
- •Агрегация
- •Зависимость
- •Конкретизация
- •Контрольные вопросы
- •Глава 10. Базис языка визуального моделирования
- •Унифицированный язык моделирования
- •Предметы в uml
- •Отношения в uml
- •Диаграммы в uml
- •Механизмы расширения в uml
- •Контрольные вопросы
- •Глава 11. Статические модели объектно-ориентированных программных систем
- •Вершины в диаграммах классов
- •Свойства
- •Операции
- •Организация свойств и операций
- •Множественность
- •Отношения в диаграммах классов
- •Деревья наследования
- •Примеры диаграмм классов
- •Контрольные вопросы
- •Глава 12. Динамические модели объектно-ориентированных программных систем
- •Моделирование поведения программной системы
- •Диаграммы схем состояний
- •Действия в состояниях
- •Условные переходы
- •Вложенные состояния
- •Диаграммы деятельности
- •Диаграммы взаимодействия
- •Диаграммы сотрудничества
- •Диаграммы последовательности
- •Диаграммы Use Case
- •Актеры и элементы Use Case
- •Отношения в диаграммах Use Case
- •Работа с элементами Use Case
- •Спецификация элементов Use Case
- •Главный поток
- •Подпотоки
- •Альтернативные потоки
- •Пример диаграммы Use Case
- •Построение модели требований
- •Кооперации и паттерны
- •Паттерн Наблюдатель
- •Паттерн Компоновщик
- •Паттерн Команда
- •Бизнес-модели
- •Контрольные вопросы
- •Глава 13. Модели реализации объектно-ориентированных программных систем
- •Компонентные диаграммы
- •Компоненты
- •Интерфейсы
- •Компоновка системы
- •Разновидности компонентов
- •Использование компонентных диаграмм
- •Моделирование программного текста системы
- •Моделирование реализации системы
- •Основы компонентной объектной модели
- •Организация интерфейса сом
- •Идентификация интерфейса
- •Описание интерфейса
- •Реализация интерфейса
- •Unknown — базовый интерфейс com
- •Серверы сом-объектов
- •Преимущества com
- •Работа с сом-объектами
- •Создание сом-объектов
- •IClassFactory :: Createlnstance (iid a); 2 — фабрика класса создает сом-объект и получает
- •Повторное использование сом-объектов
- •Маршалинг
- •Диаграммы размещения
- •Использование диаграмм размещения
- •Контрольные вопросы
- •Глава 14. Метрики объектно-ориентированных программных систем
- •Метрические особенности объектно-ориентированных программных систем
- •Локализация
- •Инкапсуляция
- •Информационная закрытость
- •Наследование
- •Абстракция
- •Эволюция мер связи для объектно-ориентированных программных систем
- •Связность объектов
- •Метрики связности по данным
- •Метрики связности по методам
- •Сцепление объектов
- •Зависимость изменения между классами
- •Локальность данных
- •Набор метрик Чидамбера и Кемерера
- •Метрика 1: Взвешенные методы на класс wmc (Weighted Methods Per Class)
- •Метрика 2: Высота дерева наследования dit (Depth of Inheritance Tree)
- •Метрика 3: Количество детей noc (Number of children)
- •Метрика 4: Сцепление между классами объектов сво (Coupling between object classes)
- •Метрика 5: Отклик для класса rfc (Response For a Class)
- •Метрика 6: Недостаток связности в методах lсom (Lack of Cohesion in Methods)
- •Использование метрик Чидамбера-Кемерера
- •Метрики Лоренца и Кидда
- •Метрики, ориентированные на классы
- •Метрика 1: Размер класса cs (Class Size)
- •Метрика 2: Количество операций, переопределяемых подклассом, noo
- •Метрика 3: Количество операций, добавленных подклассом, noa
- •Метрика 4: Индекс специализации si (Specialization Index)
- •Операционно-ориентированные метрики
- •Метрика 5: Средний размер операции osavg (Average Operation Size)
- •Метрика 6: Сложность операции ос (Operation Complexity
- •Метрика 7: Среднее количество параметров на операцию npavg
- •Метрики для оо-проектов
- •Метрика 8: Количество описаний сценариев nss (Number of Scenario Scripts)
- •Метрика 9: Количество ключевых классов nkc (Number of Key Classes)
- •Метрика 10: Количество подсистем nsub (NumberofSuBsystem)
- •Набор метрик Фернандо Абреу
- •Метрика 1: Фактор закрытости метода mhf (Method Hiding Factor)
- •Метрика 2: Фактор закрытости свойства ahf (Attribute Hiding Factor)
- •Метрика 3: Фактор наследования метода mif (Method Inheritance Factor)
- •Метрика 4: Фактор наследования свойства aif (Attribute Inheritance Factor)
- •Метрика 5: Фактор полиморфизма pof (Polymorphism Factor)
- •Метрика 6: Фактор сцепления cof (Coupling Factor)
- •Метрики для объектно-ориентированного тестирования
- •Метрики инкапсуляции
- •Метрика 1: Недостаток связности в методах lcom
- •Метрика 2: Процент публичных и защищенных pap (Percent Public and Protected)
- •Метрика 3: Публичный доступ к компонентным данным pad (Public Access to Data members)
- •Метрики наследования
- •Метрики полиморфизма
- •Контрольные вопросы
- •Глава 15. Унифицированный процесс разработки объектно-ориентированных пс
- •Эволюционно-инкрементная организация жизненного цикла разработки
- •Этапы и итерации
- •Рабочие потоки процесса
- •Технические артефакты
- •Управление риском
- •Идентификация риска
- •Анализ риска
- •Ранжирование риска
- •Планирование управления риском
- •Разрешение и наблюдение риска
- •Этапы унифицированного процесса разработки
- •Этап начало (Inception)
- •Этап развитие (Elaboration)
- •Этап конструирование (Construction)
- •Этап переход (Transition)
- •Оценка качества проектирования
- •Этап развитие
- •Этап конструирование
- •Пример объектно-ориентированной разработки
- •Этап начало
- •Идентификация актеров
- •Идентификация элементов Use Case
- •Описания элементов Use Case
- •Этап развитие
- •Сценарии для элемента Use Case Управление окнами
- •Развитие описания элемента Use Case Использование окон
- •Диаграммы последовательности
- •15.9. Диаграмма последовательности Уничтожение окна
- •Создание классов
- •Планирование итераций конструирования
- •Этап конструирование
- •Итерация 1 — реализация сценариев элемента Use Case Управление окнами
- •Итерация 2 — реализация сценариев элемента Use Case Использование окон
- •Итерация 3 — разработка диалогового окна
- •Разработка в стиле экстремального программирования
- •Элемент хр-разработки
- •Коллективное владение кодом
- •Взаимодействие с заказчиком
- •Стоимость изменения и проектирование
- •Контрольные вопросы
- •Глава 16. Объектно-ориентированное тестирование
- •Расширение области применения объектно-ориентированного тестирования
- •Изменение методики при объектно-ориентированном тестировании
- •Особенности тестирования объектно-ориентированных «модулей»
- •Тестирование объектно-ориентированной интеграции
- •Объектно-ориентированное тестирование правильности
- •Проектирование объектно-ориентированных тестовых вариантов
- •Тестирование, основанное на ошибках
- •Тестирование, основанное на сценариях
- •Тестирование поверхностной и глубинной структуры
- •Способы тестирования содержания класса
- •Стохастическое тестирование класса
- •Тестирование разбиений на уровне классов
- •Способы тестирования взаимодействия классов
- •Стохастическое тестирование
- •Тестирование разбиений
- •Тестирование на основе состояний
- •Предваряющее тестирование при экстремальной разработке
- •Import ПосещениеКафе;
- •V.ПолучитьВес();
- •Контрольные вопросы
- •Глава 17. Автоматизация конструирования визуальной модели программной системы
- •Общая характеристика case-системы Rational Rose
- •Создание диаграммы Use Case
- •Создание диаграммы последовательности
- •Создание диаграммы классов
- •Создание компонентной диаграммы
- •Генерация программного кода
- •Заключение
- •Приложение а. Факторы затрат постархитектурной модели сосомо II
- •Сложность продукта (Product Complexity) cplx
- •Приложение б.Терминология языка uml и унифицированного процесса
- •Приложение в. Основные средства языка программирования Ada 95
- •Типы и объекты данных
- •Текстовый и числовой ввод-вывод
- •Пакеты ввода-вывода
- •Процедуры ввода
- •Процедуры вывода
- •Основные операторы
- •Операторы цикла
- •Основные программные модули
- •Функции
- •Процедуры
- •Производные типы
- •Подтипы
- •Расширяемые типы
- •Список литературы
- •Оглавление
- •Глава 1. Организация процесса конструирования 6
- •Глава 2. Руководство программным проектом 19
- •Глава 3. Классические методы анализа 41
- •Глава 4. Основы проектирования программных систем 52
- •Глава 5. Классические методы проектирования 67
- •Глава 6. Структурное тестирование программного обеспечения 74
- •Глава 7. Функциональное тестирование программного обеспечения 88
- •Глава 8. Организация процесса тестирования программного обеспечения 96
- •Глава 9. Основы объектно-ориентированного представления программных систем 107
- •Глава 10. Базис языка визуального моделирования 124
- •Глава 11. Статические модели объектно-ориентированных программных систем 131
- •Глава 12. Динамические модели объектно-ориентированных программных систем 141
- •Глава 13. Модели реализации объектно-ориентированных программных систем 170
- •Глава 14. Метрики объектно-ориентированных программных систем 190
- •Глава 15. Унифицированный процесс разработки объектно-ориентированных пс 210
- •Глава 16. Объектно-ориентированное тестирование 238
- •Глава 17. Автоматизация конструирования визуальной модели программной системы 263
- •Технологии разработки программного обеспечения: Учебник
- •197110, Санкт-Петербург, Чкаловский пр., 15.
Модель этапа постархитектуры
Модель этапа постархитектуры используется в период, когда уже сформирована архитектура и выполняется дальнейшая разработка программного продукта.
Основное уравнение постархитектурной модели является развитием уравнения предыдущей модели и имеет следующий вид:
ЗАТРАТЫ = А х К~req х РАЗМЕРB х Мр +3ATPATЫauto [чел.-мес],
где
коэффициент К~req учитывает возможные изменения в требованиях;
показатель В отражает нелинейную зависимость затрат от размера проекта (размер выражается в KLOC), вычисляется так же, как и в предыдущей модели;
в размере проекта различают две составляющие — новый код и повторно используемый код;
множитель поправки Мр зависит от 17 факторов затрат, характеризующих продукт, аппаратуру, персонал и проект.
Изменчивость требований приводит к повторной работе, требуемой для учета предлагаемых изменений, оценка их влияния выполняется по формуле
К~req =l + (BRAK/100),
где BRAK — процент кода, отброшенного (модифицированного) из-за изменения требований.
Размер проекта и продукта определяют по выражению
РАЗМЕР = PA3MEPnew + PA3MEPreuse [KLOC],
где
PA3MEPnew — размер нового (создаваемого) программного кода;
PA3MEPreuse — размер повторно используемого программного кода.
Формула для расчета размера повторно используемого кода записывается следующим образом:
PA3MEPreuse =KASLOC x ((100 - AT)/ 100) x (AA + SU + 0,4 DM + 0,3 CM + 0,3 IM) /100,
где
KASLOC — количество строк повторно используемого кода, который должен быть модифицирован (в тысячах строк);
AT — процент автоматически генерируемого кода;
DM — процент модифицируемых проектных моделей;
CM — процент модифицируемого программного кода;
IM — процент затрат на интеграцию, требуемых для подключения повторно используемого ПО;
SU — фактор, основанный на стоимости понимания добавляемого ПО; изменяется от 50 (для сложного неструктурированного кода) до 10 (для хорошо написанного объектно-ориентированного кода);
АА — фактор, который отражает стоимость решения о том, может ли ПО быть повторно используемым; зависит от размера требуемого тестирования и оценивания (величина изменяется от 0 до 8).
Правила выбора этих параметров приведены в руководстве по СОСОМО II.
Для определения множителя поправки Мр основного уравнения используют 17 факторов затрат, которые могут быть разбиты на 4 категории. Перечислим факторы затрат, сгруппировав их по категориям.
Факторы продукта:
1) требуемая надежность ПО — RELY;
2) размер базы данных — DATA;
3) сложность продукта — CPLX;
4) требуемая повторная используемость — RUSE;
5) документирование требований жизненного цикла — DOCU.
Факторы платформы (виртуальной машины):
6) ограничения времени выполнения — TIME;
7) ограничения оперативной памяти — STOR;
изменчивость платформы — PVOL.
Факторы персонала:
9) возможности аналитика — АСАР;
10) возможности программиста — РСАР;
11) опыт работы с приложением — АЕХР;
12) опыт работы с платформой — РЕХР;
13) опыт работы с языком и утилитами — LTEX;
14) непрерывность персонала — PCON.
Факторы проекта:
15) использование программных утилит — TOOL;
16) мультисетевая разработка — SITE;
17) требуемый график разработки — SCED.
Для каждого фактора определяется оценка (по 6-балльной шкале). На основе оценки для каждого фактора по таблице Боэма определяется множитель затрат ЕМi. Перемножение всех множителей затрат дает множитель поправки пост-архитектурной модели:
.
Значение Мр отражает реальные условия выполнения программного проекта и позволяет троекратно увеличить (уменьшить) начальную оценку затрат.
ПРИМЕЧАНИЕ
Трудоемкость работы с факторами затрат минимизируется за счет использования специальных таблиц. Справочный материал для оценки факторов затрат приведен в приложении А.
От оценки затрат легко перейти к стоимости проекта. Переход выполняют по формуле:
СТОИМОСТЬ = ЗАТРАТЫ х РАБ_ КОЭФ,
где среднее значение рабочего коэффициента составляет $15 000 за человеко-месяц.
После определения затрат и стоимости можно оценить длительность разработки. Модель СОСОМО II содержит уравнение для оценки календарного времени TDEV, требуемого для выполнения проекта. Для моделей всех уровней справедливо:
Длительность (TDEV) = [3,0 х (ЗАТРАТЫ)(0,33+0,2(B-1,01))] х SCEDPercentage/100 [мес],
где
В — ранее рассчитанный показатель степени;
SCEDPercentage — процент увеличения (уменьшения) номинального графика.
Если нужно определить номинальный график, то принимается SCEDPercentage =100 и правый сомножитель в уравнении обращается в единицу. Следует отметить, что СОСОМО II ограничивает диапазон уплотнения/растягивания графика (от 75 до 160%). Причина проста — если планируемый график существенно отличается от номинального, это означает внесение в проект высокого риска.
Рассмотрим пример. Положим, что затраты на проект равны 20 человеко-месяцев. Примем, что все масштабные факторы номинальны (имеют значения 3), поэтому, в соответствии с табл. 2.20, показатель степени 5=1,16. Отсюда следует, что номинальная длительность проекта равна
TDEV = 3, Ox (20)0,36 = 8,8 мес.
Отметим, что зависимость между затратами и количеством разработчиков носит характер, существенно отличающийся от линейного. Очень часто увеличение количества разработчиков приводит к возрастанию затрат. В чем причина? Ответ прост:
увеличивается время на взаимодействие и обучение сотрудников, согласование совместных решений;
возрастает время на определение интерфейсов между частями программной системы.
Удвоение разработчиков не приводит к двукратному сокращению длительности проекта. Модель СОСОМО II явно утверждает, что длительность проекта является функцией требуемых затрат, прямой зависимости от количества сотрудников нет. Другими словами, она устраняет миф нерадивых менеджеров в том, что добавление людей поможет ликвидировать отставание в проекте.
СОСОМО II предостерегает от определения потребного количества сотрудников путем деления затрат на длительность проекта. Такой упрощенный подход часто приводит к срыву работ. Реальная картина имеет другой характер. Количество людей, требуемых на этапе планирования и формирования требований, достаточно мало. На этапах проектирования и кодирования потребность в увеличении команды возрастает, после окончания кодирования и тестирования численность необходимых сотрудников достигает минимума.