Время — деньги. Создание команды разработчиков программного обеспечения
Добавить в закладки К обложке
- Предисловие - Страница 1
- Благодарности - Страница 3
- Введение - Страница 4
- Часть 1Люди, организация и методы - Страница 8
- Определение «замечательных» - Страница 9
- Поиск и привлечение достойных кандидатов - Страница 12
- Общие проблемы и решения - Страница 15
- Глава 2Резюме, собеседование и удерживание сотрудников - Страница 16
- Анализ резюме - Страница 17
- Собеседование с кандидатом - Страница 19
- Удерживание сотрудников - Страница 23
- Типичные проблемы и их решение - Страница 24
- Глава 3Организация проекта - Страница 25
- Модель организационной структуры компании NuMega - Страница 26
- Управление проектом - Страница 27
- Роли и обязанности - Страница 29
- Типичные проблемы и их решение - Страница 35
- Глава 4Ранжирование сотрудников и корпоративная культура - Страница 36
- Ранжирование - Страница 37
- Корпоративная культура - Страница 40
- Типичные проблемы и их решение - Страница 43
- Глава 5Инструментальные программы - Страница 44
- Средства управления исходным кодом - Страница 45
- Устранение проблем и неисправностей - Страница 49
- Дополнительные средства - Страница 53
- Типичные проблемы и их решение - Страница 54
- Глава 6Основы системы контроля качества - Страница 56
- Основные принципы - Страница 57
- Что, когда и как тестировать - Страница 60
- Кто должен тестировать? - Страница 64
- Другие критичные моменты для контроля качества - Страница 66
- Типичные проблемы и их решение - Страница 68
- Глава 7Основы технологии разработки программ - Страница 70
- Технологи по разработке ПО - Страница 71
- Сборки - Страница 72
- Процедура установки - Страница 74
- Сбор всего вместе - Страница 76
- Типичные проблемы и их решение - Страница 77
- Часть 2Формулирование и планирование проекта. - Страница 78
- Центральная идея проекта - Страница 79
- Формулирование требований - Страница 80
- Анализ требований - Страница 83
- Определение приоритетов - Страница 85
- Утверждение требований - Страница 86
- Управление внесением изменений - Страница 87
- Общие проблемы и решения - Страница 88
- Глава 9Исследования, оценка технологий и моделирование - Страница 89
- Чем полезны исследования и прототипы - Страница 90
- Исследования - Страница 91
- Оценка технологий - Страница 94
- Моделирование - Страница 95
- Типичные проблемы и их решение - Страница 97
- Глава 10Пользовательский интерфейс - Страница 98
- Прототип пользовательского интерфейса - Страница 99
- Роль специалиста по инженерной психологии - Страница 103
- Типичные проблемы и их решение - Страница 105
- Глава 11Планирование - Страница 106
- Предпосылки - Страница 107
- Основные понятия и трудности планирования - Страница 108
- Как составить хороший план - Страница 112
- Типичные проблемы и их решение - Страница 115
- Часть 3Исполнение проекта - Страница 116
- Анология с самолётом - Страница 117
- Процесс измерений и мониторинга состояния проекта - Страница 118
- Внесение изменений - Страница 121
- Общие проблемы и решения - Страница 125
- Глава 13Бета-тестирование - Страница 126
- Ценность бета-тестирования - Страница 127
- Самая распространённая ошибка при проведении бета-тестирования - Страница 128
- Типы программ бета-тестирования - Страница 129
- Элементы программы бета-тестирования - Страница 130
- Набор бета-тестеров - Страница 131
- Менеджер бета-тестирования - Страница 134
- Общие проблемы и решения - Страница 135
- Глава 14Кандидат на выпуск - Страница 136
- Начальные требования - Страница 137
- Тестирование кандидата на выпуск - Страница 138
- Общие проблемы и решения - Страница 141
- Глава 15Закрытие проекта - Страница 142
- Почему это так важно? - Страница 143
- Как это делается? - Страница 144
- Что дальше? - Страница 146
- Общие проблемы и решения - Страница 148
- Об авторе - Страница 149
Формулирование требований
Когда установлено общее видение проекта и достигнуто понимание пользовательских проблем, пора переходить к определению требований. Как сформулировать требования, насколько подробными должны быть формулировки и как ничего не упустить?
Общие и частные требованияОдин из лучших способов дать чёткое описание набора требований к проекту — представить его в виде схемы. Самый высокий уровень схемы занимают общие требования. Они объединяют совокупности частных требований, которые, таким образом, можно обсуждать, оценивать, сравнивать и утверждать как единое целое. Нужно иметь возможность анализа общих требований и обладать совершенным пониманием их основных целей. Общих требований не должно быть слишком много, так как каждое в свою очередь генерирует ряд второстепенных требований. Например, в случае компании, которой надо адаптировать имеющееся приложение обработки заказов для работы в Интернете, достаточно пяти общих требований:
• разработать интерфейс на базе браузера;
• повысить производительность до уровня, приемлемого для Web-пользователей;
• организовать рассылку уведомлений о выполнении заказов по электронной почте;
• добавить к программе новые возможности, которые повысят производительность пользователей;
• предусмотреть применение в будущем в качестве клиентской платформы карманных компьютеров.
Каждое общее требование должно подразделяться на несколько частных. С последними могут быть связаны и другие требования, конкретизирующие или поясняющие функциональность требований более высокого уровня. В результате документация может принять такой вид:
• Общее требование 1
•• Частное требование 1
••• Частное требование нижнего уровня 1.1
••• Частное требование нижнего уровня 1.2
•• Частное требование 2
••• Частное требование нижнего уровня 2.1
••• Частное требование нижнего уровня 2.2
Ниже приводится пример некоторых общих и частных требований, организованных в соответствии с вышеописанной структурой.
• Разработать интерфейс на базе браузера для приложения по обработке заказов.
• Функциональные требования.
•• При размещении заказа:
••• Ввести для каждого заказа следующую информацию (по пунктам).
••• Проверить идентификатор покупателя.
•• Удалить заказ.
•• Проверить статус заказа.
•• Сгенерировать подтверждение заказа.
• Обеспечить поддержку следующих браузеров:
•• Microsoft Internet Explorer версии X.
•• Netscape версии Y.
• Производительность должна быть приемлема для Web-пользователя.
• Требования ко времени реакции системы:
•• Размещение заказа должно занимать менее 3 секунд.
•• Удаление заказа должно занимать менее 6 секунд.
•• Проверка статуса заказа должна занимать менее 4 секунд.
•• Подтверждение заказа должно занимать менее получаса.
• Облегчить использование приложения с помощью новых возможностей:
•• Разрешить заказ нескольких товаров в одном заказе.
•• Разрешить пользователю просмотр его идентификатора покупателя.
Как видно из этого примера, каждое общее требование включает набор поддерживающих его требований, которые конкретизируют или разъясняют содержание «родительского». Каждое поддерживающее требование сформулировано просто и ясно, что позволяет легко проследить его реализацию в данном выпуске ПО. Следует расширять степень детализации спецификации требований, пока не будут описаны все ключевые элементы функциональности и вы не останетесь довольны созданным описанием.
Полнота требованийОпределение требований должно быть полным. Рассмотрите все аспекты нового выпуска, даже те, что нельзя свести к набору частных требований. Далее приводится список общих категорий требований, применимый практически ко всем проектам по созданию программ. Я не предлагаю использовать этот список в том виде, в каком он представлен здесь, хотя возможно и такое; однако при составлении собственного списка требований рассмотрите каждую из следующих категорий.
• Задачи и функции проекта
Каждый участник должен понять ключевые задачи и функции проекта, прежде чем приступать к работе. Эти задачи и функции составляют сущность программного продукта и будут направлять его разработку, а также работу по тестированию и обучению пользователей.
• Пользовательский интерфейс
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
В конце февраля 2009 года в продаже на Amazon появилось долгожданное устройство для чтения электронных книг Kindle 2. Это событие вызвало бурю негодов
Электронная читалка - вещь очень хрупкая. Если с ней обращаться не правильно - она может сломаться. Чтобы этого не случилось, нужно придерживаться лиш
Большинство книг в сети интернет распространяется в формате FB2 (Fiction Book). Этот формат очень удобен для чтения. Файлы, в нем созданные, отличаютс
Популярность электронных книг у читателей неуклонно растет. Для доказательства этого мы провели маленький эксперимент. Из 10 людей, читающих в метро,
Файлы формата FB2 часто можно увидеть среди огромнейшего разнообразия текстовых форматов. Такая высокая популярность объясняется его предназначением.
Первую версию формата PDF (Portable Document Format) еще в 1993 году разработала фирма Adobe Systems. В 2006 году она уже разработала версию 1.7, а с
Фирма Apple порадовала пользователей iPad, выпустив под него красивую и удобную читалку iBooks.