Исследование – анализ и определение требований
Основной целью фазы исследования является доказательство жизнеспособности предложенной системы.
Задачи, которые ставит перед командой разработчиков эта фаза, включают следующее:
• определение области действия системы (т.е. какие данные можно ввести и что из этого получится);
• определение потенциальной архитектуры, которая состоит из начальных версий шести разных моделей;
• выделение критических рисков и определение, когда и как можно их устранить;
• начало оценки экономической рентабельности проекта, которая основывается на начальных оценках стоимости, затраченных усилий, графика и качества продукта.
Веха, связанная с фазой исследований, называется цели жизненного цикла. Вот основные признаки того, что эти цели достигнуты:
• основные организаторы проекта достигли единого мнения относительно области действия предложенной системы;
• потенциальная архитектура явно устраняет ряд критических требований высокого уровня;
• бизнес-план проекта достаточно обоснован, чтобы оправдать дальнейшую продолжительную разработку.
Уточнение планов – проектирование системы
Основной целью фазы уточнения планов является подтверждение возможности разработать систему с учетом финансовых, временных. и других видов ограничений, с которыми сталкивается проект разработки.
В ходе фазы уточнения планов команда разработчиков выполняет следующие задачи:
|
|
|
• охват необходимого большинства функциональных требований;
• расширение потенциальной архитектуры до уровня полной базовой линии архитектуры, которая представляет собой внутреннюю версию системы, основанную на описании архитектуры;
• устранение значительных рисков по мере их возникновения;
• завершение бизнес-плана проекта и подготовка плана проекта, достаточно подробного для осуществления следующей фазы (построение).
Базовая линия архитектуры состоит из расширенных версий шести моделей, созданных в ходе фазы исследований.
Фаза уточнения планов завершается вехой архитектуры жизненного цикла. По следующим признакам можно определить, что проект достиг этой вехи:
• эта модель прецедентов охватывает большинство функциональных требований новой системы;
• базовая линия архитектуры представляет собой небольшую и компактную систему, которая может служить надежной основой для непрерывной разработки;
• составлен успешный бизнес-план, и команда разработчиков имеет в наличии план проекта, который описывает развитие фазы построения.
Построение
Основной целью фазы построения является разработка системы, способной функционировать в испытательных условиях, повторяющих условия заказчика.
|
|
|
В ходе фазы построения команда разработчиков выполняет задания, включающие итеративное и инкрементное построение системы, достигает уверенности в том, что систему можно реализовать с сохранением жизнеспособности.
Фаза построения завершается вехой первоначальной работоспособности. Проект считается достигшим этой вехи, если у клиентов на руках оказывается более-менее работоспособная система.
Развертывание - внедрение
Основной целью этой фазы является передача полностью работоспособной системы пользователям.
В ходе фазы развертывания команда разработчиков сосредоточена на исправлении недостатков и на внесении поправок в систему с тем, чтобы откорректировать ранее не замеченные изъяны.
Пять технологических процессов
В унифицированном процессе выделяют пять технологических процессов, которые присутствуют в ходе выполнения всех четырех фаз: управление требованиями, анализ, проектирование, реализация и тестирование. Каждый технологический процесс представляет собой последовательность видов деятельности, которые выполняют исполнители проекта.
Управление требованиями
|
|
|
Основные виды деятельности технологического процесса управления требованиями направлены на построение модели прецедентов, которая охватила бы все функциональные требования создаваемой экономической информационной системы. Эта модель помогает организаторам проекта достичь согласия относительно возможностей системы и условий, которым она должна соответствовать.
Основным принципом этого этапа является необходимость разработки правильной системы. Это понятие включает сбор требований заказчиков проекта и их обсуждение до тех пор, пока не станет ясно, что клиенты и команды разработчиков достигли согласия относительно свойств будущей системы.
Охватить все требования обычно мешает ряд обстоятельств.
• Несмотря на все практические преимущества, клиенты и разработчики разговаривают на разных языках.
• Часто сложно понять, чего хотят клиенты, они либо не знают, либо думают, что знают, но не могут выразить свои мысли, либо меняют мнение и противоречат сами себе
• Документы, в которых фиксируются требования, обычно изобилуют двусмысленностями, избытком информации и внутренними противоречиями.
Технологический процесс управления требованиями определяет задачи, которые связаны с четырьмя основными целями удовлетворения требований.
|
|
|
Существует три компонента, которые могут помочь организаторам проекта достичь согласия относительно того, "с чем работает система и что из этого должно получиться". Это модели предметной области, бизнес-модели и высокоуровневые диаграммы прецедентов.
Модель предметной области описывает важные понятия, связанные с системой, в терминах объектов. Команда может использовать модель предметной области, чтобы помочь всем участникам достичь соглашения в том, какие потребности должны быть удовлетворены с помощью новой системы.
Модель предметной области охватывает важные предметы реального мира и понятия, которые принадлежат области проблемы, т.е. определяют проблему, для решения которой разрабатывается новая система. Эти предметы и понятия представлены в виде классов, связанных между собой различными отношениями.
В унифицированном процессе термин бизнес-модель относится к двум моделям: модели бизнес-прецедентов и модели бизнес-объектов.
Модель бизнес-прецедентов состоит из бизнес-прецедентов, которые описывают производственные процессы, и системных акторов, которые описывают клиентов и партнеров. Между обычными бизнес-прецедентами, а также обычными и бизнес-акторами существует непосредственная связь; на самом деле оба вида прецедентов и акторов присутствуют в диаграммах прецедентов UML.
Бизнес-модель описывает производственные процессы в терминах клиентов, а также в виде концептуальных и конкретных производственных объектов. Эта модель может помочь команде разработчиков понять внутренний принцип действия той сферы бизнеса, для которой разрабатывается система.
Модель бизнес-объектов описывает, как бизнес-прецеденты "реализуются" командой исполнителей с помощью бизнес-категорий (которые могут быть как абстрактными понятиями, например счета, так и конкретными предметами, например бланки). Эта модель также описывает организационные блоки, которые представляют собой ряд бизнес-категорий. Бизнес-категории и организационные блоки часто представляют те же виды понятий и предметов, что и классы в модели предметной области; таким образом, модель бизнес-объектов обычно отображается на диаграммах классов уровня предметной области.
Глоссарий содержит различные ключевые термины, характерные для системы, которые используются в других артефактах проекта. Эти термины могут описывать как конкретные объекты, так и абстрактные понятия. Цель состоит в том, чтобы организаторы проекта использовали глоссарий, когда потребуется прийти к общему согласию относительно того, что именно имеется в виду. Глоссарий обычно составляется на основании модели предметной области, бизнес-модели или их обеих.
Унифицированный процесс определяет прецедент как основную единицу воплощения функциональных требований. Диаграммы прецедентов описывают прецеденты и объекты (люди или предметы), которые с ними взаимодействуют. С помощью построения диаграмм прецедентов, которые отображают определенные в общих чертах высокоуровневые прецеденты (например, на уровне "краткое изложение исполнения" или, возможно, на уровень или два ниже), можно довольно быстро понять, в пределах каких границ моделируется система.
Актор может означать следующее:
• роль, которую может играть пользователь по отношению к системе;
• некий объект (например, другую систему или базу данных), который находится вне системы.
Имя актора не должно быть именем конкретного человека; наоборот, оно должно лишь определять роль или ряд ролей, которые человек, внешняя система или часть разрабатываемой системы играет в отношении одного или более прецедентов. В бизнес-модели акторы в общем соответствуют исполнителям.
Прецедент представляет собой последовательность действий, которые выполняет актор над системой для получения определенного результата.
Прецедент должен описывать один из аспектов использования системы, не учитывая дизайна и реализации. Другими словами, прецедент описывает, что должна выполнять система, при этом не уточняя, как система будет это выполнять.
Прототипы пользовательского интерфейса помогают разработчикам уточнить внешний вид системы и понимание того, как она функционирует, с клиентами, а также понять некоторые их требования.
Пакет UML представляет собой группирование элементов модели. Пакет может сам состоять из пакетов. Модель прецедентов — это, по существу, пакет пакетов прецедентов, каждый из которых состоит из акторов и прецедентов.
Частью архитектурного представления является представление модели прецедентов, которое содержит значимые для архитектуры прецеденты. К ним относятся прецеденты, которые описывают важные функциональные возможности, воплощают особенно важные требования, либо и те и другие.
Каждый из представителей заинтересованных сторон наверняка выступит с несколькими предложениями, касающимися того, какими свойствами должна обладать система. Список свойств является документом, который содержит определение и краткое описание этих предложений. Они могут рассматриваться как потенциальные требования. (С целью планирования и управления для каждого свойства должно быть достаточно сопроводительной информации, чтобы можно было трезво оценить график и бюджет.) Команда может использовать список свойств в качестве справочного материала при решении, как распределить свойства по действительным требованиям, а затем проработать в ходе определенного цикла или итерации.
Прецеденты определяют последовательности действий, которые актор (некто или нечто вне системы, взаимодействующее с ней) и система выполняют, чтобы получить видимый результат. Используя их, можно точно узнать требования клиента, так как хорошо написанный текст прецедента очень похож на текст из руководства пользователя. Прецеденты, особенно если их использовать совместно с прототипами пользовательского интерфейса, также оказывают серьезную поддержку при обсуждении требований с клиентами, так как команда разработчиков использует текст прецедентов, чтобы избежать двусмысленностей, исключить предположения и четко очертить границы наборов прецедентов, которые будут разработаны в ходе определенной итерации системы. Далее в главе прецеденты рассматриваются более подробно; кроме того, речь идет о том, как обнаружить акторов и прецеденты, а также как написать хороший текст прецедента.
Нефункциональные требования связаны с вопросами производительности, безопасности, расширяемости и надежности. Вместе с определенными прецедентами они имеют исключительное значение при формировании архитектуры. При выполнении различных видов деятельности, определенных в технологическом процессе управления требованиями, команда разработчиков может преобразовать эти требования в модели предметной области. Использование таких компонентов UML, как ограничение (условие, которое должно выполняться) и модель прецедентов, в качестве дополнительной информации, связанной с индивидуальными прецедентами или группами прецедентов, также помогает охватить эти требования.
Диаграмма классов в UML — наиболее действенный способ в полной мере представить содержание модели предметной области.
Дополнительное требование еще называют нефункциональным требованием. К этому виду требований относятся те, которые имеют отношение к таким задачам, как производительность, безопасность и возможность поддержки, или к ограничениям, налагаемым на систему извне, например тем, которые включают в себя регулирующие факторы. Дополнительное требование обычно не соответствует определенному прецеденту; для его воплощения используется несколько прецедентов.
В технологическом процессе управления требованиями принимают участие следующие исполнители, которые играют ключевые роли. Следует помнить, что исполнитель в этом контексте является логической ролью, а не физическим лицом.
Системный аналитик акцентирует внимание на процессах извлечения требований и моделировании, а также связанных с ними прецедентах. Это включает следующее:
• управление разработкой модели предметной области и бизнес-модели;
• поиск акторов и прецедентов;
• гарантия полноты и непротиворечивости модели прецедентов в целом.
Системный аналитик также несет основную ответственность за составление глоссария.
Спецификатор прецедентов составляет подробные описания основного и особых потоков событий для одного или более прецедентов.
Разработчик пользовательского интерфейса работает над визуальным представлением тех элементов пользовательского интерфейса, которые будут использовать один или несколько акторов. Для этого обычно сначала разрабатывают прототип пользовательского интерфейса.
В технологическом процессе управления требованиями архитектор распределяет в соответствии с приоритетами данный набор прецедентов и заносит архитектурно значимые прецеденты в описание архитектуры.
Модель прецедентов служит также базой для остальной работы по разработке системы. На рис. 4.2 показано, какое влияние имеет модель прецедентов на другие пять моделей.
Рис. 4.2. Шесть основных моделей унифицированного процесса
Анализ
Целью основных видов деятельности технологического процесса анализа является построение модели анализа, которая помогает разработчикам уточнить и структурировать функциональные требования, охватываемые моделью прецедентов. Эта модель содержит реализации прецедентов, которые легче использовать в проектировании и реализации, чем сами прецеденты.
На этапе технологического процесса анализа основная цель команды разработчиков состоит в том, чтобы понять требования заказчиков и опираться на них при установке целей для проектирования и реализации. Первым результатом этого процесса будет модель анализа, которая предназначена для того, чтобы помочь команде достичь таких целей, как совместное использование ресурсов, удобство сопровождения, устойчивость и повторное использование.
Модель анализа представляет собой улучшенную и расширенную модель прецедентов. Суть этого усовершенствования можно кратко выразить следующим образом.
• Даже самое скрупулезное моделирование прецедентов наверняка имеет недоработки в виде недостаточно точно написанного текста и выпущенных из виду альтернативных потоков событий. Полный анализ модели прецедентов должен устранить эти упущения.
• Анализ позволит команде разработчиков обратиться к решению таких задач, как распределение объектов, взаимосовместимость и производительность; как правило, на начальном этапе моделирования прецедентов этим не занимаются.
• В унифицированном процессе анализ представляет собой часть проекта, в которой акцент начинает смещаться от нужд заказчиков к потребностям разработчиков, направленным на то, чтобы разработать систему правильно. Если в ходе технологического процесса управления требованиями на всех этапах нужно консультироваться с заказчиками (или, по крайней мере, они должны быть представлены), то в ходе технологического процесса анализа заказчики привлекаются к работе, только если возникнет необходимость обсудить требования.
Построение
Основные виды деятельности технологического процесса проектирования направлены на построение модели проектирования, которая описывает физическую реализацию прецедентов из модели прецедентов, а также содержание модели анализа. Модель проектирования служит абстракцией модели реализации.
В технологическом процессе проектирования важное место занимает модель развертывания, которая определяет физическую организацию системы в терминах вычислительных узлов.
Основной целью технологического процесса проектирования можно назвать разработку проекта системы, на который команда сможет опираться, переходя к этапу реализации. Результатом выполнения этого процесса является создание модели проектирования и модели развертывания. Модель проектирования воплощает в себе первичные решения, принятые командой разработчиков в отношении распределения объектов, взаимосовместимости, баз данных, пользовательского интерфейса, транзакций и т.д. Модель развертывания определяет территориальное распределение различных компонентов оборудования, на котором будет разработана система.
Модель проектирования и модель развертывания, взятые вместе, представляют собой усовершенствованную и расширенную модель анализа. Суть этого усовершенствования и расширения выражается в следующем.
• Для модели анализа характерна высокая степень абстрактности; разработчики при выполнении анализа уже рассматривали задачи реализации, но не доводили их до логического завершения. Модель проектирования является, скорее, материальной: в ней абстрактные понятия, представленные в модели анализа, переводятся в элементы модели, отражающие будущую реализацию системы (например, определяются сигнатуры операций в используемом языке программирования).
• Модель проектирования обычно содержит намного больше деталей, чем модель анализа; в наибольшей степени это касается особенностей совместной работы объектов, направленной на обеспечение поведения, определенного моделью прецедентов.
• В то время как модель анализа отражает начальные идеи команды в отношении распределения объектов по ярусам или уровням, модель развертывания предоставляет окончательные решения, принятые командой по этим вопросам.
Реализация
Целью технологического процесса реализации является построение модели реализации, которая описывает, как элементы модели проектирования формируют компоненты, такие, как файлы исходного кода, библиотеки динамической компоновки (DLL) и EnterpriseJavaBeans (EJB). При этом создается рабочая версия системы, которую можно предоставить для оценки бета-пользователям. Точкой отсчета этого технологического процесса служит модель реализации, содержащая исходный код и исполняемые файлы, которые вместе формируют реализуемую систему. Команда также работает над расширением модели развертывания, разработка которой была начата в процессе проектирования.
Модель реализации — это воплощение модели проектирования в реальности. Каждый элемент этой модели становится частью компонента, т.е. физической и заменяемой части системы, которая соответствует набору интерфейсов и реализует его. Точно так же и полная модель развертывания отражает воплощение в реальности архитектуры, которая развивалась в процессе работы над разными моделями.
Тестирование
Основные виды деятельности технологического процесса тестирования направлены на построение модели тестирования, которая описывает, как системные тесты и тесты интеграции будут применяться к рабочим компонентам модели реализации. Модель также описывает, как команда будет проводить это, и тестирование модулей.
Модель тестирования содержит набор тестовых данных, которые определяются непосредственно из прецедентов. Тестирование выполняется методом черного ящика с использованием оригинального текста прецедентов и тестирования реализаций этих прецедентов, определенных в модели анализа, методом белого ящика. Тестовая модель также содержит результаты всех уровней тестирования.
Итерации и инкременты
Каждая из фаз унифицированного процесса делится на итерации. Итерация представляет собой просто мини-проект, который является частью фазы.
Типичная итерация в большей или меньшей степени имеет место во всех пяти технологических процессах, описанных ранее. Например, итерация на фазе уточнения сосредоточена на деятельности, связанной с технологическими процессами управления требованиями и анализа, в то время как итерация в фазе построения скорее задействует разработку, реализацию и тестирование.
Результатом итерации является инкремент, который представляет собой версию системы с дополнительными или усовершенствованными функциональными возможностями по сравнению с предыдущей версией.
На рис. 4.3 отображена суть итеративного и инкрементного подхода к разработке программного обеспечения.
Рис. 4.3. Итеративная и инкрементная разработка
Используя итеративный и инкрементный подход, команда проекта начинает процесс разработки с оценки существенных рисков (куда входят риски, связанные с требованиями, квалификацией, технологией и политикой), а также с попытки удостовериться, что определенная область действия проекта удовлетворяет всех. Затем команда выполняет следующее.
1. Определение первой итерации, ориентируясь на самые сложные и критические риски (другими словами, прежде всего более сложная часть работы).
2. Составление плана итерации с подходящим уровнем детализации.
3. Выполнение соответствующих действий; для унифицированного процесса виды деятельности связаны с технологическими процессами управления требованиями, анализа, реализации и тестирования.
4. Разработка постпрограммы для инкремента, который стал результатом итерации.
5. Составление обновленного списка рисков, не учитывая при этом риски, который были устранены в этом инкременте.
6. Оценка общего плана проекта в соответствии с относительным успехом или неудачей при выполнении итерации.
7. Переход к следующей итерации.
В ходе итераций (инкремент за инкрементом) строится шесть моделей. В конце каждой итерации полный набор моделей, которые представляют систему, находится в определенном состоянии; это базовая линия архитектуры.
Для каждого технологического процесса унифицированного процесса определены три элемента: артефакты, исполнители и виды деятельности.
Артефакты
В унифицированном процессе артефактом называют любую значимую внутреннюю или подлежащую сдаче порцию информации, которая играет определенную роль в разработке системы. К основном артефактам построения относятся модели, прототипы пользовательского интерфейса и оценка результатов тестирования. Артефакты управления, такие, как бизнес-план и план проекта, также обсуждаются в контексте пяти технологических процессов и четырех фаз. Одним из исходных условий унифицированного процесса является то, что система не считается готовой к сдаче заказчику, пока все необходимые артефакты (независимо от того, предназначены они для внутреннего использования или для пользователей) не завершены должным образом.
Исполнители
В унифицированном процессе исполнитель определяется как роль, которую индивид может исполнять в ходе выполнения проекта. (Основная разница между понятиями исполнителя и актора в том, что актор находится вне системы и смотрит на нее снаружи, в то время как исполнитель находится внутри системы и, возможно, смотрит наружу, а возможно, и нет. К тому же акторы могут воздействовать и использовать систему, в то время как исполнители являются участниками разработки системы.)
Исполнители создают артефакты как индивидуально, так и в составе подкоманд или команд. Единственное, что нужно запомнить: один человек в ходе процесса может выполнить больше действий, чем исполнитель. Например, аналитик может найти прецеденты и написать к ним текст.
Виды деятельности
Каждый технологический процесс включает несколько видов деятельности.
В контексте технологического процесса вид деятельности можно определить как задачу, которую выполняет исполнитель, чтобы создать артефакт. Виды деятельности, охватывают широкий диапазон, включая как высокоуровневое исследование идей и интересующих клиента моментов (построение модели предметной области), так и кропотливую работу, связанную с физической системой (реализация класса).
Тема 7.
Стандарты управления производством
Исторически, методология Enterprise Requirement Planning (ERP), то есть планирование ресурсов предприятия, является результатом последовательного развития, начавшегося с концепции Material Resource Planning (MRP), обеспечивавшей планирование потребностей предприятий в материалах. Преимущества, даваемые MRP, состоят в минимизации издержек, связанных со складскими запасами сырья, комплектующих, полуфабрикатов и прочего, а также с аналогичными запасами, находящимися на различных участках непосредственно в производстве.
В основе этой концепции лежит понятие Bill Of Material (BOM), то есть спецификации изделия, которая показывает зависимость внутреннего для предприятия спроса на сырье, комплектующие, полуфабрикаты и т.д. от плана выпуска (бюджета реализации) готовой продукции. При этом очень важную роль играет фактор времени, поскольку несвоевременная доставка материалов может привести к срыву планов выпуска готовой продукции. Для того чтобы учитывать временную зависимость производственных процессов, информационной системе, поддерживающей реализацию концепции MRP на предприятии, «необходимо знать» технологию выпуска продукции (технологическую цепочку), то есть последовательность технологических операций и их продолжительность.
На основании плана выпуска продукции, BOM и технологической цепочки в MRP – системе осуществляется расчет потребностей в материалах в зависимости от конкретных сроков выполнения тех или иных технологических операций.
Однако у методологии MRP есть серьезный недостаток. При расчете потребности в материалах не учитываются загрузка и амортизация производственных мощностей, стоимость рабочей силы, потребляемой энергии и т.д. Поэтому в качестве логического развития MRP была разработана концепция Manufacturing Resource Planning (планирование производственных ресурсов), сокращенно называемая MRP II. В рамках MRP II можно уже планировать все производственные ресурсы предприятия: сырье, материалы, оборудование, людские ресурсы, все виды потребляемой энергии и пр.
Далее концепция MRP II развивалась в соответствии с тенденциями изменения рынка и порождаемыми ими новыми потребностями в управлении предприятиями. К MRP II постепенно добавлялись возможности по учету и управлению другими затратами предприятия. Так появилась концепция ERP, называемая иногда также Enterprise-wide Resource Planning (планированием ресурсов в масштабе предприятия). В основе методологии ERP лежит принцип единого хранилища данных (repository), содержащего всю деловую информацию, накопленную организацией в процессе ведения бизнеса, включая финансовую информацию, данные, связанные с производством, управлением персоналом, или любые другие сведения. Это устраняет необходимость в передаче данных от одной информационной системы к другой и создает дополнительные возможности для анализа, моделирования и планирования. Кроме того, любая часть информации, которой располагает данная организация, становится одновременно доступной для всех работников, обладающих соответствующими полномочиями.
Начиная с середины 90-х годов, концепция ERP стала очень популярной в производственном секторе, поскольку ее использование для планирования ресурсов позволило существенно сократить время выпуска продукции, снизить уровень товарно- материальных запасов, а также улучшить обратную связь с потребителем при одновременном сокращении административного аппарата. Методология ERP позволила объединить информацию обо всех ресурсах предприятия добавляя, таким образом, к
MRP II возможности управление заказами, поставками, финансами и т.д.
Итак:
MRP (Material Requirement Planning) – это планирование потребности в материалах;
MRP II (Manufacturing Resource Planning) – это планирование производственных ресурсов;
ERP (Enterprise Resource Planning) – это планирование ресурсов всего предприятия.
Стандарты MRP/ERP поддерживаются Американским обществом по контролю за производственными запасами APICS (American Production and Inventory Control Society).
MRP/ERP – это набор проверенных на практике разумных принципов, моделей и процедур управления и контроля, предназначенных для повышения показателей экономической деятельности предприятия.
Так, изданный APICS в 1989 г. стандарт «MRP II Standard System», содержит 16 групп функций производственно - сбытовой системы:
2. - Планирование продаж и производства (Sales and Operation Planning);
3. - Управление спросом (Demand Management);
4. - Составление плана производства (Master Production Scheduling);
5. - Планирование материальных потребностей (MRP - Material Requirement Planning);
6. Спецификация продуктов (Bill of Materials);
7. Управление запасами (Inventory Transaction Subsystem);
8. - Управление плановыми поставками (Scheduled Receipts Subsystem);
9. - Управление на уровне производственного цеха (Shop Flow Control);
10. - Планирование производственных мощностей (CRP – Capacity Requirement Planning);
11. - Контроль входа/выхода рабочих потоков (Input/output control);
12. - Материально техническое снабжение (Purchasing);
13. - Планирование ресурсов для распределения (DRP – Distribution Resource Planning);
14. - Планирование и контроль производственных операций (Tooling Planning and Control);
15. - Управление финансами (Financial Planning);
16. - Моделирование для производственной программы (Simulation);
17. - Оценка результатов деятельности (Performance Measurement).
С накоплением опыта моделирования производственных и непроизводственных бизнес -процессов эти понятия постоянно уточняются, постепенно охватывая все больше функций. Развитие стандарта MRP/ERP проиллюстрировано в Таблице 1.
Таблица 1. Историческая справка (Gartner Group)
Дата добавления: 2018-11-24; просмотров: 225; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!