Время — деньги. Создание команды разработчиков программного обеспечения
Добавить в закладки К обложке
- Предисловие - Страница 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
• Задачи, которые чаще всего решают постоянные пользователи программы
Нужно постараться не разочаровать постоянных пользователей, безошибочно определив их ключевые задачи. Успех здесь даёт замечательный шанс удовлетворить потребности пользователей на долгое время. Соответственно следует сосредоточить основное внимание команды разработчиков на этих задачах, которые нужно максимально обогатить полезными возможностями, качественно реализовать и хорошо описать в документации.
Виды прототиповКогда основные задачи определены, всё готово к созданию прототипа пользовательского интерфейса. При этом очень важно выбрать инструмент, позволяющий создать прототип легко и быстро. Затем надо проверить свои варианты дизайна прототипа, разрешить все проблемы и вновь оперативно проверить результат. Познакомимся с наиболее популярными методиками создания прототипов и посмотрим, как с их помощью решать собственные проблемы. Вот эти методики по порядку, начиная с самой лучшей.
• Прототипы на бумаге
Для создания такого прототипа нужно просто нарисовать фрагменты пользовательского интерфейса на бумаге. Чтобы облегчить художникам и пользователям работу с таким прототипом, рисовать каждый элемент интерфейса надо на отдельном листе бумаги соответствующего размера. Расположите нарисованные меню, панели инструментов, командные кнопки, поля и другие элементы так, чтобы результат напоминал пользовательский интерфейс программы. Например, каждый раскрывающийся список и каждое диалоговое окно в этом случае будет на своём кусочке бумаги. Не обязательно добиваться точности воспроизведения — достаточно, чтобы эти кусочки бумаги давали чёткое представление об элементах пользовательского интерфейса.
Преимущество бумажных прототипов в том, что их легко собирать и изменять. Изолируя основные элементы интерфейса, можно легко изменить ход управления, условия работы, а также их расположение или размер. Нетрудно стирать линии или даже перерисовывать отдельные страницы или прототип целиком. Благодаря тому, что бумажные прототипы так легко менять, их можно обновлять и модифицировать прямо во время демонстрации конечным пользователям, это позволяет тут же проверять новые идеи.
Кроме того, бумажный прототип не страдает от проблем, связанных с программированием, установкой и других помех, неизбежных при разработке ПО. Это его преимущество, так как лучше тратить время на тестирование и доводку пользовательского интерфейса, а не на решение технических или механических проблем, связанных с его созданием.
С появлением более совершенных графических программ и инструментов для разработки стало проще создавать реальные изображения элементов интерфейса и распечатывать их на бумаге, чем рисовать их от руки. Следует выбирать тот или иной метод на основе личных предпочтений, поскольку важные преимущества есть у каждого из них: оба позволяют легко создавать и быстро доводить прототипы.
Из собственного опыта
Бумажные прототипы могут быть чрезвычайно эффективны, но если команда не верит в результативность этой методики, использовать её нельзя. Чтобы побороть эту проблему в NuMega, мы отправили всю команду на однодневный методический курс, который читали в институте UEI (Usability Engineering Institute). Особое внимание в этом курсе уделялось работе с бумажными прототипами. Это был замечательный способ продемонстрировать участникам команды, насколько важны и эффективны могут быть прототипы на бумаге. Этот курс изменил наши представления о разработке ПО.
• Инструменты RAD
Создание прототипов с помощью инструментов для быстрой разработки приложений (RAD, Rapid Application Development), — вероятно, самая популярная методика. Подходящим можно считать любой инструмент, позволяющий быстро создать наглядную функционирующую модель пользовательского интерфейса.
Одно из преимуществ инструментов RAD в том, что они позволяют создавать прототипы очень быстро (хотя бумажный прототип, как правило, делается быстрее). Ещё одно преимущество — реализм полученных прототипов. Многие думают, что прототипы, созданные с помощью RAD, обеспечивают более эффективное тестирование, чем бумажные, поскольку в первом случае тестированию подвергается настоящая программа. Однако программисты часто застревают на кодировании таких прототипов и напрасно теряют драгоценное время. Они пытаются довести прототип, улучшая его, а не реальный интерфейс. Другая проблема в сильном искушении перенести код прототипа прямо в рабочую программу, невзирая на его недостаточную проработанность и несовершенство дизайна.
- 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.