дет в 5—10 раз меньше, а стоимость обнаружения и устранения ошибки на стадии сопровождения — в 20 раз больше (рис. 2.1).

Этап

Время выработки требований Проектирование

Откуда берется такая высокая стоимость ошибки? Ко времени обнаружения ошибки в требованиях группа разработчиков уже могла потратить время и усилия на создание проекта по этим ошибочным требованиям. В результате проект, вероятно, придется отбросить или пересмотреть [1].

Истинная природа ошибки может быть замаскирована; при проведении тестирования и проверок на данной стадии все думают, что имеют дело с ошибками проектирования, и значительное время и усилия могут быть потрачены впустую.

В зависимости от того, где и когда при работе над проектом разработки программного приложения был обнаружен дефект, цена его может разниться в 50—100 раз. Причина состоит в том, что для его исправления придется затратить средства на некоторые (или все) нижеперечисленные действия.

1. Повторная спецификация.

2. Повторное проектирование.

3. Повторное кодирование.

4. Повторное тестирование.

5. Замена заказа — сообщить клиентам и операторам о необходимости заменить дефектную версию исправленной.

6. Внесение исправлений — выявить и устранить все неточности, вызванные неправильным функционированием ошибочно специфицированной системы, что может потребовать выплаты определенных сумм возмущенным клиентам, повторного выполнения определенных вычислительных задач на ЭВМ и т. п.

1. Списание той части работы (кода, части проектов и т. п.), которая выполнялась с наилучшими побуждениями, но оказалась ненужной, когда обнаружилось, что все это создавалось на основе неверных требований.

7. Отозвание дефектных версий встроенного программного обеспечения и соответствующих руководств. Если принять во внимание, что программное обеспечение сегодня встраивается в различные изделия — от наручных часов и микроволновых печей до автомобилей, — такая замена может коснуться как этих изделий, так и встроенного в них программного обеспечения.

9. Выплаты по гарантийным обязательствам.

10. Ответственность за изделие, если клиент через суд требует возмещение убытка, причиненного некачественным программным продуктом.

11. Затраты на обслуживание представитель компании должен посетить клиента, чтобы установить новую версию программного обеспечения.

12. Создание документации.

2./.3- Управление требованиями

Требования задают возможности, которые должна предоставлять система, так что соответствие или несоответствие некоторому множеству требований часто определяет успех или неудачу проекта. Поэтому имеет смысл узнать, что собой представляют требования, записать их, упорядочить и отслеживать их изменения. Определение управления требованиями выглядит следующим образом [3].

---

Управление требованиями — это систематический подход к выявлению, организации и документированию требований к системе, а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и выполняющей проект группой по поводу меняющихся требований к системе.

Учитывая, что системе будут предъявлены сотни, если не тысячи требований, то очень важно организовать их.

Поскольку невозможно удерживать в памяти более нескольких десятков фактов, для успешного взаимодействия различных участников процесса необходимо обеспечить документирование требований. Требования следует записать так, чтобы они были доступны для ознакомления; это может быть документ, модель, база данных или листок на доске объявлений.

Кроме того, очень важными факторами являются размер проекта и его сложность. Управление требованиями наиболее важно в больших проектах, в которых участвует множество людей и число требований к проекту велико Допустим, таких требований 1000. Тогда придется столкнуться с задачами организации, определения приоритетов, управления доступом, а также обеспечения ресурсов для выполнения всех этих требований.

2. /-4- Последовательность работы с требованиями. Анализ проблемы

У пользователя есть технические или бизнес-задачи, для решения которых им нужны программисты. Задача последних состоит в том, чтобы понять проблемы пользователей в их собственной проблемной плоскости и на их языке и построить системы, удовлетворяющие их требованиям. Для понимания проблемы пользователей существует ряд профессиональных приемов, о которых пойдет речь ниже [3].

Программисты должны понять потребности пользователей и других заинтересованных лиц, на чью жизнь повлияет создание программы.

Следующим шагом осуществляется переход в область решения — непосредственно к программированию. Однако для начала будет полезно сформулировать знания о предметной области. На данном этапе составляется список функций, которые должна реализовывать система.

Для того чтобы провести анализ, полезно определить, что же собственно представляет собой проблема. По определению Гауса и Вайнберга [11], проблема — это разница между желаемым и воспринимаемым.

Иногда самым простым решением является изменение бизнес-процесса, а не создание новой системы. Как всегда, начинать следует с определения цели. Цель анализа состоит в том, чтобы добиться лучшего понимания решаемой проблемы до начала разработки. Для этого необходимо осуществить следующие пять этапов.

1. Достигнуть соглашения об определении проблемы.

2. Выделить основные причины — вопросы, стоящие за про-
блемой.

3. Выявить заинтересованных лиц и пользователей.

4. Определить границу системы решения.

5. Выявить ограничения, которые необходимо наложить на
решение.

---

Этап 1. Достижение соглашения об определении проблемы.

Первый шаг состоит в достижении соглашения об определении проблемы, которую необходимо решить. Один из простейших способов заключается в том, чтобы просто записать проблему и выяснить, все ли согласны с такой постановкой.

В рамках этого процесса зачастую полезно рассмотреть преимущества предлагаемого решения, причем их следует описывать на языке клиентов/пользователей. Это обеспечивает дополнительную содержательную основу для понимания реальной проблемы. Рассматривая эти преимущества с точки зрения клиента, программисты также достигают лучшего понимания их взгляда на проблему в целом.

Часто бывает полезно записать проблему в стандартной форме (табл. 2.1). Создание подобной таблицы является простым, но действенным средством, чтобы удостовериться в том, что все участники проекта работают вместе над осуществлением общей цели.

Таблица 2.1. Структурирование проблемы

Элемент	Описание
Проблема	Описание проблемы
Воздействует на что (кого) и результатом чего является	Указание лиц, на которых оказывает влияние данная проблема. Описание воздействия данной проблемы на заинтересованных лиц и бизнес-деятельность
Выигрыш от решения может состоять в следующем	Указание предлагаемого решения. Список основных предоставляемых решением преимуществ

Этап 2. Выявление основных причин — вопросов, стоящих за проблемой.

На данном этапе важно понять корневые причины, лежащие в основе проблемы, и ее проявления.

Например, электронный магазин решил бороться с проблемой недостаточной прибыльности. Для этого был проведен анализ причин плохих продаж. Получено, что следующие причины ведут к слишком большим остаткам продукции на складе:

1. устаревшие готовые изделия;

2. неправильные заказы на покупку;

3. повреждения при доставке;

4. производственные дефекты;

5. возвраты клиентами;

6. прочее.

Однако нужно ли устранять все эти причины? Зачастую нет. Некоторые корневые причины просто не стоят того, чтобы их устранять. Нужно определить влияние каждой корневой причины и устранять только те, которые наиболее серьезно влияют на саму проблему. В примере, допустим, наибольшее влияние оказывает корневая причина «Неправильные заказы на покупку».

Этап 3. Выявление заинтересованных лиц и пользователей.

В этом процессе могут помочь ответы на следующие вопросы:

• Кто является пользователем системы?

• Кто является заказчиком (экономическим покупателем) системы?

• На кого еще окажут влияние результаты работы системы?

• Кто будет оценивать и принимать систему, когда она будет представлена и развернута?

• Существуют ли другие внешние или внутренние пользователи системы, чьи потребности следует учесть?

• Кто будет заниматься сопровождением новой системы?

• Не забыли ли мы кого-нибудь?

---

Этап 4. Определение границ системы.

Мир делится на две части (рис. 2.2):

• создаваемая система;

• то, что взаимодействует с системой, — фактор.

Очень важно правильно определить факторы. Для этого следует ответить на приводимые ниже вопросы.

• Кто будет управлять системой?

• Кто будет осуществлять сопровождение системы?

• Откуда система получает информацию?

• Какие внешние системы будут взаимодействовать с системой?

Этап 5. Выявление ограничений, налагаемых на решение.

Ограничения уменьшают степень свободы, которой располагают разработчики при реализации решения. Каждое ограничение может существенно сузить возможность создания предполагаемого решения. Следовательно, в процессе планирования необходимо тщательно изучить все ограничения (табл. 2.2).

2.1-5. Преграды на пути выявления требований Синдром «да, но...

Одну из самых неприятных проблем, с которыми сталкиваются разработчики, можно назвать синдромом «да, но...» [3]. Это первичная наблюдаемая реакция пользователя на каждый разработанный фрагмент программного обеспечения, которая могла бы быть выражена следующими словами:

• «О, это действительно здорово! Можем реально использовать это, классная работа, молодцы, мальчики!» и т. д.

• «Да, но как насчет?.. Нельзя ли было?.. А что, если?.. Причина синдрома «да, но...» кроется глубоко в природе

проектирования программного обеспечения как интеллектуального неосязаемого процесса. Проблема усугубляется тем, что команда разработчиков крайне редко предоставляет что-либо пользователям для обсуждения до окончания разработки (создания программного кода).

Реакция пользователей является следствием человеческой природы. Подобную реакцию можно часто наблюдать и при других повседневных обстоятельствах. Пользователи никогда ранее не видели новую систему или что-либо подобное; они не понимают, что программисты подразумевают, когда описывают ее. И вот теперь она перед ними — впервые после стольких месяцев (или лет) ожидания они имеют возможность взаимодействовать с системой. И оказывается, что это не совсем то, чего они ожидали!

Как это ни грустно, но нужно принять факт существования синдрома «да, но...» в качестве объективной реальности и сделать некоторые выводы, которые помогут членам команды смягчить влияние этого синдрома в будущих проектах:

• синдром «да, но...» является следствием человеческой природы и неотъемлемой частью разработки любого приложения;

• разработчики могут существенно уменьшить воздействие этого синдрома путем применения методов, которые выявят эти «но» как можно раньше. Выявив их на более ранних этапах, можно направить большую часть усилий на разработку программ, которые уже прошли тест на «да, но...

---

42 Глава 2. Технология разработки программных продуктов... Синдром «пользователь и разработчик»

Синдром «пользователь и разработчик» является следствием расхождения взглядов пользователей и разработчиков. Пользователи и разработчики, как правило, принадлежат к различным мирам, говорят на разных языках и имеют различный опыт, мотивацию и цели. Предлагаются рекомендации по смягчению данной ситуации (табл. 2.3).

Таблица 2.3. Рекомендации решения проблемы

Проблема	Решение
Пользователи не знают, чего хотят, а если и знают, то не могут это выразить	Признать пользователя экспертом в предметной области и ценить его в этом качестве; пытаться использовать альтернативные методы общения и выявления требований
Пользователи думают, что они знают, чего хотят, до тех пор, пока разработчики не предоставят им то, что те якобы хотели	Как можно раньше предлагать альтернативные методы выявления: раскадровку, ролевые игры, прототипы и т. п.
Аналитики думают, что они понимают проблемы пользователя лучше его самого	Поставить аналитика на место пользователя. Провести ролевую игру в течение часа или всего дня
Все считают, что другие руководствуются политическими мотивами	Такова человеческая натура, поэтому пусть все остается, как есть

Функции

Использование функций — удобный способ описания возможностей без лишних подробностей.

Такой подход имеет недостаток. Если команда при обсуждении не поймет, какая потребность стоит за функцией, это может привести к неприятным последствиям. Тем не менее это высокий уровень абстракции, удобный для описания возможностей системы.

Рекомендуемое количество функций, которое дает полное представление о разрабатываемой системе, — 25—99, однако желательно, чтобы их число не превышало 50.

После того как все функции перечислены, можно приступить к принятию решения вида «отложить до следующей версии», «реализовать немедленно», «полностью отвергнуть» или «исследовать дополнительно». Это процесс корректировки мае

---

Смотрите также файлы

• КР Руский язык22.docx

• Только для мужчин.docx

• Kursovaya_Malinovskaya333333333.docx

• вопросы ОММСЭП.docx

• РАЗДАТ. МАТЕР. СТУД. по БЖ.docx