ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.01.2024
Просмотров: 113
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Вернемся к нашему примеру. Предположим, что в результате сбора данных получилась картина, изображенная на рис. 4.2. Как видно, команда обнаружила, что одна корневая причина — "неправильные заказы на покупку" — является источником половины всех остатков. Если, в свою очередь, окажется, что существующая система заказов на покупку является образцом ошибочного кода, недружественного интерфейса пользователя и не предоставляет возможность устранения ошибок в интерактивном режиме, тогда действительно можно сократить остатки с помощью разработки нового программного обеспечения.
Рис. 4.2. Парето-диаграмма корневых причин
В этот момент, и только в этот момент, можно считать аргументированным предложение команды заменить существующую систему ввода заказов на покупку. Затем можно предоставить стоимостное обоснование такой системы, оценив затраты на разработку и дивиденды от уменьшения остатков.
Продолжая анализ, можно применить новую диаграмму в виде "рыбного скелета" для определения того, какие типы ошибок вносят наибольший вклад в проблему неправильности заказов. Полученные данные можно затем использовать для определения функций новой системы программного обеспечения, которая призвана устранить эти ошибки. В нашем случае, однако, можно завершить анализ выводом, что замена системы обработки заказов на покупку поможет, по крайней мере частично, решить проблему слишком больших остатков.
Раз мы приняли решение, что проблема неправильных заказов на покупку достойна решения, можно создать для нее формальную постановку, как показано в табл. 4.2.
Таблица 4.2. Постановка проблемы ввода заказов на покупку
| Элементы | Описание |
| Проблема | неправильных заказов на покупку |
| воздействует на | выполняющий заказы персонал, клиентов, производство, продажи и обслуживание клиентов, |
| результатом чего является | увеличение остатков, повышение производственных затрат, неудовлетворенность клиентов, уменьшение прибыли. |
| Выигрыш от | новой системы, направленной на решение данной проблемы, может состоять в следующем. • Повышение точности заказов на покупку в точке ввода • Совершенствование учета данных о покупках В конечном счете — увеличение прибыли. |
После написания постановки проблемы, ее следует передать для ознакомления заказчикам и заинтересованным лицам, чтобы они внесли свои комментарии. Затем постановка проблемы доводится до сведения всех членов команды разработчиков с тем, чтобы все работали в направлении достижения общей цели.
Этап 3. Выявление заинтересованных лиц и пользователей
При решении любой сложной проблемы, как правило, приходится удовлетворять потребности различных групп заинтересованных лиц. Эти группы обычно имеют различные точки зрения на проблему и различные потребности, которые должны быть учтены в решении.
Заинтересованные лица - это все, на кого реализация новой системы или приложения может оказать материальное воздействие.
Понимание потребностей пользователей и других заинтересованных лиц является ключевым фактором в выработке успешного решения.
Первая категория заинтересованных лиц — это пользователи системы. Их потребности легко учесть, поскольку они будут непосредственно привлекаться к определению и использованию системы. Вторую категорию составляют непрямые пользователи, а также те, на кого воздействуют только бизнес-последствия разработки. Этих заинтересованных лиц можно найти в соответствующей бизнес-области или в "окрестностях" среды конкретного приложения. Третья категория заинтересованных лиц может находиться еще дальше от среды приложения. Среди них могут быть люди и организации, вовлеченные в разработку системы, субподрядчики, клиенты клиентов, внешние регулирующие инстанции, например Федеральное управление гражданской авиации США (U.S. Federal Aviation Administration, FAA), Управление по санитарному надзору за пищевыми продуктами и медикаментами (Food and Drug Administration, FDA), или другие агентства, взаимодействующие с системой или участвующие в процессе разработки. Каждая из перечисленных категорий заинтересованных лиц может оказывать влияние на требования к системе или будет каким-либо образом связана с результатом работы системы.
Потребности заинтересованных лиц, не являющихся пользователями, также необходимо выявить и учесть.
Понимание того, кто же такие эти заинтересованные лица, и выявление их потребностей являются важными факторами разработки успешного решения. В зависимости от того, в какой предметной области работает команда, выявление заинтересованных лиц может оказаться как тривиальным, так и нетривиальным этапом анализа проблемы. Часто достаточно провести простой опрос среди тех, кто принимает решения, а также опросить потенциальных пользователей и другие заинтересованные стороны. В этом процессе могут оказаться полезными следующие вопросы.
• Кто является пользователями системы?
• Кто является заказчиком (экономическим покупателем) системы?
• На кого еще окажут влияние результаты работы системы?
• Кто будет оценивать и принимать систему, когда она будет представлена и развернута?
• Существуют ли другие внутренние или внешние пользователи системы, чьи потребности необходимо учесть?
• Кто будет заниматься сопровождением новой системы?
• Не забыли ли мы кого-нибудь?
В нашем примере замены системы заказов на покупку основными и наиболее очевидными пользователями являются служащие, занимающиеся вводом заказов на покупку. Они определенно являются заинтересованными лицами, так как их производительность, удобство, комфорт, выполнение работы и ее результаты зависят от системы. Кого еще из заинтересованных лиц можно выделить?
На руководителя отдела приема заказов система также оказывает непосредственное воздействие, но он взаимодействует с системой не напрямую, а посредством различных интерфейсов пользователя и форм отчетов. Главный финансист компании также, очевидно, принадлежит к заинтересованным лицам, так как ожидается, что система повлияет на производительность, качество предоставляемых услуг и прибыльность компании. Наконец, администратор информационной системы и члены команды, разрабатываю-
щей приложение, также являются заинтересованными лицами, так как они будут отвечать за разработку и сопровождение системы. Они также, как и пользователи, будут зависеть от поведения системы. Результаты выявления пользователей и заинтересованных лиц новой системы ввода заказов на покупку представлены в табл. 4.3.
Таблица 4.3. Пользователи и лица, заинтересованные в новой системе
| Пользователи | Другие заинтересованные лица |
| Служащие, занимающиеся вводом заказов | Администратор информационной системы и команда разработчиков |
| Руководитель отдела приема заказов | Главный финансист |
| Контроль производства | Управляющий производством |
| Служащий, выписывающий счета | |
Этап 4. Определение границ системы-решения
После того как согласована постановка проблемы и выявлены пользователи и заинтересованные лица, можно перейти к определению системы, разрабатываемой для решения данной проблемы. Это важный момент, когда необходимо постоянно помнить как о понимании проблемы, так и о свойствах потенциального решения.
Следующий важный этап состоит в том, чтобы определить границы системы-решения. Границы системы — это "водораздел" между решением и окружающим его реальным миром (рис. 4.3.) Иными словами, граница системы описывает оболочку, в которой заключена система. Информация в виде ввода и вывода передается от находящихся вне системы пользователей системе и обратно. Все взаимодействия с системой осуществляются посредством интерфейсов между системой и внешним миром.
Исходные данные
Результаты
Рис. 4.3. Отношение ввод/система/вывод
Мы делим мир на две части.
1. Наша система
2. То, что взаимодействует с нашей системой
Другими словами, если мы собираемся нечто создать или модифицировать — это часть нашего решения, которая находится внутри границы; если нет — это нечто внешнее по отношению к системе. Таким образом, мы делим мир на два интересующих нас класса.
• Наша система
• То, что взаимодействует с нашей системой
О
пределим "то, что взаимодействует с нашей системой", общим понятием "акторы" (actors). Они выполняют некоторые действия, заставляя систему делать ее работу. Актор изображается простой пиктограммой в виде человечка. Его определение выглядит следующим образом.Актор - это находящееся вне системы нечто {или некто), взаимодействующее с системой.
С помощью данного понятия мы можем проиллюстрировать границы системы (рис. 4.4).
Рис, 4.4. Границы системы
Во многих случаях границы системы очевидны. Например, однопользовательский персональный планировщик контактов, работающий на автономной платформе Windows 2000, имеет достаточно хорошо определенные границы. Имеется всего один пользователь и одна платформа. Интерфейсы между пользователем и приложением состоят из диалогов, посредством которых пользователь получает доступ к информации системы, и неких выходных сообщений и коммуникационных путей, которые система использует для документирования или передачи этой информации.
Для системы ввода заказов из нашего примера, которая должна быть объединена с уже существующей информационной системой компании, границы не столь очевидны. Аналитик должен определить, будут ли данные использоваться совместно с другими приложениями, должно ли новое приложение распределяться по разным хостам и клиентам, а также кто будет пользователем. Например, должен ли персонал, занятый в производстве, иметь интерактивный доступ к заказам на покупку? Обеспечивается ли контроль качества или функции аудита? Будет ли система выполняться на компьютере-мэйнфрейме или на новом компьютере-клиенте? Должны ли предоставляться специальные отчеты?
Выявление акторов является ключевым аналитическим этапом в анализе проблемы. Ответы на следующие вопросы помогут их обнаружить.
• Кто будет поставлять, использовать или удалять информацию из системы?
• Кто будет управлять системой?
• Кто будет осуществлять сопровождение системы?
• Где будет использоваться система?
• Откуда система получает информацию?
• Какие внешние системы будут взаимодействовать с системой?
Имея ответы на эти вопросы, аналитик может создать блок-схему, описывающую границы системы, пользователей и другие интерфейсы. На рис. 4.5 представлена новая система ввода заказов на покупку и ее окружение.
Рис. 4.5. Система и ее окружение
Точечная линия иллюстрирует границу системы для предлагаемого решения. Из рисунка видно, что основная часть нового приложения будет развернута в новой системе ввода заказов на покупку, но часть кода решения должна разрабатываться и разворачиваться в уже существующей унаследованной системе.
Этап 5. Выявление ограничений, налагаемых на решение
Ограничения уменьшают степень свободы, которой мы располагаем при предложении решения.
Перед тем как предпринимать продиктованные благими намерениями и стоящие больших денег усилия по "революционизированию" состояния дел в области ввода заказов на покупку, необходимо остановиться и рассмотреть ограничения, которые будут наложены на решение. Мы будем определять ограничение следующим образом.
Ограничения уменьшает степень свободы, которой мы располагаем при предложении решения.