- •Глава 1. Организация процесса конструирования
- •Определение технологии конструирования программного обеспечения
- •Классический жизненный цикл
- •Макетирование
- •Стратегии конструирования по
- •Инкрементная модель
- •Быстрая разработка приложений
- •Спиральная модель
- •Компонентно-ориентированная модель
- •Тяжеловесные и облегченные процессы
- •Модели качества процессов конструирования
- •Контрольные вопросы
- •Глава 2. Руководство программным проектом
- •Процесс руководства проектом
- •Начало проекта
- •Измерения, меры и метрики
- •Процесс оценки
- •Анализ риска
- •Планирование
- •Трассировка и контроль
- •Планирование проектных задач
- •Размерно-ориентированные метрики
- •Функционально-ориентированные метрики
- •Выполнение оценки в ходе руководства проектом
- •Выполнение оценки проекта на основе loc- иFp-метрик
- •Конструктивная модель стоимости
- •Модель композиции приложения
- •Модель раннего этапа проектирования
- •Модель этапа постархитектуры
- •Предварительная оценка программного проекта
- •Анализ чувствительности программного проекта
- •Сценарий понижения зарплаты
- •Сценарий наращивания памяти
- •Сценарий использования нового микропроцессора
- •Сценарий уменьшения средств на завершение проекта
- •Контрольные вопросы
- •Глава 3. Основы проектирования программных систем
- •Особенности процесса синтеза программных систем
- •Особенности этапа проектирования
- •Структурирование системы
- •Моделирование управления
- •Декомпозиция подсистем на модули
- •Модульность
- •Информационная закрытость
- •Связность модуля
- •Функциональная связность
- •Информационная связность
- •Коммуникативная связность
- •Процедурная связность
- •Временная связность
- •Логическая связность
- •Связность по совпадению
- •Определение связности модуля
- •Сцепление модулей
- •Сложность программной системы
- •Характеристики иерархической структуры программной системы
- •Контрольные вопросы
- •Метрики объектно-ориентированных программных систем
- •Метрические особенности объектно-ориентированных программных систем
- •Локализация
- •Инкапсуляция
- •Информационная закрытость
- •Наследование
- •Абстракция
- •Эволюция мер связи для объектно-ориентированных программных систем
- •Связность объектов
- •Метрики связности по данным
- •Метрики связности по методам
- •Сцепление объектов
- •Зависимость изменения между классами
- •Локальность данных
- •Набор метрик Чидамбера и Кемерера
- •Метрика 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)
- •Метрики Лоренца и Кидда
- •Метрики, ориентированные на классы
- •Метрика 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)
- •9. Тестирование программных продуктов
- •9.1. Виды контроля качества разрабатываемого программного обеспечения
- •9.2. Ручной контроль программного обеспечения
- •2. Контроль вычислений
- •3. Контроль передачи управления
- •4. Контроль межмодульных интерфейсов
- •9.3. Структурное тестирование
- •9.4. Функциональное тестирование
- •Глава 8. Организация процесса тестирования программного обеспечения
- •Методика тестирования программных систем
- •Тестирование элементов
- •Тестирование интеграции
- •Нисходящее тестирование интеграции
- •Восходящее тестирование интеграции
- •Сравнение нисходящего и восходящего тестирования интеграции
- •Тестирование правильности
- •Системное тестирование
- •Тестирование восстановления
- •Тестирование безопасности
- •Стрессовое тестирование
- •Тестирование производительности
- •Искусство отладки
- •Контрольные вопросы
- •2.Использование буфера обмена
- •3.Технология "перетяни и оставь"
- •4. Технология ole
- •5. Динамический обмен данными (dde)
- •6. Эволюция архитектуры «клиент-сервер»
- •6.1 Определение и назначение промежуточного по
- •6.2 Функции middleware
- •6.3 Виды промежуточного по
- •Промежуточное по межпрограммного взаимодействия
- •6.4 Промежуточное по доступа к базам данных
- •9. Основы компонентной объектной модели
- •Организация интерфейса сом
- •Идентификация интерфейса
- •Описание интерфейса
- •Реализация интерфейса
- •Unknown — базовый интерфейс com
- •Серверы сом-объектов
- •Преимущества com
- •Работа с сом-объектами
- •Создание сом-объектов
- •IClassFactory :: Createlnstance (iid a); 2 — фабрика класса создает сом-объект и получает
- •Повторное использование сом-объектов
- •Маршалинг
- •12. Введение в .Net Framework
Модель раннего этапа проектирования
Модель раннего этапа проектирования используется в период, когда стабилизируются требования и определяется базисная программная архитектура.
Основное уравнение этой модели имеет следующий вид:
ЗАТРАТЫ = А х РАЗМЕРв х Ме + ЗАТРАТЫаuto[чел.-мес],
где:
масштабный коэффициент А = 2,5;
показатель В отражает нелинейную зависимость затрат от размера проекта (размер системы РАЗМЕР выражается в тысячах LOC);
множитель поправки Мe зависит от 7 формирователей затрат, характеризующих продукт, процесс и персонал;
слагаемое 3ATPATЫauto отражает затраты на автоматически генерируемый программный код.
Значение показателя степени В изменяется в диапазоне 1,01... 1,26, зависит от пяти масштабных факторов Wi и вычисляется по формуле
.
Общая характеристика масштабных факторов приведена в табл. 2.19, а табл. 2.20 позволяет определить оценки этих факторов. Оценки принимают 6 значений: от очень низкой (5) до сверхвысокой (0).
Таблица 2.19. Характеристика масштабных факторов
Масштабный фактор (Wi) |
Пояснение |
Предсказуемость PREC |
Отражает предыдущий опыт организации в реализации проектов этого типа. Очень низкий означает отсутствие опыта. Сверхвысокий означает, что организация полностью знакома с этой прикладной областью |
Гибкость разработки FLEX
Разрешение архитектуры /риска RESL
Связность группы TEAM
Зрелость процесса РМАТ |
Отражает степень гибкости процесса разработки. Очень низкий означает, что используется заданный процесс. Сверхвысокий означает, что клиент установил только общие цели Отражает степень выполняемого анализа риска. Очень низкий означает малый анализ. Сверхвысокий означает полный и сквозной анализ риска Отражает, насколько хорошо разработчики группы знают друг друга и насколько удачно они совместно работают. Очень низкий означает очень трудные взаимодействия. Сверхвысокий, означает интегрированную группу, без проблем взаимодействия Означает зрелость процесса в организации. Вычисление этого фактора может выполняться по вопроснику СММ |
В качестве иллюстрации рассмотрим компанию, которая берет проект в малознакомой проблемной области. Положим, что заказчик не определил используемый процесс разработки и не допускает выделения времени на всесторонний анализ риска. Для реализации этой программной системы нужно создать новую группу разработчиков. Компания имеет возможности, соответствующие 2-му уровню зрелости согласно модели СММ. Возможны следующие значения масштабных факторов:
предсказуемость. Это новый проект для компании — значение Низкий (4);
гибкость разработки. Заказчик требует некоторого согласования — значение Очень высокий (1);
разрешение архитектуры/риска. Не выполняется анализ риска, как следствие, малое разрешение риска — значение Очень низкий (5);
связность группы. Новая группа, нет информации — значение Номинальный (3);
зрелость процесса. Имеет место некоторое управление процессом — значение Номинальный (3).
Таблица 2.20. Оценка масштабных факторов
Масштабный фактор (Wi) |
Очень низкий 5 |
Низкий 4 |
PRЕС |
Полностью непредсказуемый проект |
Главным образом, в значительной степени непредсказуемый |
FLEX |
Точный, строгий процесс разработки |
Редкое расслабление в работе |
RESL |
Малое разрешение риска (20%) |
Некоторое (40%) |
TEAM |
Очень трудное взаимодействие |
Достаточно трудное взаимодействие |
PREC |
Полностью непредсказуемый проект |
В значительной степени непредсказуемый |
РМАТ |
Взвешенное среднее значение от количества ответов «Yes» на вопросник СММ Maturity |
Сумма этих значений равна 16, поэтому конечное значение степени В= 1,17. Вернемся к обсуждению основного уравнения модели раннего этапа проектирования. Множитель поправки Мe зависит от набора формирователей затрат, перечисленных в табл. 2.21.
Для каждого формирователя затрат определяется оценка (по 6-балльной шкале), где 1 соответствует очень низкому значению, а 6 — сверхвысокому значению. На основе оценки для каждого формирователя по таблице Боэма определяется множитель затрат EMi Перемножение всех множителей затрат формирует множитель поправки:
.
Слагаемое 3ATPATbIauto используется, если некоторый процент программного кода генерируется автоматически. Поскольку производительность такой работы значительно выше, чем при ручной разработке кода, требуемые затраты вычисляются отдельно, по следующей формуле:
ЗАТРАТЫаuto = (КALOC x (AT /100)) / ATPROD,
где:
KALOC — количество строк автоматически генерируемого кода (в тысячах строк);
AT — процент автоматически генерируемого кода (от всего кода системы);
ATPROD — производительность автоматической генерации кода.
Сомножитель AT в этой формуле позволяет учесть затраты на организацию взаимодействия автоматически генерируемого кода с оставшейся частью системы.
Далее затраты на автоматическую генерацию добавляются к затратам, вычисленным для кода, разработанного вручную.
Номинальный 3 |
Высокий 2 |
Очень высокий 1 |
Сверхвысокий 0 |
Отчасти |
Большей частью |
В значительной |
Полностью знакомый |
непредсказуемый |
знакомый |
степени знакомый |
|
Некоторое расслабление в работе |
Большей частью согласованный процесс |
Некоторое согласование процесса |
Заказчик определил только общие цели |
Частое (60%) |
Большей частью (75%) |
Почти всегда (90%) |
Полное (100%) |
Среднее |
Главным образом |
Высокая |
Безукоризненное |
взаимодействие |
кооперативность |
кооперативность |
взаимодействие |
Отчасти непредсказуемый |
Большей частью знакомый |
В значительной степени знакомый |
Полностью знакомый |
Взвешенное среднее значение от количества ответов «Yes» на вопросник СММ Maturity |
Таблица 2.21. Формирователи затрат для раннего этапа проектирования
Обозначение |
Название |
PERS RCPX RUSE PDIF PREX FСIL SCED |
Возможности персонала (Personnel Capability) Надежность и сложность продукта (Product Reliability and Complexity) Требуемое повторное использование (Required Reuse) Трудность платформы (Platform Difficulty) Опытность персонала (Personnel Experience) Средства поддержки (Facilities) График (Schedule) |