Технологии программирования - Wiegers.Software R. Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция , 2004. ил. Isbn 5-7502-0240-2 Эта книга
 Скачать 37.95 Mb.
| Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
Полное содержание архива WinRAR ZIP archive.zip: Разработка требований к программному обеспечению Практические приемы сбора требований и ими при разработке программного продукта Карл И. Вигерс Дважды лауреат Software Development Productivity Award Посвящается Крис Software Requirements Second Edition Practical techniques for gathering and managering requirements throughout the development cycle Karl E. Wiegers Two-time winner of the Software Productivity Award Press Разработка требований к программному обеспечению Практические приемы сбора и управления ими при разработке программного продукта Карл И. Вигерс лауреат Software Development Productivity Award Москва 2004 УДК 004.45 В41 Карл Разработка требований к программному с англ. — М.: дом «Русская Редакция», 2004. ил. ISBN 5-7502-0240-2 Эта книга посвящена разработке качественных требований к продукту, Здесь описаны дюжины проверенных на практике способов выявления, фор- мулирования, разработки, проверки, утверждения и тестирования требова- ний к ПО, которые помогут разработчикам ПО, менеджерам и маркетологам создать эффективное ПО. Это перевод второго издания оригинальной книги, которое новыми главами о роли аналитика требований, а также о том, как формулирование требований важно для проектов по обслуживанию, для комплексных решений и проектов, разраба- тываемых сторонними организациями. Основная аудитория — аналитики требований и разработчики продукта, а также дизайнеры, программисты, тестеровщики ПО и другие члены коман- ды , задача которых понять и удовлетворить чаяния клиентов, а также маркето- логи, менеджеры по продуктам и менеджеры проекта, которые должны про- никнуться «духом» и особенностями продукта, чтобы сделать его в полной ме- ре конкурентоспособным. Книга состоит из 23 глав, 4 приложений, терминов и библиогра- фического списка. УДК 004.45 к изданию по лицензионному договору с Microsoft Corporation, Вашингтон, США. Microsoft, Microsoft Press, Visual Basic и Windows являются товарными знаками или охраняемыми товарными знаками корпорации в США и/или странах. Все другие товарные знаки являются собственностью фирм. Все названия компаний, организаций и продуктов, а также имена лиц, используемые в примерах, и не имеют отношения к реальным компаниям, органи- продуктам и лицам. ISBN (англ.) ISBN © Оригинальное на английском языке, 2003 © Перевод на русский язык, Microsoft Corporation, 2004 © Оформление и подготовка к изданию. дом "Русская 2004 Содержание Предисловие xiii Что дает эта книга xiv Кому предназначена эта книга Краткий обзор xv Примеры из практики От принципов - к практике Благодарности Часть I. Требования к продукту: что, почему и кто Глава Особенности разработки требований к ПО 2 Оговоренные требования к ПО Особенности интерпретации требований G Уровни требований Каких требований не должно быть Разработка и управление требованиями Разработка требований Управление Каждый проект имеет требования 14 Когда плохие требования появляются у хороших людей Недостаточное вовлечение пользователей 17 «Разрастание» требований пользователей 17 Двусмысленность требований «Золочение» продукта Минимальная спецификация 19 Пропуск классов пользователей 19 Небрежное планирование 20 Выгоды от высококачественного процесса разработки требований 20 Характеристики превосходных требований 22 Характеристики отдельных положений спецификации требований 22 Характеристики спецификации требований 24 Глава 2. Требования с точки зрения клиента 26 Кто же клиент? 28 Сотрудничество клиентов и разработчиков 30 Билль о правах клиента ПО 32 Билль об обязанностях клиента ПО 35 Что насчет подписи? 38 Глава 3. Хорошие приемы создания требований 41 Обучение 43 Выявление требований 45 Анализ требований 47 Спецификации требований 50 Проверка требований 51 Управление требованиями 52 Управление проектом 54 Начинаем применять новые приемы 56 Процесс создания требований 58 Глава 4. Аналитик требований 62 Роль аналитика требований 62 Задачи аналитика 64 необходимые аналитику 67 Знания, необходимые аналитику 69 Становление аналитика 70 Бывший пользователь 70 Бывший разработчик 71 Профильный специалист 72 Создание атмосферы тесного сотрудничества 72 Часть II. Разработка требований к ПО 75 Глава 5. Определение образа и границ проекта 76 Определение образа продукта вплоть до бизнес-требований 77 Конфликтующие бизнес-требования 78 Бизнес-требования и варианты использования 79 vi Содержание Документ об образе и границах проекта 80 Бизнес-требования 82 2. Образ решения 84 3. Масштабы и ограничения проекта 85 4. Бизнес-контекст 87 Контекстная диаграмма 90 Не упускайте границы из вида 91 Глава 6. Как отобрать пользователей для работы над проектом 94 Основные источники информации о потребностях клиентов 95 Классы пользователей 97 Представители пользователей Сторонники продукта 1СЗ Сторонники продукта, приглашенные со стороны Чего следует ожидать от сторонника продукта На что способны несколько сторонников продукта Как «продать» идею о необходимости привлечения сторонника продукта В какие ловушки можно угодить, привлекая сторонников продукта Кто принимает решения Глава 7. Как услышать голос клиента Выявление требований Польза семинаров Несколько советов о том, как собирать информацию Поиск упущенных требований Как что сбор требований завершен 1 1 Глава 8. Как понять требования пользователей Подход с применением варианта использования продукта Варианты использования и сценарии использования 137 Определение вариантов использования Документирование вариантов использования 143 Варианты использования продукта и функциональные требования Преимущества способа с применением вариантов использования 153 Каких ловушек следует опасаться при способе с применением вариантов использования Таблицы «событие - реакция» Содержание v Глава 9. Игра по правилам Правила бизнеса 163 Факты Ограничения 164 Активаторы операций 165 Выводы 166 Вычисления 167 Документирование бизнес-правил и требования 170 Глава 10. Документирование требований Спецификация требований к ПО Требования к именованию 178 Когда информации недостаточно 180 интерфейсы и спецификация требований к ПО Шаблон спецификации требований к ПО Введение 2. Общее описание 185 3. Функции системы 4. Требования к внешнему интерфейсу 5. Другие нефункциональные требования 190 6. требования Приложение А. Словарь терминов Приложение Б. Модели анализа 193 Приложение В. Список вопросов 193 Принципы создания требований Примеры требований: до и после 198 Словарь данных 203 Глава Любое изображение стоит слов 206 Моделирование требований 207 От желания клиента к модели анализа 209 Диаграмма потока данных Диаграмма - связь» Диаграмма перехода состояний Карта диалогов 222 Диаграмма классов 226 Таблицы решений и деревья решений 229 Последнее 231 viii Содержание Глава Обратная сторона функциональности: атрибуты качества ПО 232 Атрибуты качества 234 Определение атрибутов качества Атрибуты, важные для пользователей 237 Атрибуты, важные для разработчиков Требования к производительности Определение нефункциональных требований с помощью языка Компромиссы для атрибутов Реализация нефункциональных требований Глава Прототипы как средство уменьшения риска 253 Что такое прототип и для чего он нужен 254 Горизонтальные прототипы 255 Вертикальные прототипы 25(5 Одноразовые прототипы 257 Эволюционные прототипы 25!3 Бумажные и электронные прототипы 261 Оценка прототипа 263 Риски Факторы успеха прототипирования 266 Глава Назначение приоритетов требований 269 Зачем определять приоритеты требований 270 Игры, в которые люди играют с приоритетами 271 Шкала приоритетов 273 Определение приоритетов на основе ценности, стоимости и риска 274 Глава 15. Утверждение требований 283 Просмотр требований 287 Проведение экспертизы 288 Проблемы при просмотре требований 298 Тестирование требований 300 Определение критерия приемлемости 306 Глава Проблемы при разработке специальных требований ЗС D Требования к проектам по обслуживанию 309 Начните сбор информации Применяйте новые приемы работы с требованиями Перемещайтесь по цепочке трассируемое™ Обновляйте документацию Содержание ix Требования для пакетных решений Разработка вариантов использования 316 Работа с Определение требований к качеству Требования к выполняемым сторонними организациями 319 Требования для принципиально новых проектов 321 спецификация пользовательских требований 323 Присутствие клиента 323 Периодическая расстановка приоритетов на ранних стадиях 324 Простое управление 324 Глава От требований — к следующим этапам 326 От требований - к планам проекта 327 Требования и расчеты 329 Требования и график 332 От требований - к дизайну и коду 333 От требований - к тестированию 337 От требований - к успеху 339 Часть III. Управление требованиями к ПО 341 Глава 18. Принципы и приемы управления требованиями к ПО 342 Базовая 344 Процедуры управления требованиями 345 Контроль версий 346 Атрибуты требований 348 Контроль статуса требований 351 Измерение усилий, необходимых для управления требованиями 353 Глава Изменения случаются 356 Управление незапланированным ростом объема 358 Процесс контроля изменений 360 Политика контроля изменений 361 Описание процесса контроля изменений 362 Совет по управлению изменениями 369 Состав совета по управлению изменениями 370 Устав совета по управлению изменениями 370 Средства контроля измений 372 Измерение активности 373 Изменение не бесплатно: анализ 376 Процедура анализа влияния изменения 377 Шаблон отчета об влияния изменения Содержание Глава 20. Связи в цепи требований 384 требований Мотивация для трассируемое™ требований Матрица трассируемое™ требований Средства трассирования требований Процедура трассирования требований Осуществимость и необходимость трассирования требований 397 Глава Инструментальные средства управления требованиями 399 Преимущества инструментальных средств управления требованиями Возможности инструментальных средств управления требованиями Реализация автоматизации управления требованиями 407 Выбор инструментального средства Изменение культуры работы Как заставить инструментальные средства работать Часть IV. Особенности реализации процесса построения требований Глава 22. Совершенствование процессов работы с требованиями Как требования связаны с другими составляющими проекта Требования и различные заинтересованные в проекте группы Основы совершенствования процессов разработки ПО 420 Цикл совершенствования технологических процессов 423 Оцените текущие технологические процессы 423 Создайте план совершенствования Создайте, опробуйте и реализуйте новые процессы 426 Оцените результаты 427 Образцы документов для процессов конструирования требований 42!) Образцы документов для разработки требований Образцы документов для управления требованиями Дорожная карта совершенствования работы с требованиями Глава 23. Требования к ПО и управление риском 436 Основы управления риском при создании ПО 433 Составляющие управления риском 439 Документирование рисков проекта 440 Планирование управления риском 443 Содержание Риск, связанный с требованиями 444 требований 445 Анализ требований 446 Спецификация требований 447 Утверждение требований 448 Управление требованиями 448 Управление риском - ваш друг 449 Эпилог 451 Приложение А. Самостоятельная оценка применяемых вами приемов работы с требованиями 453 Приложение Б. Модели совершенствования требований и технологических процессов 461 The Capability Maturity Model for Software 461 465 Приложение В. Руководство по поиску и решению связанных с требованиями Анализ основных причин 470 Общие симптомы проблем, связанных с требованиями 471 Общие препятствия для реализации решений 472 Приложение Г. Примеры документации требований 495 Документ об образе и границах проекта 496 Варианты использования 503 Спецификация требований к ПО 510 Приложение А. Словарь и модель данных 521 Приложение Б. Модели анализа 525 525 Словарь терминов 528 Библиографический список 540 Об авторе 554 Содержание Предисловие Несмотря на более чем пятидесятилетнее существование компьютер- ной отрасли, многие компании — разработчики программного обеспе- чения по-прежнему прикладывают значительные усилия для сбора документирования требований к ПО, а также управления ими. Недоста- точный объем информации, поступающей от пользователей, требова- ния, сформулированные не полностью, их кардинальное изменение — вот основные причины, из-за которых зачастую командам, щим в области информационных технологий, не удается вовремя и рамках бюджета клиентам всю запланированную Многие разработчики не умеют спокойно и нально собирать требования пользователей к ПО. У клиентов зачастую не хватает терпения участвовать в разработке требований к ПО, или они норовят передать свои пожелания через совершенно щих для этого дела людей. Иногда участники проекта даже не прийти к единому мнению, что же такое «требование». Как заметил один писатель, «программисты скорее предпочтут расшифровать ва классической песни Кингсмена (Kingsmen) «Louie Louie», чем требо- вания Разработка ПО включает по крайней мере столько же сколько и обычная работа с компьютером, но зачастую мы делаем цент на работе с компьютером и не уделяем достаточно общению. В этой книге описаны дюжины способов, позволяющих реа- лизовать это общение и помогающих разработчикам ПО, менеджерам, маркетологам и клиентам использовать на практике эффективные Исследование «CHAOS Report», проведенное компанией Group International, 1995. Peterson, Gary. Статья «Risque Requirements» в апрельском номере журнала CrossTalk за xt методы формулирования требований к ПО. Настоящее издание допол- нено новыми главами, посвященными роли аналитика требований, важности бизнес-правил, а также рассказом о том, как формулирова- ние требований важно для проектов по обслуживанию, для комплекс- ных решений, для извлечения данных из внешних источников и новых проектов. Во многочисленных врезках я привожу реальные иллюстрирующие типичные ситуации, возникающие при формулиро- вании требований. В книге описаны основные «отличные способы» формулирования требований, а не экзотичные или тщательно разработанные методоло- гии, обещающие решить все проблемы, возникающие при формули- ровании требований. С тех пор, как в 1999 г. вышло первое издание этой книги, я провел свыше семинаров, посвященных формулиро- ванию требований к для сотрудников коммерческих и правитель- ственных организаций всех толков. Я понял, что эти способы годятся практически для любого проекта, включая развертываемые частями, маленькие проекты и крупномасштабные гиганты, а также те, что раз- рабатываются «с нуля», и проекты по обслуживанию. Кроме того, эти способы не ограничиваются только областью разработки ПО, и вполне годятся для проектирования оборудования и систем. Как и в случае с любыми другими способами разработки ПО, чтобы понять, какие из способов формулирования требований подходят вам более всего, следует руководствоваться здравым смыслом и опираться на собст- венный опыт. Что дает эта книга Из всех возможных способов совершенствования процесса разработ- ки ПО наибольшее преимущество за формулированием требований. Я уделяю особое внимание описанию проверенных на практике спосо- бов, которые помогут вам: 1 повысить качество требований к проекту на ранней стадии цикла что позволит снизить число доработок и повысить про- изводительность; 1 соблюдать расписание, контролируя область действия и требований; I снизить затраты на обслуживание и поддержку. Моя цель — помочь вам усовершенствовать процессы сбора и ана- лиза требований, написания и оценки спецификаций, определяющих требования, а также процессы управления требованиями на протяже- нии всего цикла разработки продукта. вы на самом деле ста- нете применять усовершенствованные способы, а не просто прочтете о них. Изучить новые способы легко; значительно труднее изменить привычку людей работать так, а не иначе. Кому предназначена эта книга Она для тех, кто так или иначе вовлечен в сбор и формулирование бований к программному продукту. Основная аналитики требований и разработчики продукта независимо от того, работаю" они полный день или привлекаются к проекту время от времени. широкий круг читателей — дизайнеры, программисты, тестеры ПО и другие члены команды, задача которых понять и удовлетворить клиентов, а также маркетологи и менеджеры по продуктам, должны проникнуться «духом» и особенностями чтобы лать его в полной мере конкурентоспособным. Менеджеры отвечающие за своевременный выпуск, также найдут здесь для себя немало интересного: они узнают, как управлять показателями, с требованиями к проекту, а также реагировать на этих требований. Еще один сегмент аудитории — клиенты, которые жаждут высказать свои пожелания о создаваемом продукте. Настоя книга поможет им понять роль процесса формулирования ваний и их место в этом процессе. Краткий обзор Книга состоит из четырех частей. Первая часть «Требования к почему и кто» начинается с ряда определений и описания характеристик требований, которые считаются качественными. ли вы занимаетесь техническими вопросами, надеюсь, вы главы 2, посвященной взаимодействию клиентов и раз- работчиков, со своими ключевыми клиентами. В главе 2 описано сколько дюжин хороших приемов создания и управления ми, а также процесс формулирования требований в целом. Глава 4 по- священа роли аналитика требований. Вторая часть «Разработка требований к ПО» начинается с описания способов для определения бизнес-требований к проекту. Другие вы этой части посвящены тому, как правильно выбрать Предисловие лей клиента, узнать у них требования и задокументировать варианты использования, бизнес-правила, функциональные требования и атри- буты качества. В главе обсуждается несколько моделей анализа, представляющих требования с разных точек зрения, в главе — при- менение прототипов ПО, позволяющих снизить риск выпуска продукта ненадлежащего качества. Прочие главы посвящены расстановке при- оритетов и оценке требований. Завершается вторая часть описанием особенностей формулирования требований для нескольких конкрет- ных проектов и рассказом о том, как требования влияют на другие ас- пекты работы над проектом. В третьей части «Управление требованиями к ПО" речь пойдет о прин- ципах и способах управления требованиями, особое внимание уделяет- ся позволяющим реагировать на изменение требований. В главе 20 рассказано, как отслеживать изменение требований с го начала до их реализации в продукте. Третья часть завершается санием коммерческих утилит, расширяющих возможности управления требованиями к проекту. Заключительная часть книги «Особенности реализации процесса построения требований» поможет вам перейти от теории к практике. В главе 22 как включить новые способы формулирования требований в действующий процесс разработки. Глава 23 посвящена рискам, связанным с требованиями к проекту. Приложение А вам оценить применяемые способы формулирования требований и ределить области, требующие совершенствования. В прочих ниях представлены руководство по устранению проблем, возникающих при формировании требований, а также примеры ных требований к проектам. Примеры из практики Методы, описанные в книге, я иллюстрирую примерами, за основу ко- торых взяты реальные проекты; это касается и информационной сис- темы среднего размера под названием Chemical Tracking System. (He волнуйтесь — чтобы разобраться в этом проекте, знание химии вам не потребуется.) Диалоги участников проектов из примеров разбавляют текст книги. Думаю, вне зависимости от того, что за ПО разрабатывает ваша команда, вы найдете эти диалоги интересными и полезными, Предисловие От принципов - к практике Трудно сколько энергии потребуется на мешающих изменению и практическому применению но- вых знаний. оставаться в комфорта, которая знакомыми — если не сказать, не всегда эффективными — собами разработки. Чтобы облегчить вам применение новых на практике, каждую главу я заканчиваю разделом гдз перечислены конкретные действия, которые вы можете выполнить отношении реального проекта. На моем Web-узле simpact.com вы найдете аннотированные шаблоны документов для ределения требований, контрольные списки проверки, таблицу оритетов требований, описание процесса контроля изменений, а так- же полезные вещи для многих других процессов. Используйте эти териалы, чтобы применять полученные значения на практике. Начните с небольших усовершенствований, но — именно сегодня, не отклады- вая на завтра. Отдельные участники проекта с большой неохотой возьмутся за применение новых способов формулирования требований. Некоторь е люди откровенно и если вы имеете дело именно с та- кими людьми, описанные здесь способы работать не будут. Исполь- зуйте материал книги для обучения коллег, клиентов и Напоминайте им о связанных с требованиями проблемах, возникав- ших при работе над предыдущими проектами, и обсуждайте альные преимущества использования новых способов. Не обязательно запускать новый проект, чтобы начать применять усовершенствованные способы формулирования требований. В гла- ве 16 рассказывается, как использовать описываемые в книге способы в проектах по обслуживанию. Постепенное внедрение новых бов — сопряженный с незначительным риском подход к совершенст- вованию процесса который подготовит вас к комплексно- му использованию новых способов при работе над следующим круп- ным проектом. Цель — сформулировать требования, которые позволят проектиро- вать приложения с приемлемым уровнем риска. Потратив на это дос- таточно времени, вы можете быть что свели к минимуму риск переделки продукта, создания негодного ПО или срыва сроков сдачи проекта. Эта книга научит как объединить усилия нужных людей для разработки качественных требований к нужному продукту, Предисловие Благодарности Выражаю глубокую благодарность людям, не поленившимся просмотреть руко- пись этой книги и предложившим бесчисленные рекомендации по совер- шенствованию ее текста. Рецензенты первого издания — Стив Адольф (Steve Никки (Nikki Bianco), Билл Дэгг (Bill Dagg), Дейл Эмери (Dale Крис Фальбуш (Chris (Geoff Flamank), Линда Флеминг (Lynda Кэти Джим Харт (Jim Hart), Тэмми (Tammy Майк Малек (Mike endra Майк (Mike Фил Рекио (Phil Recchio), Кэти Род (Kathy Rhode), Джоанна Ротман (Johanna Rothman), Джойс (Joyce Statz), Дорис (Doris Пракаш (Prakash Up- и Скотт Витмайр (Scott Что касается настоящего, издания, то я высоко ценю Стива Адольфа (Steve Adolph), Росса Колларда (Ross Ричарда Дальтона (Richard Dalton), Криса Фальбуша (Chris Fahl- Линды Флеминг Fleming), Элен (Ellen Линды Льюис (Linda Lewis), Джеффа Пинка (Jeff Pink), Эрика Симмонса (Erik Sim- mons), Дэвида Standerford), Дэниса Стефенсона (Dennis Stephenson), Скотта (Scott Whitmire), Ребекки Вирш-Брок (Rebecca и Триши Цвирнбаум (Trish Спасибо сотрудникам Microsoft Press, принявшим участие в работе над пер- вым изданием этой книги, в том числе редакторам Бену Раину (Ben Ryan), Джону Пирсу (John Pierce), Мэри Колбах Барнард Barnard), Мишель Гудман (Michelle Goodman), Робу Нэнсу (Rob Nance) и Поле Горлик (Paula Gorelick). За работу над вторым изданием благодарю (Danielle Bird), Томаса Польмана (Thomas Pohlmann), Масгрейва (Devon Mus- Санди Резник (Sandi Resnick), художника Майкла Клопфера Kloepfer) и наборщицу Джину Кассил (Gina Cassill). Значительную помощь мне оказали и слушатели семинаров по формулированию требований к ПО, за по- следние несколько лет они завалили меня предложениями и рекомендациями. Пожалуйста, пишите мне по адресу и делитесь со мной опытом. Выражаю глубочайшую признательность Крис Замбито (Chris Zambito) самой веселой, самой терпеливой и самой заботливой жене, о какой писатель может только мечтать. Благодарности Особенности разработки требований к ПО «Привет, Фил, это Мария из отдела персонала. нас проблема с системой, которую вы разрабатывали для нас. Одна из со- трудниц изменила имя на Старлайт, а система не прини- мает это изменение. Ты можешь помочь?» Юна вышла замуж за парня по имени Старлайт?» она просто взяла другое имя, — ответила Мария. — В этом-то и проблема. Как будто мы можем брать другое имя только при изменении семейного положения». я не предусмотрел такой возможности. Я не помню, чтобы и ты говорила мне о ней, когда мы обсуждали систему. Вот по- этому-то диалоговое окно «Изменить имя» доступно только из окна «Изменение семейного положения», — сказал Фил. «Я ты знаешь, что люди могут законным образом ме- нять имена, когда захотят, — ответила Мария. — Мы должны это к пятнице, а то Спакл не сможет обналичить чек. Ты сможешь исправить этот дефект к такому сроку?» не резко парировал Фил. знал, что вам нужна эта функциональность. Сейчас я занимаюсь оценкой производительности системы. что потребуется менять другое». да здесь есть еще кое- что. Я, вероятно, смогу исправить это в конце месяца, но не на этой неделе. Извини меня. Но в следующий раз с такими просьбами звони пораньше и, пожалуйста, описывай их». «А что же я скажу Спакл? — возмутилась Мария. — Ей придется залезать в долги, если она не сможет обналичить чек». «Эй, Мария, это не моя вина, — запротестовал Фил. — Если ты не сказала мне при первом осуждении, что вам понадобится Часть I. Требования к продукту: что, почему и кто изменять имена в любое время, этого и нет в системе. Ты не можешь винить меня за то, что я не умею читать мысли в твоей голове». Сердитая и смирившаяся, Мария отрывисто сказала: «Это как раз то, из-за чего я ненавижу компьютерные системы. ни мне, как только сможешь исправить недостаток». Если вы когда-либо бывали в шкуре клиента на переговорах, этому, то знаете, как расстраиваются пользователи кото- рый не позволяет выполнять основные задачи. Разработчики вают чувство разочарования, когда узнают о функциональности, кото- рую пользователи ожидали получить, только после развертывания сис- темы. Точно также раздражает, если приходится прерывать работу за необходимости модифицировать систему, так как она не те о которых вы говорили еще в самом начале разработки. Масса проблем с ПО возникает из-за несовершенства которые люди применяют для сбора, документирования, согласования и модификации требований к ПО. Как в случае с Филом и Марией, проблемы могут возникать из-за неформального сбора предполагаемой функциональности, ошибочных или несогласованных предположений, недостаточно определенныхтребований и бессистем- ного изменения процесса. Большинство людей при строительстве дома даже не интересуются подрядчиками, пока в полном объеме не обсудят свои потребности и желания и не уточнят все детали. Покупатели понимают, что внесение изменений влечет за собой изменение цены; им это не нравится, но они это понимают. Однако люди весело ищут оправдания, когда дело касается разработки ПО. Ошибки, допущенные на стадии сбора требо- ваний, составляют от 40 до 60% всех дефектов проекта (Davis, 1993; 1997). Две наиболее распространенные проблемы, о рых сообщается в большом Европейском обзоре индустрии ПО, — оп- ределение и управление требованиями заказчика (ESPITI, не мене многие организации еще применяют неэффективные методы на этих стадиях разработки ПО. Типичный исход — неожидаемые про- белы, а также различия между тем, что разработчики строить, и тем, в чем клиенты реально нуждаются. * Я использую термины взаимозаменяемые в этой Концепции и приемы, обсуждаемые здесь, применимы к ПО любого вида и к ПО, элементы, которые вы строите. | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
