|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
|
|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Методики внедрения информационных системСтр 1 из 6Следующая ⇒
Методики внедрения информационных систем Оглавление 1. Место процессов внедрения в ЖЦ информационных систем.. 2 2. Модели внедрения ИС.. 3 3. Стандарты, регламентирующие процессы внедрения ИС.. 7 4. Основные модели внедрения решений на платформе 1С.. 9 5. Общие сведения, структура, понятия методологии быстрого результата 1С.. 10 6. Документирование при внедрении проектов на платформе 1С.. 11 7. Общие сведения, структура, понятия Microsoft Dynamics Sure Step. 12 8. Компоненты модели внедрения Microsoft Dynamics Sure Step. 15 9. Документирование при внедрении по модели внедрения Microsoft Dynamics Sure Step. 17 10. Общие сведения, структура, понятия методологии Oracle Financial Analyzer — Oracle Data Warehouse Method (DWM) 22 11. Основные компоненты модели внедрения Oracle. 27 12. Документирование при внедрении по модели внедрения Oracle Data Warehouse Method (DWM) 34 13. Различие в подходах и содержании мероприятий внедрения при использовании различных методологий внедрения. 35 14. Требования к документированию при внедрении ИС.. 36 15. Требования к формированию инфраструктуры проекта по внедрению ИС.. 38 17. Возможные критерии анализа эффективности использования методологии внедрения. 41
Место процессов внедрения в ЖЦ информационных систем Процесс внедрения является совокупностью задач по вводу в эксплуатацию системы у некоторого заказчика. Внедрение – длительный процесс. Суть внедрения: берём шаблон-исходник, устанавливаем и настраиваем в рамках, допустимых исходником.
Заказчик – организации, юридическое лицо, которое приобретает, получает систему или отдельный программный продукт, или отдельную программную услугу (облачные вычисления и т.д.)
Под задачей понимается минимальная процессуальная единица внедрения, содержащая конкретные описания решения проблемы, документы, удостоверяющий выполнение, информацию о трудозатратах. Т.е. задача имеет максимально полное описание. Делается это для того, чтобы можно было описать, оценить проект. Для описания задачи необходимо: - Входные параметры (что до неё выполнилось). - Документы на входе. - Итог выполнения задачи. - Документы на выходе. - Какие ресурсы необходимо для выполнения. Задача, по сути, - деятельность из IDEF0.
Поставщик – юридическое понятие, организация, которая заключает договор с заказчиком на поставку услуг или программ. Поставщик может быть чисто юридическим лицом (чисто в документах), может быть вендором (компания, которая занимается разработкой ИС).
Вендор определяет методологию внедрения своего ПП или общие практики внедрения (в худших случаях)
Методология – документ, описывающий типовые процессы внедрения. Обобщает опыт внедрения и направлена на минимизацию рисков (обычно в ней прописано максимальное количество рисков). Является совещательными, рекомендательными документами. Каждый интегратор обычно составляет собственную методологию и могут либо передавать, либо не передавать её вендору (второе – плохо). Существует опыт, что методология внедрения собирается в течение 5-6 лет, формализуется и вводится на какой-то период (примерно 5-7 лет). Т.о. методология идёт с запаздыванием относительно самой системы. Нельзя прописать методологии ранее, т.к. там не будет рисков.
Интегратор – организация, осуществляющая внедрение ИС. Не занимаются созданием ИС, чаще всего используют несколько ПП, соответствующим нескольким методикам внедрения, предлагаемым вендорами (пример: битрикс). Чаще всего компании используют несколько крупных систем и несколько мелких, чтобы можно было внедрять разным фирмам.
Стоимость внедрения = стоимость системы + стоимость внедрения + сторонние затраты
Связь процессов внедрения с этапами ЖЦ по 12207 Этап Подготовка: Анализ заказа Формализация задачи Анализ бизнес-системы (объекта автоматизации) Выработка требований Оценка модели Этап Планирование: Выработка сценариев Отображение бизнес-системы Планирование инфраструктуры проекта Аудит Реализация Выбор модели ЖЦ Формирование надзорной группы Формирование системной архитектуры Конверсия данных Системное документирование Системное управление Создание инфраструктуры Кодирование Инсталляция программно-аппаратной среды Пользовательское документирование Верификация Тестирование Квалификационное испытание Ввод и эксплуатация Ввод в эксплуатацию Обеспечение качества Сверка сальдо Промышленная эксплуатация Снятие с эксплуатации
Модели внедрения ИС Внедрение по ГОСТ 12207 Этапы: 1. Подготовка 2. Планирование 3. Выполнение 4. Ввод в эксплуатацию 5. Эксплуатация
Подготовка Первичное взаимодействие с заказчиком, что он из себя представляет. BP Win, проектирование ИС. Нужно определить, какие функции искать в программном продукте. Интегратор осуществляет тесный контакт со всеми сотрудниками, т.к. представленное руководство отличается от реалий на местах. Интегратор формулирует требования, которые предъявляет заказчик к Интегратору (ГОСТ требует от Интегратора формирования требований заказчика) Выход: требования к внедрению ИС (не ТЗ! )
Планирование Интегратор ищет максимально подходящего вендора: просчитываются функциональные и нефункциональные требования, просматриваются методологии и выбирается вендор. Далее происходит просчёт самого процесса внедрения (риски, ресурсы (время, деньги, люди). Выход: ТЗ на внедрение – обсчитанный проект на внедрение с учётом конкретного заказчика, вендора и интегратора, т.к. разный этап могут выполнять разные фирмы) Этот этап примерно по времени сопоставим со всеми остальными этапами (м.б. даже дольше)
Выполнение Форм[альное] исп[олнение] ТЗ (? ) Чёткое разделение функций (кто и что делает), чёткий контроль выполнения сроков и объёмов работ.
Ввод в эксплуатацию ГОСТ разделяет выполнение от ввода в эксплуатацию. По ГОСТ выполнение – подготовка системы (доработка), ввод в эксплуатацию – ввод данных и настройка инфраструктуры.
Эксплуатация Эксплуатация = сопровождение (а не изменение) ИС. Т.е. обучение пользователей, а не изменение. Доработка – отдельный процесс внедрения.
Риски Риски – обобщённый опыт конкретного интегратора, зависят от отраслевой и национальной специфики и специфики конкретного вендора. Очень важные, но слабо прописаны в ГОСТах. Обычно хорошо прописаны у вендора, т.к. у них хорошо налажен процесс консолидации опыта.
Основные понятия методологии Проектная технология – организационная деятельность по внедрению 1С в рамках проекта по внедрению в организацию. Размер проекта – интегральная величина, описывающая сложность и нестандартность БП, объём информации, которая будет обрабатываться и которую нужно обработать во время проекта и количество информации, которую нужно перенести. Типовые сценарии проектов внедрения: - экспресс- внедрение - стандартное внедрение - технология проектного внедрения - корпоративное внедрение (максимально широкое, в разных филиалах) - бухгалтерский консалтинг - управленческий консалтинг Показатели, по которым оценивается сложность проекта: - размер проекта - сложность и трудоёмкость задачи, которая автоматизируется - количество АРМ - распределённость проекта - количество участников проектной команды - количество и разнообразие связей с внешними ИС - размер юридических, социальных, экономических последствий выполнения проекта
Общие сведения Методология Microsoft Dynamics Sure Step (MDSS) представляет собой комплексную методологию внедрения, содержащую в себе рекомендации, стратегии управления проектами, инструменты и шаблоны, которые партнеры корпорации Майкрософт могут использовать для внедрения продуктов Microsoft Dynamics для своих клиентов. MDSS применяется как в крупных и средних, так и в небольших проектах внедрения систем на платформе Microsoft Dynamics. Методология Microsoft Dynamics Sure Step охватывает весь спектр программных решений Microsoft Dynamics: - Microsoft Dynamics AX, - Microsoft Dynamics NAV, - Microsoft Dynamics CRM.
Структура методологии Методология Sure Step содержит подробное руководство по всему жизненному циклу внедрения. В нем излагается опробованная методика внедрения, базирующаяся на опыте внедрения партнерами Microsoft Consulting и Microsoft Dynamics. Методология Microsoft Dynamics Sure Step включает руководство по управлению проектами, а также средства, интегрированные во все компоненты методологии внедрения. Таким образом, методология Sure Step предлагает руководство по управлению проектами внедрения и выполнению функциональных и технических задач, составляющих основу процесса внедрения Microsoft Dynamics. Наиболее полезные компоненты методологии Sure Step - средства и шаблоны, позволяющие создавать технические и проектные конечные результаты, формируемые в ходе проекта внедрения. Методология Sure Step предлагает широкий набор шаблонов Microsoft Office, которые можно использовать для создания конечных результатов внедрения. Она также включает множество схем процесса, которые позволяют наглядно представить каждый этап процесса внедрения и найти в методологии определенные сведения о задачах внедрения. Методология Sure Step также включает средство редактирования, позволяющее партнерам выполнять индивидуальную настройку методологии Sure Step, чтобы обеспечить поддержку средств внедрения, процессов и задач партнера. Партнеры могут добавлять средства и шаблоны, добавлять или изменять задачи, процессы и руководство, чтобы лучше адаптировать методологию к определенной практике партнера и отрасли.
Подход к проектам внедрения Методология MDSS определяет стандартизованный поэтапный подход к проектам внедрения. Методология Sure Step призвана помочь партнерам Майкрософт внедрять решения Microsoft Dynamics в последовательной и повторяемой форме. Она предоставляет опробованные передовые методы внедрения, которые можно использовать в проектах внедрения. Методология Sure Step является достаточно гибкой для использования в различных сценариях внедрения, и позволяет удовлетворить различные потребности клиентов и улучшить результаты внедрения. Модель внедрения, образующая основу методологии Microsoft Dynamics Sure Step, включает следующие компоненты: - Этапы (Диагностика, Анализ, Дизайн, Разработка, Развёртывание, Эксплуатация); - процессы; - предложения (варианты внедрения); - конечные результаты; - межэтапные процессы (затрагивают несколько этапов, имеют единый вектор, хоть и разную специфику); - процедуры управления проектами; - роли консультантов и клиентов. Методологию внедрения MDSS можно использовать в трёх вариантах: 1. Быстрое внедрение: Диагностика-> Развёртывание-> Эксплуатация 2. Двухэтапное внедрение: 1) Диагностика+Детальный анализ 2) Внедрение (дизайн, разработка, развёртывание, эксплуатация) 3. Полное внедрение – весь цикл этапов
Диагностика Задача: получить завершённые результаты, которые будут содержать предложения по проекту, предварительное планирование, описание проекта и оценку инфраструктуры. Завершение: подписание документа, который определяет объёмы и рамки проекта и ресурсы, которые необходимы. Этот документ – соглашение о том, «что хочется сделать». Также необходимо формально перечислить все возможные трудности. Рекомендация к этапу: максимальная формализация. Анализ Начинается с формирования проектной команды, формализуется её состав, роли и точки зрения на проект, происходит погружение команды в программный продукт для того, чтобы сотрудники клиента взглянули на ПО со стороны MS Dynamics AX. Происходит параллельное диагностирование всех подразделений, детальный анализ всех бизнес-процессов и их формализация. Также производится новый анализ инфраструктуры с учётом новых требований, а также анализ и планирование миграции данных. Завершение: документ с функциональными требованиями, который дополнительно содержит требования к контролю качества и тестированию; устав проекта (все соглашения внутри проекта) и план-график проекта. Дизайн Создание спецификации дизайн-решения, интеграция с внешними системами и миграция данных. Завершение: техническая спецификация проекта (конкретные сроки, исполнители, ПО и т.д.) Разработка Параллельная разработка всех модулей, выполнение формального соответствия работы с документами. Сложность – в тестировании. Развёртывание Происходит объединение команды, при этом усиливается нагрузка на сотрудников заказчика. Осуществляется запуск системы и контролирование валидности её реализации, тренинг и обучение персонала, нагрузочное тестирование, тестирование конечными пользователями. Эксплуатация Приёмка системы заказчиком, формирование пакетов документов по закрытию проекта, обучение (знакомство с платформой – обучение конкретному решению – помощь сотрудников друг другу). Завершение: внутренние и внешние конечные документы.
Методология Sure Step представляет процессы по каждому этапу двумя способами: - иерархический список операций, задач и подзадач, представленный в древовидной структуре методологии Sure Step; - схемы процессов в виде схем Microsoft® Visio®, являющиеся графическим изображением операций каждого этапа методологии. Предложения определяют различные варианты продажи и поставки внедрения решения Microsoft Dynamics. Предложения, определенные в методологии Sure Step, поддерживают различные сценарии внедрения. Они соответствуют различным этапам или сочетаниям этапов модели методологии, и позволяют партнеру выбрать подход внедрения, наилучшим образом удовлетворяющий конкретные потребности клиента.
Методология Microsoft Dynamics Sure Step поддерживает следующие предложения услуг: - диагностика; - подробный анализ; - анализ; - внедрение; - полное внедрение; - быстрое внедрение; - оптимизация; - обновление. Межэтапный процесс — это группа связанных операций, охватывающих несколько этапов внедрения в конкретном сценарии проекта. Методология Sure Step содержит следующие межэтапные процессы: - анализ бизнес-процесса; - настройка; - миграция данных; - инфраструктура; - установка; - интеграция; - тестирование; - обучение. Ниже представлены примеры основных ролей, поддерживаемых методологией Sure Step. Роли консалтинга - Руководитель проекта - Менеджер по контактам - Архитектор решений - Консультант по приложениям - Консультант по разработке - Технический консультант Роли клиента - Руководитель, принимающий решения - Руководитель проекта - Руководитель отдела ИТ - Ключевой пользователь - Конечный пользователь Этап 1: диагностика Этап начинается с подготовительной деятельности, основная цель которой — сформировать команду для проведения диагностики. Как только команда собрана и проинструктирована, первой ее задачей станет высокоуровневый анализ бизнес-требований. В некоторых компаниях имеются бизнес-процессы, заключающие в себе высокие риски в силу большой доли неопределенности в них. Для таких процессов рекомендуется более детальный бизнес-анализ. Задачи детального анализа на этапе диагностики сводятся к получению достаточной информации для точного определения рамок проекта и объема предполагаемых работ. В некоторых случаях могут потребоваться отдельное коммерческое предложение и контракт на проведение детальной диагностики. Как только анализ бизнес-процессов будет завершен, у проектной команды появится достаточно информации для высокоуровневого определения границ и рамок проекта. Отдельная часть предложения на внедрение системы посвящена инфраструктуре. Клиент хочет понимать, каковы будут суммарные инвестиции в проект развертывания Microsoft Dynamics. Задачи инфраструктурного анализа определяются на этапе диагностики, но их выполнение можно перенести на этапы анализа или дизайна, в зависимости от конкретного клиента. Финальный набор задач заключается в планировании проекта – определении ресурсов, времени и бюджета для развертывания решения. В завершение этапа диагностики необходимо оценить бизнес-требования, объем и рамки проекта, а также план проекта, и исходя из этого определить, что рационально в данном случае – быстрое или полное внедрение Microsoft Dynamics. Основные результаты этапа - Предложение по работе над проектом: o описание содержания проекта (отчет о диагностике, рабочая тетрадь бизнес-процессов); o предварительный план проекта (включая идентификацию и рамки проекта). - Оценка инфраструктуры. Основные вехи этапа - Клиент принимает предложение на внедрение и контракт, включая предполагаемый объем и рамки проекта, а также предварительный план проекта.
Этап 2: анализ Этап анализа начинается с действий, направленных в первую очередь на формализованное создание проектной команды – как со стороны консультанта, так и со стороны заказчика. Следует обратить особое внимание на совещание по запуску проекта (Kick Off Meeting), на котором должны быть представлены участники проектной команды и согласованы ожидания и взгляды на то, как будет протекать проект. Следующая по важности задача после проведения kickoff-встречи — необходимость ознакомить ключевых пользователей с Microsoft Dynamics. Тренинг должен быть нацелен на пользователей, которые будут непосредственно участвовать в детальном анализе, а также на ключевых пользователей из бизнес-единиц компании-заказчика, вовлеченных в проект. Далее запускается ряд параллельных операций, набор которых зависит от объема проекта и доступных ресурсов. В первую очередь проектная команда должна продолжить детальный анализ бизнес-процессов, начатый на этапе диагностики. Как только завершится анализ разрывов, рекомендуется провести ревизию требований к инфраструктуре с целью удостовериться, что ни одно из новых требований не повлияет на изначально предложенную инфраструктуру. Анализ и планирование миграции данных также следует проводить на стадии анализа. Проектная команда должна идентифицировать существующие источники информации и оценить, что потребуется для миграции данных. Когда анализ всех требований будет завершен, собранная информация агрегируется и на ее основе создается документ «Функциональные требования», который заказчик проверяет, одобряет и подписывает. Основные результаты этапа - Устав проекта. - План и тренинги ключевых пользователей. - Детальный анализ бизнес-процессов: o анализ разрывов требований с базовой функциональностью; o оценка устранения разрывов; o описание интерфейсов. - План миграции данных. - План проекта. - Функциональные требования: o инфраструктура, функциональность и безопасность; o интеграция. - Требования к контролю качества и тестированию. Основные вехи этапа - Проведено совещание по запуску проекта. - Заказчик утверждает Устав проекта. - Проводится тренинг по Microsoft Dynamics AX для ключевых пользователей. - Заказчик утверждает «Функциональные требования», включая описания бизнес-процессов, интеграции и миграции данных. - Заказчик утверждает обновленный план-график проекта.
Этап 3: дизайн Основа этапа дизайна закладывается еще на этапе анализа и регламентируется порожденными на ней артефактами, в частности, результатом анализа бизнес-процессов и планом миграции данных. Цели этапа дизайна включают следующее (но не ограничиваются этим): - Создать или обновить целостный дизайн решения и соответствующие документы, которые потребуются для того, чтобы решение соответствовало функциональным требованиям. - Создать верхнеуровневую спецификацию для каждой модификации системы, настраиваемой обработки, специфичных отчетов и интеграций, определенных в документе «Функциональные требования». - Создать детальное описание требований к преобразованию данных в соответствии с тем, что было определено в ходе анализа и планирования миграции данных на этапе анализа. - Получить одобрение от заказчика верхнеуровнего плана миграции данных и спецификации дизайна решения, прежде чем приступать к созданию детальной спецификации дизайна и проведению финальных оценок. - Создать детальную спецификацию дизайна решения на основе верхнеуровневой структуры дизайна, одобренной клиентом. - Провести и представить заказчику окончательные оценки разработки, создания модификаций, настройки, интеграции и миграции данных. - Получить утвержденные заказчиком дизайн решения, спецификации модификаций системы, дизайн миграции данных и оценки всех перечисленных операций. Основные результаты этапа - Спецификация дизайна решения: o o функциональный дизайн; o o техническая спецификация. - Дизайн интеграции с внешними системами. - Дизайн миграции данных и определение соответствий структур данных. - План и сценарии тестирования. Основные вехи этапа - Заказчик утверждает спецификацию дизайна решения, дизайн интеграции с внешними системами и дизайн миграции данных. - Заказчик утверждает время разработки и оценку расходов.
Этап 4: разработка Планирование этапа разработки включает просмотр требований к разработке, расстановку приоритетов и распределение ресурсов. Затем настраивается среда разработки и тестирования, а план тестирования, работа над которым была начата на стадии дизайна, окончательно прорабатывается для каждого настраиваемого процесса. Текущие операции разработки протекают параллельно в зависимости от того, какие ресурсы имеются в распоряжении проектной команды. Например, можно параллельно разрабатывать дополнительную функциональность системы, способы интеграции и миграции данных. Операции разработки включают тестирование разработанных модулей. Кроме того, необходимо функциональное тестирование, проводимое командой консультантов. В идеале тестирование должно выполняться не самими разработчиками, а кем-либо еще, и проводиться по согласованному ранее плану тестирования. Как только завершится цикл разработки какой-либо дополнительной функциональности, можно приступать к подготовке как технической, так и пользовательской документации на эту функциональность, включая дополнительные тренинги для пользователей. Заказчик начинает тестирование процессов согласно критериям, сформулированным на этапе дизайна. Такое тестирование подтверждает корректность настройки функциональности, интеграции и миграции данных. Циклы разработки и тестирования продолжаются до тех пор, пока результаты тестирования не будут отвечать определенным ранее критериям тестирования и не удовлетворят заказчика. На данном этапе проекта важны такие процессы, как управление объемом и рамками проекта и управление изменениями. Реализация отдельных функций, интеграция и миграция данных могут быть перенесены на другие этапы разработки в зависимости от их масштаба, сложности и доступных ресурсов. Основные результаты этапа - Настройка решения Microsoft Dynamics. - Подготовка документации по решению Microsoft Dynamics (технической и пользовательской). - Разработка дополнительной функциональности (кастомизаций) (дополнения и модификации). - Настройка и тестирование миграции данных. - Интеграционное тестирование (в том числе интеграции с внешними системами). - Результаты тестирования Основные вехи этапа - Выполняется миграция данных. - Выполняется интеграционное тестирование. - Заказчик принимает созданное решение, результаты тестирования и документацию.
Этап 5: развертывание На этапе развертывания все усилия проектной команды объединяются и направляются на успешную передачу заказчику решения Microsoft Dynamics. В рамках этого этапа есть несколько важных задач, которые должны быть выполнены для успешного достижения цели. Этап включает в себя все операции, связанные с завершающим тестированием (в том числе нагрузочным), тренингами пользователей и окончательным переходом на новую рабочую среду. Основные результаты этапа - План запуска и контрольный список. - План тестирования системы. - План обучения пользователей. - Тренинги для пользователей. - Рабочая система. Основные вехи этапа - План запуска и контрольный список. - План тестирования системы.
Этап 6: эксплуатация После успешного запуска системы и подписания акта приемки этапа развертывания могут быть запущены две параллельные группы задач. Первый набор задач — различные завершающие операции проекта, связанные с окончательной передачей знаний от проектной команды заказчику. Некоторые проектные операции остаются открытыми после запуска системы — это вполне обычное явление. Очень важно пройти по всем этим открытым операциям и получить согласие заказчика на их закрытие. Закрытие проекта также включает поставку оставшейся документации, опциональные дополнительные тренинги пользователей и финальную передачу знаний. Второй набор задач представляет собой важные «пост-запускные» операции, которые подразумевают присутствие участников проектной команды у заказчика на протяжении определенного периода времени с целью удостовериться в том, что рабочая среда корректно функционирует, и оказать помощь при возникновении непредвиденных ситуаций. Это потенциально объемный набор задач, которым необходимо управлять, и он имеет фиксированную дату завершения. После закрытия проекта, передачи знаний и пост-запускной поддержки рекомендуется провести совместный анализ проекта. Это отличная возможность обсудить проект и вынести из него соответствующие уроки. На этой точке взаимодействие с заказчиком ведется в рамках предварительно согласованной поддержки продукта (с подписанием соответствующего контракта). Команда консультанта переключается на следующий проект. Основные результаты этапа - Приемка системы заказчиком. - Документы для закрытия проекта (техническая и пользовательская документация). - Соглашение о поддержке системы. Основные вехи этапа - Заказчик принимает Microsoft Dynamics и подписывает акт ввода в промышленную эксплуатацию. - Заказчик формально закрывает проект. - Заказчик подписывает договор поддержки. Oracle Financial Analyzer Oracle Financial Analyzer (OFA, Финансовый анализатор Oracle) предназначена для формирования финансовой отчетности, анализа, прогнозирования, бюджетного планирования и контроля исполнения бюджетов. Объединяя централизованный источник управленческих данных с мощными аналитическими возможностями, OFA позволяет принимать, контролировать и оценивать решения на всех уровнях организации. Ключевыми бизнес-процессами являются. Система поддерживает выполнение таких финансовых функций, как контроль затрат, анализ эффективности, оценка возможностей и формирование будущей стратегии.
Методология внедрения OFA Внедрение OFA производится на основе применения методологии Oracle Data Warehouse Method, заточенной непосредственно под OFA (Oracle Data Warehouse Method Oracle Financial Analyzer (DWM OFA)). Границами применения методологии является разработка и внедрение системы, основанной на технологии OFA. В подходе центральное место выделяется бизнес-требованиям пользователя и рассматриваются все компоненты внедряемой системы: - Извлечение, преобразование, передача и загрузка исходных данных; - Техническую архитектуру; - Пользовательские интерфейсы; - Отчёты и спецификации; - Схему базы данных; - Специфические настройки системы под пользователя. В дополнение к разработке компонентов системы методология намечает в общих чертах задачи для обучения, тестирования и переходу к промышленной эксплуатации.
Процессы Методология выделяет следующие процессы: 1. Определение бизнес-требований; 2. Сбор данных; 3. Определение технической архитектуры; 4. Определение форм доступа к данным; 5. Проектирование и построение базы данных; 6. Документирование; 7. Тестирование; 8. Обучение; 9. Передача в промышленную эксплуатацию. Цели каждого процесса приведены в таблице 1. Таблица 1 – Цели процессов DWM OFA Популярное:
|
Последнее изменение этой страницы: 2016-05-03; Просмотров: 4391; Нарушение авторского права страницы