
- •З курсу
- •З курсу
- •Содержание
- •Часть 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. Классификация процессов совершенствования
23. Управление персоналом
Люди, работающие в компаниях по разработке ПО, являются их самым ценным "активом". Именно они представляют интеллектуальный капитал, и от менеджеров по разработке ПО зависит, получит ли компания наилучшие из возможных дивиденды от инвестиций в человеческие ресурсы. В успешно развивающихся компаниях и экономических структурах это достигается в том случае, если организация уважает своих сотрудников. Круг выполняемых ими обязанностей и уровень вознаграждения должны соответствовать их умению, которое, в свою очередь, зависит от квалификации.
Таким образом, эффективный менеджмент – это эффективное управление персоналом компании. Менеджеры – руководители проектов должны решать как технические, так и далекие от технических вопросы, используя при этом членов команды с оптимальной эффективностью. Они должны уметь мотивировать действия людей, организовывать их работу и гарантировать ее качественное исполнение. Слабый менеджмент персонала – одна из основных составляющих провала программных проектов.
В своих рассуждениях я опираюсь в основном не на принятые в наше время модные модели теории менеджмента, а на два фактора – познавательный и социальный. Процесс разработки ПО включает в себя познавательный и социальный процессы, поэтому именно эти факторы я считаю самыми важными в углублении понимания того, как создаются программы. Если у менеджеров есть понятие об этих основах, тогда они лучше управляют людьми, получая наибольшую отдачу.
23.1. Пределы мышления
Человеческие возможности достаточно разнообразны, и это прежде всего зависит от уровня интеллекта, образования и личного опыта, однако у всех нас есть нечто общее: в своей умственной деятельности мы подчиняемся определенным ограничениям. Эти ограничения не что иное, как следствие того, каким образом наш мозг сохраняет и обрабатывает полученную информацию. Нам вовсе не обязательно подробно изучать процесс обработки информации об окружающем мире человеческим мозгом. Однако я считаю, что знание границ нашего мышления имеет исключительную важность. Именно эти знания помогут выяснить, почему некоторые технологии разработки программного обеспечения достигают высокой эффективности, а также проникнуть вглубь взаимоотношений между членами команды разработчиков ПО.
23.1.1. Организация человеческой памяти
Программные системы представляют собой абстрактные объекты, при работе с которыми разработчикам необходимо учитывать все их особенности. К примеру, программист должен понимать и всегда помнить о взаимосвязи между листингом исходного кода и динамическим поведением программы. Эти знания будут полезны ему и при разработке программ в дальнейшем.
Организацию человеческой памяти можно представить в виде иерархической структуры с тремя отчетливыми, связанными между собой типами памяти (рис. 23.1).
1. Кратковременная память с быстрым доступом, но ограниченными возможностями. Вводный сигнал, порождаемый органами чувств, поступает именно сюда для дальнейшей обработки. Такую память мы можем сравнить с регистрами в вычислительной машине, так как она является местом обработки информации, а не ее хранения.
2. Промежуточная память с высокими возможностями. Доступ к такой памяти более труден, нежели к кратковременной. Она тоже служит для обработки информации, однако может удерживать информацию на более долгий срок, чем кратковременная память. Она не используется для сохранения информации, предназначенной для более длительного хранения. По аналогии с компьютером такая память напоминает оперативную, в которой информация сохраняется только на период вычислительных операций.
3. Долговременная память. Это память с самыми широкими возможностями, относительно трудным доступом и крайне ненадежными механизмами хранения (мы забываем иногда некоторые вещи). Такая память используется для "постоянного" хранения информации. Продолжая наше сравнение с компьютерной памятью, можем соотнести долговременную память с дисковыми накопителями.
Рис. 23.1. Схема организация человеческой памяти
Кратковременная память получает информацию о поставленной перед человеком задаче через чтение (человеком) различных документов и контакты с другими людьми. Далее полученная информация, составив единое целое с уже существующими данными в долговременной памяти, поступает в промежуточную память. Именно результат формирования этого целого и составляет основу решения поставленной задачи. Все это заносится в долговременную память с тем, чтобы использоваться в будущем. Никто не говорит, что решение обязательно должно быть верным. Со временем, после поступления новой информации, долговременная память изменяется. Несмотря на это, неверная информация никоим образом не удаляется, а наоборот, сохраняется в видоизмененной форме. Ведь учимся же мы на собственных ошибках.
Наш познавательный процесс в некоторой степени сдерживается ограниченным размером кратковременной памяти. В классическом эксперименте Миллер определил, что в кратковременной памяти может храниться около семи квантов информации. Квант информации не составляет твердо фиксированной величины, это, скорее, определенная информационная единица, которой может быть телефонный номер, сформулированная цель или название улицы. Миллер также дает описание процесса "образования блоков", во время которого кванты информации собираются в целые блоки.
Если постановка задачи содержит больше информации, чем тот объем, с которым может справиться кратковременная память, тогда эта информация будет обрабатываться и преобразовываться параллельно поступлению. Такой процесс может привести к потере информации. Также велика возможность возникновения ошибок, так как обработка информации не успевает за ее поступлением в память.
Шнейдерман предполагает, что процесс формирования блоков информации используется и при чтении программы программистом. Читающий разбивает содержащуюся в программе информацию на блоки, построенные по принципу внутренней семантической (смысловой) структуры. Восприятие программы не происходит последовательно от оператора к оператору, если только оператор не представляет собой логический блок. На рис. 23.2 показано, как простая программа сортировки может быть разбита на блоки читающим ее субъектом.
Рис. 23.2. Познавательные блоки в программе сортировки
После определения внутренней семантической структуры, представляющей программу, эти знания передаются в долговременную память. Если эта информация потребляется регулярно, то обычно ее трудно забыть. Без особого труда такую информацию можно воспроизвести в различных формах представления. Поэтому нам легче запомнить абстрактные конструкции высокого уровня, чем подробности низкого уровня.
Знания, которые приобретаются в процессе разработки ПО и сохраняются в долговременной памяти, разделяются на два класса.
1. Семантические знания. Это знания об основных понятиях, таких, например, как функционирование оператора присвоения, представление о классе объектов, о технике хешированного поиска или о структуре организации программ. Эти знания приобретаются через опыт и обучение и сохраняются в форме автономных представлений.
2. Синтаксические знания. Это детализированные знания (подробности) об отдельных объектах и явлениях, например о том, как дать описание объекта в UML, какие стандартные функции доступны в языке программирования, создается ли оператор присвоения с помощью знака "=" или знака ":=" и т.д. Эти знания хранятся в неструктурированном виде.
Такая организация знаний показана на рис. 23.3, который был заимствован (и переделан) из книги по проектированию интерфейсов пользователя. Здесь предполагается, что семантические знания и знания о решаемой задаче имеют свою организацию и структуру, которые показаны на схеме в виде логической структуры взаимосвязей между различными фрагментами знаний. В противовес семантическим знаниям, синтаксические являются произвольными (в определенной мере) и не имеют четкой организации. Поэтому именно для данного типа знаний более вероятны ошибки и потеря информации.
Рис. 23.3. Синтаксические и семантические знания
Семантические знания приобретаются с помощью опыта и путем активного обучения. Новая информация сознательно интегрируется с уже существующими семантическими структурами. Напротив, синтаксические знания приобретаются путем простого запоминания. Хотя новые синтаксические знания не объединяются с существующими в тот же момент, однако могут с ними взаимодействовать. Следовательно, эти знания забываются чаще, чем более углубленные семантические.
Различные модели приобретения синтаксических и семантических знаний помогают понять, как опытные программисты изучают новый язык программирования. У них не возникает особых трудностей в освоении основных понятий языка, таких, как присвоение, цикл, условные операторы и т.п. Синтаксис нового языка, тем не менее, имеет тенденцию смешиваться с синтаксисом уже знакомых языков. Поэтому программист, владеющий языком Ada, при изучении языка Java напишет оператор присвоения скорее с использованием знака ":=", чем "=".
По мере более глубокого освоения основные понятия закрепляются в памяти как семантические знания. Семантические знания сохраняются в памяти в абстрактной смысловой форме, но детали основных понятий могут быть воспроизведены в различных конкретных представлениях.
Для примера рассмотрим алгоритм двоичного поиска, в котором осуществляется поиск конкретного элемента в упорядоченной совокупности. Этот алгоритм включает проверку средней точки совокупности и применение знаний о взаимоотношении порядка для проверки местонахождения элемента-ключа – в верхней или нижней части совокупности. Программист, знакомый с этим алгоритмом, без труда напишет его версию на языках Java, Ada или на любом другом языке программирования.
Эта модель хорошо объясняет и тот факт, что для многих людей умение программировать приходит как бы одним махом, после долгого периода обучения и трудностей. Умение программировать требует от человека понимания семантических концепций и способности разделять семантические и синтаксические понятия. Иногда преподавателям не удается понять проблемы студентов. Сами они успешно разобрались в семантической информации и осмыслили ее, поэтому для них главная задача состоит в обработке синтаксической информации. Поэтому часто преподавателю бывает сложно объяснить семантические понятия на таком уровне, чтобы это было доступно и новичкам в программировании.