41404

Разработка программного обеспечения информационных систем

Лекция

Информатика, кибернетика и программирование

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

Русский

2013-10-23

194.5 KB

10 чел.

Лекция N 1 30/10/02

Объектно-ориентированный анализ и проектирование

Управление требованиями

1. Проблема требований

1.1. Цель

Разработка программного обеспечения информационных систем.

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

Клиенты могут быть достаточно разными:

• Для некоторых из нас клиент - источником заказов, и его нужно убедить отклонить предложения наших конкурентов и приобрести наш готовый программный продукт

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

• Для большинства же клиент работает вместе с нами, сидит дальше по коридору, этажом ниже или где-то в другом месте и с нетерпением ожидает нового приложения, позволяющего более эффективно обрабатывать заказы или использовать средства электронной коммерции для продажи товаров и услуг.

1.2. Статистика

Но зачастую ситуация более серьезна. Исследования группы Стендиша (Standish Group) (1994) свидетельствуют о следующем.

В США ежегодно тратится более 250 миллиардов долларов на разработку приложении. информационных технологий в рамках примерно 175000 проектов. Средняя стоимость проекта для -крупной компании составляет $2322000, для средней— $1331000, а для мелкой— $434000...

Исследования группы Стендигна показали, что 31% проектов будет прекращен до завершения. Затраты на 52,7% проектов составят 189% от первоначальной оценки. Исходя из этого, группа Стендиша оценивает, что американские компании и правительственные учреждения потратят 81 миллиард долларов на программные проекты, которые так и не будут завершены. Эти же организации заплатят дополнительно 59 миллиардов долларов за программные проекты, которые хотя и завершатся, но значительно превысят первоначально отведенное на них время.

1.3. Основные причины успеха и провала проектов

В отчете группы Стендиша (1994) указано три наиболее часто встречающихся ключевых фактора, создающих "проблемы" в проектах.

• Недостаток исходной информации от клиента: 13% всех проектов

• Неполные требования и спецификации: 12% проектов

• Изменение требований и спецификаций: 12% всех проектов

Каковы главные "факторы успеха " в этих проектах? Согласно проведенному исследованию тремя наиболее важными факторами были следующие.

• Подключение к разработке пользователя: 16% всех успешных проектов

• Поддержка со стороны исполнительного руководства: 14% всех успешных проектов

• Ясная постановка требований: 12% всех успешных проектов

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

1. Спецификации требований

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

1.4. Высокая цена ошибок требований

В проведенных в компаниях GTE, TRW, IBM и HP исследованиях была оценена стоимость ошибок, возникающих на различных стадиях жизненного цикла проекта. Дэвис (Davis) в своей работе (1993) подвел итоги нескольких подобных исследований. Результаты представлены на рис. 1. Хотя эти исследования проводились независимо, они имели приблизительно одинаковые результаты: если стоимость усилий, необходимых для обнаружения и устранения ошибки на стадии написания кода, принять за единицу, то стоимость выявления и устранения ошибки па стадии выработки требований будет в пять-десять раз меньше. А стоимость обнаружения и устранения ошибки на стадии сопровождения — в 20 раз больше.

Из рисунка видно, что при обнаружении ошибок на стадии формирования требований получаем экономию средств в соотношении 200:1 по сравнению с их обнаружением на стадии сопровождения жизненного цикла программы.

Рис. 1. Относительная стоимость устранения ошибки «различных фазах жизненного цикла

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

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

• Повторное проектирование

• Повторное кодирование

• Повторное тестирование

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

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

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

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

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

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

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

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

2. Введение в управление требованиями

2.1. Определения

Что такое требование

Хотя за долгие годы уже появилось множество определений требований к программному обеспечению, вполне приемлемым является следующее определение, предложенное специалистами в области разработки требований Дорфманом (Dorfman) и Тапером (Thayer) (1990).

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

Что такое управление требованиями

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

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

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

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

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

Но как быть с управлением требованиями? Основными факторами в данном случае являются размер проекта и его сложность: никто не будет вспоминать об "управлении" требованиями, если в проекте участвуют два человека и необходимо обеспечить выполнение десяти требований. Однако при проверке 1000 требований (как в небольшом коммерческом программном продукте) или 300 000 требований (как в системе управления самолетом Боинг 777) нам, очевидно, придется столкнуться с задачами организации, определения приоритетов, управления доступом, а также обеспечения ресурсов для выполнения всех этих различных требований.

Кто из участников команды проектировщиков отвечает за требование, касающееся скорости ветра (№278), и кому из них разрешено вносить в него изменения или вообще удалить его?

• Если в требование №278 вносятся изменения, на какие другие требования это повлияет?

• Как удостовериться в том, что в системе программного обеспечения v-же написан код для выполнения требования №278, и какие тестовые примеры из общего набора тестов предназначены для проверки того, что данное требование действительно выполнено?

Именно это, а также многое другое подразумевается под управлением требованиями.

2.2. Подход к управлению требованиями

Область проблемы

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

Область проблемы

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

Потребности заинтересованных лиц

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

Переход к области решения

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

Функции системы

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

• "У автомобиля будут автоматические стеклоподъемники"

• "Диаграммы динамики обнаружения неисправностей будут снабжены визуальными средствами оценки прогресса"

• "Необходимо предусмотреть возможность ввода заказов через Internet"

• "Автоматический цикл двойной сварки"

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

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

Графически функции будут представляться как основание описанной ранее пирамиды потребностей.

Требования к программному обеспечению

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

Этими более конкретизированными требованиями являются требования к программному обеспечению (software requirements). Мы будем представлять их в виде части пирамиды аналогично представлению функций. Отметим, что они находятся в пирамиде гораздо ниже, и это означает, что нам придется проделать немалую работу, прежде чем мы достигнем этого уровня детализации.

Понятие прецедентов

Наконец, еще одной важной конструкцией, которая поможет нам в нашем путешествии, является прецедент (use case). В простейшем случае прецедент описывает последовательность действий, выполняемых системой, чтобы предоставить значимый результат пользователю. Другими словами, прецедент описывает серии взаимодействий пользователь/система, в результате которых пользователь решает некие свои задачи. Мы будем изображать прецедент в виде простой овальной пиктограммы, содержащей его название. Например, если мы хотим описать прецедент, когда клиент использует компьютер просто для включения или выключения света, его можно назвать "Управление освещением" и поместить это название в овал.

Заключение

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

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

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

Рис. 2. Характеристика области проблемы и области решения

3. Команда разработчиков

3.1. Разработка программного обеспечения как командная деятельность

"Разработка программного обеспечения стала командным видам спорта. " (Буч, 1998)

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

3.2. Профессиональные навыки, которыми должна обладать команда для эффективного управления требованиями

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

• "Анализ проблемы"

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

• "Понимание потребностей пользователей"

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

• "Определение системы"

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

• "Управление масштабом"

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

• "Уточнение определения системы"

описывается, как организовать информацию о требованиях. Затем предлагается ряд методов уточнения определения системы до уровня детализации, пригодного для проведения проектирования и реализации, чтобы вся расширенная команда точно знала, какую систему она разрабатывает.

• "Построение правильной системы",

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

3.3. Организация команд, разрабатывающих программное обеспечение

Рис. 3. Организационная схема команды разработчиков программного обеспечения системы

4. Анализ проблемы

• Пять этапов анализа проблемы

• Моделирование бизнес-процессов

• Инженерия систем, интенсивно использующих программное обеспечение

4.1. Пять этапов анализа проблемы

Большинство систем создается для решения определенной проблемы. Чтобы правильно понять, в чем состоит проблема, мы будем использовать методы анализа проблем.

Анализ проблемы - это процесс осознания реальных проблем и потребностей пользователя и  предложения решений для удовлетворения этих потребностей.

Чтобы иметь возможность провести анализ проблемы, полезно определить, что же собой представляет проблема. По определению Гауса и Вайнберга (Gause, Weinberg, 1989) проблема - это разница между желаемым и воспринимаемым.

Это определение достаточно разумно, по крайней мере, оно устранит часто встречающееся среди разработчиков заблуждение, что подлинная проблема заключается в том, что пользователь не понимает, в чем состоит проблема!

Согласно данному определению, если пользователь ощущает нечто как проблему, это и есть настоящая проблема, и она достойна внимания.

Иногда самым простым решением является изменение бизнес-процесса, а не создание новой системы.

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

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

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

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

Для этого необходимо осуществить следующие пять этапов.

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

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

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

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

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

Давайте подробно рассмотрим каждый их этих этапов.

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

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

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

Постановка проблемы

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

Таблица 1. Стандартная форма постановки проблемы

Элемент

Описание

Проблема

воздействует на

результатом чего является

Выигрыш от

может состоять в следующем

[Описание проблемы]

[Указание лиц, на которых оказывает влияние данная проблема]

[Описание воздействия данной проблемы на заинтересованных лиц и бизнес-деятельность]

[Указание предлагаемого решения]

[Список основных предоставляемых решением преимуществ]

Может показаться, что достижение согласия относительно определения решаемой проблемы — шаг небольшой и малозначащий, и чаще всего так оно и есть. Но не всегда. Например, один из наших клиентов, производитель оборудования, занялся усовершенствованием своей IS/IT-системы, обеспечивающей пересылку счетов и финансовых отчетов между компанией и ее дилерами. Задачей новой программы было "улучшить средства коммуникации дилеров". В свете этого команда приготовилась разрабатывать новую масштабную систему. Данный пример достижения соглашения о решаемой проблеме весьма показателен. Предложенное командой определение решения предполагало создание мощной новой системы, предусматривающей улучшенную финансовую отчетность, усовершенствованные формы счетов и отчетов, возможность заказа запчастей в интерактивном режиме и электронную почту. Помимо этого, команда надеялась (если получится) обеспечить возможность электронного перевода средств между компанией и дилером.

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

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

Для понимания реальной проблемы и ее причин можно использовать множество методов. Одним из них является метод анализа корневых причин (root cause analysis), представляющий собой семантический способ нахождения причин, лежащих в основе рас- сматриваемой проблемы или ее проявления.                                       

Рассмотрим реальный пример.

Компания GoodsAreUs, занимающаяся торговлей по каталогу, производит и рассылает на дом множество недорогих товаров различных наименований. Решив заняться проблемой недостаточной прибыльности, компания использует рекомендуемую ее программой обеспечения качества методику "качество — во всем" (total quality management, TQM). Применив данный подход, компания практически сразу обратила внимание на ущерб от несоответствия (cost of nonconformance), который представляет собой стоимость всего, что идет не так, как надо, и приводит к бесполезным затратам. Этот ущерб включает в себя переделки, остатки, неудовлетворенность клиента, текучесть кадров и другие негативные факторы. Проанализировав ущерб от несоответствия, компания заподозрила, что наибольший вклад в него вносят "остатки".

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

Рис. 3. Диаграмма в форме рыбного скелета для отображения корневых причин

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

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

Устранение корневых причин

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

Конечно, инженер в каждом из нас захочет устранить все корневые причины на "косточках" диаграммы. Кажется, что это правильно. Но так ли это? Зачастую — нет. Качественные данные свидетельствуют, что многие корневые причины просто не стоят того, чтобы их устранять, поскольку затраты на их устранение превысят причиняемый проблемой ущерб. Как же узнать, какие из них устранять? Ответ: необходимо определить влияние каждой корневой причины. Результат этого исследования можно отобразить в виде Парето-диаграммы, визуально отражающей реальных "виновников".

Вернемся к нашему примеру. Предположим, что в результате сбора данных получилась картина, изображенная на рис. 4.. Как видно, команда обнаружила, что одна корневая причина — "неправильные заказы на покупку" — является источником половины всех остатков. Если, в свою очередь, окажется, что существующая система заказов на покупку является образцом ошибочного кода, недружественного интерфейса пользователя и не предоставляет возможность устранения ошибок в интерактивном режиме, тогда действительно можно сократить остатки с помощью разработки нового программного обеспечения.

Рис. 4. Парето-диаграмма корневых причин

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

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

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

Таблица 2. Постановка проблемы ввода заказов на покупку

Элементы

Описание

Проблема воздействует на

результатом чего является

Выигрыш от

неправильных заказов на покупку

выполняющий заказы персонал, клиентов, производство, продажи и обслуживание клиентов

увеличение остатков, повышение производственных затрат, неудовлетворенность клиентов, уменьшение прибыли

новой системы, направленной на решение данной проблемы, может состоять в следующем.

• Повышение точности заказов на покупку в точке ввода

• Совершенствование учета данных о покупках В конечном счете — увеличение прибыли.

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


 

А также другие работы, которые могут Вас заинтересовать

79240. Классическая политическая экономия. Экономические системы А. Смита (1723-1790) и Д. Рикардо (1772 - 1823 гг.) 152 KB
  Годичный труд каждого народа представляет собою первоначальный фонд который доставляет ему все необходимые для существования и удобства жизни продукты потребляемые им в течение года и состоящие всегда или из непосредственных продуктов этого труда или из того что приобретается в обмен на эти продукты у других народов. Напротив у народов цивилизованных и процветающих – хотя у них большое число людей совсем не работает причем многие неработающие потребляют в десять а часто и в сто раз большего труда чем...
79241. Идеи классической политической экономии в учениях Т. Мальтуса, Ж.-Б. Сэя., Дж. Ст. Милля 192.5 KB
  Это обстоятельство а также внимание оказанное обществом моему Опыту обязывали меня произвести некоторые исторические исследования с целью изучить влияние закона народонаселения на прошедшее и настоящее состояния общества. Нищета и бедствия производимые чрезмерно быстрым размножением населения бы ли уже замечены и жестокие меры против этих бедствий были указываемы со времен Платона и Аристотеля. Не говоря уже о том что сравнение между возрастанием населения и средств потребления не было никем изложено с достаточной силой и ясностью...
79242. Экономическое учение западно-европейских социалистов и демократическая мысль России 1-й половины XIX века 303.5 KB
  Лучшим средством привлечь их на свою сторону будет возможно полное разъяснение этого вопроса; вот цель какую я себе ставлю обращаясь к различным группам человечества разделяемого мною на три класса: первый – это тот к которому имеем честь принадлежать мы с вами; он шествует под знаменем прогресса человеческого духа и состоит из ученых художников и всех людей разделяющих либеральные идеи. Это такое брожение когда все отношения между членами нации становятся непрочными и величайший из всех бичей – анархия – свободно производит свои...
79243. Марксистская политическая экономия. Структура и логика «Капитала» К. Маркса 313 KB
  Но товарная форма продукта труда или форма стоимости товара есть форма экономической клеточки буржуазного общества. Этот его характер не зависит от того много или мало труда стоит человеку присвоение его потребительных свойств. Как потребительная стоимость он не заключает в себе ничего загадочного будем ли мы его рассматривать с той точки зрения что он своими свойствами удовлетворяет человеческие потребности или с той точки зрения что он приобретает эти свойства как продукт человеческого труда. Потому что вопервых как бы...
79244. Основные идеи русского марксизма. Экономическая мысль России второй половины XIX – начала XX веков. Экономические взгляды народников, Г. В. Плеханова (1856-1918 гг.), В. И. Ленина (1870-1924 гг.) 323 KB
  Для социальной науки предмет которой не личность а коллектив весь капитализм с его бесчисленными противоречиями непрерывной борьбой неустойчивыми равновесиями движением от одних кризисов и революций к другим есть не более как переходная фаза между двумя органическими общественными системами длительная революция методов производства и форм сотрудничества. Но и они должны переходить ко все более глубоким пластам и при нынешней скорости расширения производства угольное будущее этих стран также становится все более темным. Эволюция...
79245. Организация планирования на предприятии. Планирование как инструмент принятия управленческих решений 21.2 KB
  Организация планирования на предприятии. Сущность планирования в условиях рыночной экономики заключается в научном обосновании на предприятиях предстоящих экономических целей их развития и форм хозяйственной деятельности выбора наилучших способов их осуществления на основе наиболее полного выявления требуемых рынком видов объемов и сроков выпуска товаров выполнения работ и оказания услуг и установления таких показателей их производства распределения и потребления которые при полном использовании ограниченных производственных ресурсов...
79246. Стратегическое планирование развития предприятия, цели и особенности стратегического планирования 13.45 KB
  Цель функционирования компании фирмы предприятия это четко и однозначно сформулированные намерения представленные в виде перечня подлежащих достижению главных показателей имеющих количественную оценку. Цели представляют собой ориентиры развития фирмы а стратегия это план их достижения. Цель можно определить и как конечные экономические и финансовые результаты деятельности фирмы которые она планирует получить к заранее установленному сроку. Цель возникает как результирующая компонента потребностей покупателей определяемых миссией...
79247. Особенности бизнес планирования 18.56 KB
  Бюджетное управление это технология управления компанией комплекс организационных мер операций и приемов направленных на разработку и внедрение системы бюджетного управления Бюджет предприятия – план составленный на следующий период в натуральном и денежном выражении; определяющий потребность предприятия в ресурсах необходимых для получения запланированных доходов. Бюджетная структура – система функциональных бюджетов предприятия по которой происходят последовательное планирование и учет результатов хозяйственной деятельности всего...