- •З курсу
- •З курсу
- •Содержание
- •Часть 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. Классификация процессов совершенствования
26.1.2. Работоспособность и безотказность
Под работоспособностью системы подразумевается способность предоставлять пользователю все необходимые системные сервисы по мере возникновения потребности в них. Безотказность – это способность системы предоставлять именно те сервисы, которые заложены в систему ее спецификацией. Из этого следует, что безотказность более общий показатель, включающий в себя свойство работоспособности, поскольку если система не работоспособна, то о безотказности вообще речи идти не может.
Однако необходимо и различать эти свойства, так как требования к работоспособности и безотказности в разных системах могут быть различны. Например, некоторые системы могут иметь сравнительно частые сбои, но они также могут быстро восстанавливаться после сбоев. У таких систем сравнительно низкие требования к безотказности. В то же время они могут иметь высокие требования к работоспособности в связи с необходимостью непрерывного обслуживания пользователей.
Наглядный пример такой системы – коммутатор телефонной станции. Снимая трубку телефона, пользователь слышит зуммер, означающий, что "линия свободна" и система готова выполнить требования пользователя. В случае сбоя такая система должна быть легко восстанавливаема. Коммутатор телефонной станции имеет средства для восстановления неправильной работы и разрешает повторную попытку соединения. Это выполняется очень быстро, и абонент телефона может даже не почувствовать, что был сбой. В такой ситуации основным требованием к функциональной надежности системы является безотказность.
Другое различие между этими показателями заключается в том, что работоспособность системы зависит также от времени, которое требуется для устранения неисправности. Так как, если система А отказывает один раз в год, а система В отказывает раз в месяц, то система А более надежна, чем В. Однако, если системе А необходимо три дня для восстановления работоспособности, а системе В для этого достаточно всего 10 минут, то безотказность системы В выше, чем системы А. Исходя из этих соображений пользователь скорее выберет систему В, чем А
Безотказность и работоспособность системы могут быть определены более точно следующим образом.
1. Безотказность – это способность системы безотказно работать определенное время с указанной целью в определенном окружении.
2. Работоспособность – это способность системы правильно функционировать и предоставлять вовремя требуемые сервисы.
Одна из практических проблем, возникающая при разработке систем, заключается в том, что наши интуитивные понятия безотказности и работоспособности часто оказываются шире приведенных выше формулировок. При рассмотрении функциональной надежности системы должны быть приняты во внимание окружение, в котором будет действовать система, и цель, для которой она используется. Следовательно, оценка безотказности в одном окружении не обязательно переносится в другое окружение, где система используется по-другому.
Для примера рассмотрим безотказность системы программного обеспечения в двух средах (окружении) – в офисе и в университете. В офисе пользователи строго следуют инструкциям по работе с системой и не имеют времени и возможностей экспериментировать с ней. В университетской среде студенты пробуют все возможности системы и часто непредвиденными способами, что может привести к отказам системы, которые никогда бы не встретились в офисной среде.
В определении работоспособности и безотказности системы не рассматривается тяжесть и последствия отказов системы. Людям особенно небезразличны отказы, которые имеют серьезные последствия; от этого зависит восприятие безотказности системы. Например, работа автомобильного двигателя, который дает сбои сразу после запуска, а затем после перезапуска работает исправно, раздражает. Но это не затрагивает нормального режима эксплуатации автомобиля.
Считается, что система ведет себя надежно, если ее работа соответствует заданному алгоритму. Однако возможны ситуации, когда работа системы не совсем соответствует ожиданиям пользователей. К сожалению, системные требования часто бывают или неполны или некорректны. Разработчики в таких случаях должны сами решать, как будет вести себя система, но, не всегда являясь специалистами в конкретной области применения системы, они не могут учесть все факторы и запрограммировать такое поведение системы, которое необходимо пользователю.
Как показывает опыт, наиболее важными составляющими функциональной надежности являются безотказность и работоспособность. Если же система ненадежна, то трудно гарантировать ее безопасность или защищенность. Ненадежность системы влечет за собой большие материальные потери, такие системы приобретают репутацию некачественных и в дальнейшем теряют доверие потребителей.
Безотказность системы определяется отсутствием сбоев. Отказы системы могут происходить из-за плохого или неправильного ее обслуживания, могут быть следствием ошибок в алгоритме, а могут быть вызваны неисправностями систем связи. Однако во многих случаях причиной ошибочного поведения системы являются дефекты в самой системе. При рассмотрении безотказности полезно понимать различие в терминах сбой, ошибка и отказ, которые определены в табл. 26.1.
Таблица 26.1. Терминология безотказности
Термин |
Описание |
Отказ системы |
Прекращение функционирования системы |
Системные ошибки |
Ошибочное поведение системы, не соответствующее ее спецификации |
Сбой системы |
Неправильное поведение системы, непредвиденное ее разработчиками |
Ошибка оператора |
Неверные действия пользователя, вызвавшие сбой в работе системы |
Сбои не обязательно приводят к отказам системы, поскольку они могут быть кратковременными и система может прийти к нормальному функционированию раньше, чем произойдет отказ. Системные ошибки также не обязательно приводят к отказам системы, так как системы имеют защиту, гарантирующую, что ошибочный режим будет обнаружен и исправлен.
Терминология, приведенная в табл. 26.1, помогает понять три дополняющих друг друга подхода, используемых для повышения безотказности систем.
1. Предотвращение сбоев. Подход к разработке ПО, минимизирующий возможность появления ошибок и/или обнаруживающий ошибки прежде, чем они приведут к сбоям системы. Пример такого подхода – исключение подверженных ошибкам определенных конструкций языков программирования (например, указателей) и постоянный анализ программ для обнаружения различных аномалий программного кода.
2. Обнаружение ошибок и их устранение. Использование разнообразных методов проверки системы в различных режимах позволяет обнаружить ошибки и устранить их до ввода системы в эксплуатацию. Регулярное тестирование системы и ее отладка – пример данного подхода.
3. Устойчивость к сбоям. Использование специальных методов, гарантирующих, что ошибки в системе не приведут к сбоям и что сбои не приведут к отказам системы. Пример такого подхода – применение средств самовосстановления системы с использованием дублирования модулей.
Рис. 26.3. Программная система как отображение входных данных на множество выходных данных
Программный сбой приводит к отказу системы, когда "сбойный" программный код выполняется над определенными входными данными, приводящими к сбою системы. При этом программа может корректно работать на других входных данных. На рис. 16.5, программная система представлена как отображение множества входных данных (входов) на множество выходных данных (выходов). Программа обрабатывает входные данные, получая выходные данные.
Некоторые из входных данных (см. рис. 26.3) приводят к отказам системы, в результате программа генерирует ошибочные выходные данные. Безотказность программного обеспечения характеризуется вероятностью, с которой при выполнении программы среди множества входных данных встретятся такие, что приведут к ошибочным результатам вычислений.
Существует сложная взаимосвязь между наблюдаемой безотказностью системы и количеством скрытых программных дефектов. Не все программные ошибки в равной степени вызывают отказ системы. Обычно в множестве входных данных Iê, приводящих к ошибочным выходным данным, имеется ряд данных, вероятность выбора которых больше, чем у других данных. Если эти входные данные не требуют для своей обработки той части ПО, которая содержит ошибки, то системных сбоев не будет. Таким образом, безотказность системы зависит преимущественно от количества входных данных, приводящих к ошибочным результатам во время нормальной эксплуатации системы. Сбои системы, которые проявляются только в исключительных ситуациях, мало влияют на ее надежность.
Надежность системы связана с вероятностью ошибки, проявляющейся во время эксплуатации системы. Устранение программных ошибок в редко используемых системных модулях мало повлияет на повышение безотказности системы. Устранение 60% программных ошибок только на 3% повысит безотказность системы. Это подтверждается и исследованиями ошибок в программных продуктах IBM. Многие ошибки в программных продуктах реально вызывают сбои системы после сотен или тысяч месяцев эксплуатации.
Следовательно, программа может содержать ошибки и все же вызывать доверие пользователей. Сбои программы "никогда не будут возникать, если не выбирать входных данных, ведущих к сбоям. Кроме того, опытные пользователи часто работают, зная об ошибках программного обеспечения, вызывающих сбои системы, и умело избегают их. Устранение ошибок в таких случаях не даст практически никакого повышения надежности.
Рис. 26.4. Использование множества входных данных разными пользователями
Каждый пользователь системы по-своему избегает "встречи" с системными ошибками. Ошибки, с которыми встречается один пользователь, могут никогда не встретиться другому. На рис. 26.4 показано множество входных данных, используемых разными пользователями. Входные данные, выбранные пользователем 2 пересекаются с входными данными, приводящими к сбою системы. Поэтому пользователь 2 будет сталкиваться со сбоями системы. Пользователи 1 и 3 никогда не используют входных данных, приводящих к сбою системы, – для них программное обеспечение всегда будет безотказно.