- •З курсу
- •З курсу
- •Содержание
- •Часть I. Инженерные основы программного обеспечения 10
- •Часть II. Требования к программному обеспечению 33
- •Часть III. Моделирование программного обеспечения 52
- •Часть IV. Технологии разработки программного обеспечения 124
- •Часть V. Письменная коммуникация. Документирование проекта Программного обеспечения 145
- •Часть VI. Управление проектом программного обеспечения 192
- •Предисловие
- •Часть I. Инженерные основы программного обеспечения
- •1. Введение в программную инженерию
- •1.1. Вопросы и ответы об инженерии программного обеспечения
- •1.2. Профессиональные и этические требования к специалистам по программному обеспечению
- •2. Системотехника вычислительных систем
- •2.1. Интеграционные свойства систем
- •2.2. Система и ее окружение
- •2.3. Моделирование систем
- •2.4. Процесс создания систем
- •2.5. Приобретение систем
- •3. Процесс создания программного обеспечения
- •3.1. Модели процесса создания программного обеспечения
- •3.2. Итерационные модели разработки программного обеспечения
- •3.3. Спецификация программного обеспечения
- •3.4. Проектирование и реализация программного обеспечения
- •3.5. Эволюция программных систем
- •3.6. Автоматизированные средства разработки программного обеспечения
- •4. Технологии производства программного обеспечения
- •Часть II. Требования к программному обеспечению
- •5. Требования к программному обеспечению
- •5.1. Функциональные и нефункциональные требования
- •5.2. Пользовательские требования
- •5.3. Системные требования
- •5.4. Документирование системных требований
- •6. Разработка требований
- •6.1. Анализ осуществимости
- •6.2. Формирование и анализ требований
- •6.3. Аттестация требований
- •6.4. Управление требованиям
- •7. Матрица требований. Разработка матрицы требований
- •Часть III. Моделирование программного обеспечения
- •8. Архитектурное проектирование
- •8.1. Структурирование системы
- •8.2. Модели управления
- •8.3. Модульная декомпозиция
- •8.4. Проблемно-зависимые архитектуры
- •9. Архитектура распределенных систем
- •9.1. Многопроцессорная архитектура
- •9.2. Архитектура клиент/сервер
- •9.3. Архитектура распределенных объектов
- •9.4. Corba
- •10. Объектно-ориентированное проектирование
- •10.1. Объекты и классы объектов
- •10.2. Процесс объектно-ориентированного проектирования
- •10.2.1. Окружение системы и модели ее использования
- •10.2.2. Проектирование архитектуры
- •10.2.3. Определение объектов
- •10.2.4. Модели архитектуры
- •10.2.5. Специфицирование интерфейсов объектов
- •10.3. Модификация системной архитектуры
- •11. Проектирование систем реального времени
- •11.1. Проектирование систем реального времени
- •11.2. Управляющие программы
- •11.3. Системы наблюдения и управления
- •11.4. Системы сбора данных
- •12. Проектирование с повторным использованием компонентов
- •12.1. Покомпонентная разработка
- •12.2. Семейства приложений
- •12.3. Проектные паттерны
- •13. Проектирование интерфейса пользователя
- •13.1. Принципы проектирования интерфейсов пользователя
- •13.2. Взаимодействие с пользователем
- •13.3. Представление информации
- •13.4. Средства поддержки пользователя
- •13.5. Оценивание интерфейса
- •Часть IV. Технологии разработки программного обеспечения
- •14. Жизненный цикл программного обеспечения: модели и их особенности
- •14.1. Каскадная модель жизненного цикла
- •14.2. Эволюционная модель жизненного цикла
- •14.2.1. Формальная разработка систем
- •14.2.2. Разработка программного обеспечения на основе ранее созданных компонентов
- •14.3. Итерационные модели жизненного цикла
- •14.3.1 Модель пошаговой разработки
- •14.3.2 Спиральная модель разработки
- •15. Методологические основы технологий разработки программного обеспечения
- •16. Методы структурного анализа и проектирования программного обеспечения
- •17. Методы объектно-ориентированного анализа и проектирования программного обеспечения. Язык моделирования uml
- •Часть V. Письменная коммуникация. Документирование проекта Программного обеспечения
- •18. Документирование этапов разработки программного обеспечения
- •19. Планирование проекта
- •19.1 Уточнение содержания и состава работ
- •19.2 Планирование управления содержанием
- •19.3 Планирование организационной структуры
- •19.4 Планирование управления конфигурациями
- •19.5 Планирование управления качеством
- •19.6 Базовое расписание проекта
- •20. Верификация и аттестация программного обеспечения
- •20.1. Планирование верификации и аттестации
- •20.2. Инспектирование программных систем
- •20.3. Автоматический статический анализ программ
- •20.4. Метод "чистая комната"
- •21. Тестирование программного обеспечения
- •21.1. Тестирование дефектов
- •21.1.1. Тестирование методом черного ящика
- •21.1.2. Области эквивалентности
- •21.1.3. Структурное тестирование
- •21.1.4. Тестирование ветвей
- •21.2. Тестирование сборки
- •21.2.1. Нисходящее и восходящее тестирование
- •21.2.2. Тестирование интерфейсов
- •21.2.3. Тестирование с нагрузкой
- •21.3. Тестирование объектно-ориентированных систем
- •21.3.1. Тестирование классов объектов
- •21.3.2. Интеграция объектов
- •21.4. Инструментальные средства тестирования
- •Часть VI. Управление проектом программного обеспечения
- •22. Управление проектами
- •22.1. Процессы управления
- •22.2. Планирование проекта
- •22.3. График работ
- •22.4. Управление рисками
- •23. Управление персоналом
- •23.1. Пределы мышления
- •23.1.1. Организация человеческой памяти
- •23.1.2. Решение задач
- •23.1.3. Мотивация
- •23.2. Групповая работа
- •23.2.1. Создание команды
- •23.2.2. Сплоченность команды
- •23.2.3. Общение в группе
- •23.2.4. Организация группы
- •23.3. Подбор и сохранение персонала
- •23.3.1. Рабочая среда
- •23.4. Модель оценки уровня развития персонала
- •24. Оценка стоимости программного продукта
- •24.1. Производительность
- •24.2. Методы оценивания
- •24.3. Алгоритмическое моделирование стоимости
- •24.3.1. Модель сосомо
- •24.3.2. Алгоритмические модели стоимости в планировании проекта
- •24.4. Продолжительность проекта и наем персонала
- •25. Управление качеством
- •25.1. Обеспечение качества и стандарты
- •25.1.1. Стандарты на техническую документацию
- •25.1.2. Качество процесса создания программного обеспечения и качество программного продукта
- •25.2. Планирование качества
- •25.3. Контроль качества
- •25.3.1. Проверки качества
- •25.4. Измерение показателей программного обеспечения
- •25.4.1. Процесс измерения
- •25.4.2. Показатели программного продукта
- •26. Надежность программного обеспечения
- •26.1. Обеспечение надежности программного обеспечения
- •26.1.1 Критические системы
- •26.1.2. Работоспособность и безотказность
- •26.1.3. Безопасность
- •26.1.4. Защищенность
- •26.2. Аттестация безотказности
- •26.3. Гарантии безопасности
- •26.4. Оценивание защищенности программного обеспечения
- •27. Совершенствование производства программного обеспечения
- •27.1. Качество продукта и производства
- •27.2. Анализ и моделирование производства
- •27.2.1. Исключения в процессе создания по
- •27.3. Измерение производственного процесса
- •27.4. Модель оценки уровня развития
- •27.4.1. Оценивание уровня развития
- •27.5. Классификация процессов совершенствования
24.2. Методы оценивания
Не существует простого метода определения будущих затрат, необходимых для разработки программного продукта. Начальное оценивание можно провести, основываясь на определенных пользовательских требованиях высокого уровня. Но заранее не известно, какие технологии будут применяться при разработке ПО и какие компьютеры будет использоваться. Также невозможно предугадать, какие люди будут работать над проектом и какие у них будут навыки и опыт. Это показывает, что чрезвычайно трудно провести точную оценку стоимости проекта на самом раннем этапе. Более того, основная проблема в оценке себестоимости проектов заключается в низкой точности применяемых методов оценивания.
Часто в расчет себестоимости проекта закладывается его окупаемость. Таким образом, первоначальная оценка себестоимости определяет бюджет проекта, за рамки которого нельзя выходить при реализации проекта. Вместе с тем я не знаю ни одного реализованного проекта, где бы стоимость не корректировалась по ходу его выполнения. Но всегда в ходе реализации проекта фактические расходы сравниваются с предварительной оценкой затрат.
Несмотря ни на что, организации-разработчики обязательно должны оценивать затраты на разработку и себестоимость программного продукта. Для этого можно применять методы, описанные в табл. 24.4.
Таблица 24.4. Методы оценки себестоимости
Метод |
Описание |
Алгоритмическое моделирование себестоимости |
Метод основан на анализе статистических данных о ранее выполненных проектах, при этом определяется зависимость себестоимости проекта от какого-нибудь количественного показателя программного продукта (обычно это размер программного кода). Проводится оценка этого показателя для данного проекта, после чего с помощью модели прогнозируются будущие затраты |
Оценка эксперта |
Проводится опрос нескольких экспертов по технологии разработки ПО, знающих область применения создаваемого программного продукта. Каждый из них дает свою оценку себестоимости проекта. Потом все оценки сравниваются и обсуждаются. Этот процесс повторяется до тех пор, пока не будет достигнуто согласие по окончательному варианту предварительной сметы проекта |
Оценка по аналогии |
Этот метод используется в том случае, если в данной области применения создаваемого ПО уже реализованы аналогичные проекты. В таком случае при оценке затрат для сравнения берутся предыдущие проекты. |
Закон Паркинсона |
Согласно этому закону усилия, затраченные на работу, распределяются равномерно по выделенному на проект времени. Здесь критерием для оценки затрат по проекту являются человеческие ресурсы, а не целевая оценка самого программного продукта. Если проект, над которым работает пять человек, должен быть закончен в течение 12 месяцев, то затраты на его выполнение исчисляются в 60 человеко-месяцев |
Назначение цены с целью выиграть контракт |
Затраты на проект определяются наличием тех средств, которые имеются у заказчика. Поэтому себестоимость проекта зависит от бюджета заказчика, а не от функциональных характеристик создаваемого продукта |
Методы предварительной оценки себестоимости могут выполняться с применением нисходящего или восходящего подходов. При нисходящем подходе оценка себестоимости начинается на уровне системы: рассматриваются функциональные возможности программы в целом и то, как эти возможности реализуются посредством функций более низкого уровня. Здесь учитывается себестоимость таких этапов разработки, как сборка системы, управление конфигурацией и создание технической документации.
В отличие от нисходящего подхода, восходящий начинается на уровне системных компонентов. Система разбивается на компоненты и определяются затраты на разработку каждого из них. Затем эти затраты суммируются для определения полной стоимости проекта.
Недостатки восходящего подхода являются достоинствами нисходящего и наоборот. Восходящий подход может недооценить затраты, необходимые для решения сложных проблем, возникающих при разработке таких специфических компонентов системы, как интерфейсы для нестандартных аппаратных средств. Детального обоснования для составления сметы затрат в этом случае не существует. Нисходящий подход, напротив, дает такое обоснование, а также возможность рассмотреть каждый компонент в отдельности. Вместе с тем данный подход больше акцентирует внимание на таких этапах реализации проекта, как, например, сборка системы. Кроме того, нисходящий подход является более дорогостоящим. Для его применения нужно иметь хотя бы предварительный результат проектирования системы с тем, чтобы оценить каждый ее компонент.
Каждый метод оценивания, безусловно, имеет слабые и сильные стороны. Для работы с большими проектами необходимо применить несколько методов оценивания себестоимости для их последующего сравнения. Если при этом получаются совершенно разные результаты, значит, информации для получения более точной оценки недостаточно. В этом случае необходимо воспользоваться дополнительной информацией, после чего повторить оценивание, и так до тех пор, пока результаты разных методов не станут достаточно близкими.
Описанные методы оценивания применимы, если документированы требования для будущей системы. В таком случае существует возможность определить функциональные характеристики разрабатываемой системы. Обычно все большие проекты разработки ПО имеют документ, в котором определены требования к системе.
Однако во многих проектах оценка затрат проводится только на основании проекта требований к системе. В этом случае лица, участвующие в оценке стоимости проекта, будут иметь минимум информации для работы. Процедуры анализа требований и создания спецификации весьма дорогостоящи. Поэтому менеджерам компании следует составить смету на их выполнение еще до утверждения бюджета для всего проекта.
Во многих случаях популярной становится стратегия ценообразования с целью "выиграть контракт". Можно согласиться, что данная фраза звучит несколько некорректно и не по-деловому, однако этa стратегия на самом деле себя оправдывает. Стоимость работы согласовывается на основании предварительного проекта предложения. Далее проводятся переговоры между компанией-исполнителем и заказчиком с тем, чтобы обсудить детальное техническое задание, которое, однако, ограничивается согласованной суммой. Продавец и заказчик также должны обсудить приемлемые функциональные возможности системы. Здесь основополагающим фактором для многих проектов становятся возможности бюджета, а не требования к системе. Требования всегда можно изменить так, чтобы не выходить за рамки принятого бюджета.
При оценке себестоимости проекта менеджеры должны всегда помнить о том, что между прошлыми проектами и будущими разработками может быть существенная разница. Только за последние 10 лет на свет появился целый ряд новейших разработок и технологий. Многие менеджеры очень мало ознакомлены, а иногда просто не имеют понятия об этих технологиях и о том, какое влияние они могут оказать на проект. Вот несколько примеров технических и технологических новшеств, которые могут повлиять на оценку стоимости проекта, основанную на предыдущем опыте.
• Появление объектно-ориентированного программирования вместо процедурного.
• Применение систем типа клиент/сервер вместо систем, основанных на мэйнфреймах.
• Применение готовых коммерческих пакетов программного обеспечения вместо собственной разработки компонентов системы.
• Повторное использование компонентов системы вместо новых разработок.
• Использование CASE-средств и генераторов программ вместо разработки ПО без применения средств поддержки.
Все эти факторы отнюдь не облегчают задачу менеджера в оценке стоимости программной продукции. И в этом случае предыдущий опыт не всегда оказывается полезным для проведения такой оценки.