Внедрение информационной системы

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И  НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

федеральное агентство по образованию

Государственное образовательное  учреждение высшего профессионального  образования

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ  УНИВЕРСИТЕТ 
ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ, МЕХАНИКИ И ОПТИКИ

ФАКУЛЬТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И ПРОГРАММИРОВАНИЯ

КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ

направление 080700 -Бизнес – информатика.

 

ОТЧЕТ

 

ПО ДИСЦИПЛИНЕ  ПРОЕКТНАЯ ДОКУМЕНТАЦИЯ

НА ТЕМУ       ВНЕДРЕНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

 

 

 

Студента _3_ курса

группы № 3522

Фамилия Кармов

Имя         Анзор

 

 

 

 

Преподаватель .Маятин А.В._

Оценка _______________________

Подпись преподавателя _________

 

 

САНКТ-ПЕТЕРБУРГ

2011

 

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И  НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

федеральное агентство по образованию

Государственное образовательное учреждение высшего профессионального образования

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ  УНИВЕРСИТЕТ 
ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ, МЕХАНИКИ И ОПТИКИ

ФАКУЛЬТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И ПРОГРАММИРОВАНИЯ

КАФЕДРА ИНФОРМАЦИОННЫХ СИСТЕМ

направление 080700 -Бизнес – информатика.

 

ОТЧЕТ

 

ПО ДИСЦИПЛИНЕ  ПРОЕКТНАЯ ДОКУМЕНТАЦИЯ

НА ТЕМУ       ВНЕДРЕНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

 

 

 

Студенты _3_ курса

группы № 3522

Кармов Анзор

Лисовой Георгий 

 

 

 

 

Преподаватель .Маятин А.В._

Оценка _______________________

Подпись преподавателя _________

 

 

САНКТ-ПЕТЕРБУРГ

2011

 

  • Основной дескриптор: «Внедрение информационной системы».

 

  • Эквивалентные понятия: «Развертывание», «Deployment».

 

  • Использованные стандарты:
  • Cobit 4.1 Control Objectives for Information and Related Technology (Задачи информационных и смежных технологий) 
  • ГОСТ Р ИСО/МЭК 12207-99 процессы жизненного цикла программных средств
  • ГОСТ Р ИСО/МЭК ТО 15271-2002 – руководство по применению ГОСТ Р ИСО/МЭК 12207
  • ГОСТ 19.102-77 Единая система программной документации. Стадии разработки
  • RUP - Rational Unified Process (Комплексный/Унифицированный процесс разработки ПО)
  • UML – Unified Modeling Language

 

  • Рабочие определения:

 

  • Новые системы должны быть готовы к эксплуатации после завершения разработки. Для этого необходимо тестирование в выделенной тестовой среде подходящих тестовых данных, определение инструкций по миграции, планирование выхода версии и внедрение в промышленную эксплуатацию, а также анализ результатов внедрения. Это обеспечит соответствие эксплуатируемых систем ранее сформулированным ожиданиям и требованиям. [Cobit 4.1]
  • Подготовка и передача программы и программной документации для сопровождения и (или) изготовления. Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление. Передача программы в фонд алгоритмов и программ. [ГОСТ 19.102-77 Единая система программной документации. Стадии разработки]
  • Обеспечение полного соответствия продукта нуждам пользователей. [RUP - Rational Unified Process (Комплексный/Унифицированный процесс разработки ПО) http://www.rup-rus.ru/faza-vnedrenie-celi-i-iteracii-vexa-gotovogo-produkta-sostoyanie-osnovnyx-artefaktov/ ]
  • A deployment is a dependency relationship which describes allocation (deployment) of an artifact to a deployment target.

Deployment could be shown as a dependency that is drawn from the artifact (supplier) to the deployment target (client) and is labeled with “deploy”. Note, that dependency usually points from the client to supplier, I.E. in the direction oppose to what is recommended by UML 2.4 for deployment. On the other hand, UML specification allows to change direction for a dependency based on user’s stipulations. [UML – Unified Modeling Language http://www.uml-diagrams.org/deployment-diagrams-reference.html]

  • Формализация метода внедрения. Формализация включает в себе введение нового процесса в ряд проектов и (или) в организации. При этом принимают и используют такие методы. как обучение, документирование, предоставление инструментальных средств для нового процесса(ов), а также слежение за данным процессом(ами) и определение его недостатков. В любом утвержденном и реализуемом проекте должно быть осуществлено планирование перехода к новому процессу(ам).  [ГОСТ Р ИСО/МЭК ТО 15271-2002 – руководство по применению ГОСТ Р ИСО/МЭК 12207]

 

  • Вышестоящий дескриптор: «Фаза жизненного цикла», «Жизненный цикл программного обеспечения».

 

  • Связанные понятия:
  • Dependency : A dependency is a directed relationship used when some element or a set of elements requires (needs) other model elements for specification or implementation. It means that complete semantics of the depending elements is either semantically or structurally dependent on the the supplier element(s).
  • Artifact: An artifact is a classifier that represents some physical entity, a piece of information that is used or is produced by a software development process, or by deployment and operation of a system. Artifact is a source of a deployment to a node. A particular instance (or "copy") of an artifact is deployed to a node instance. 
  • Deployment target is the location for a deployed artifact.
  • Процесс (process): Совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующей входы в выходы.
  • Проект (project): Уникальный процесс, состоящий из совокупности скоординированной и управляемой деятельности с начальной и конечной датами, предпринятый для достижения цели, соответствующей конкретным требованиям, включая ограничения сроков, стоимости и ресурсов.
  • Поставщик (supplier): Организация или лицо, предоставляющее продукцию.
  • заказчик (acquirer): Организация, которая приобретает или получает систему, программный продукт или программную услугу от поставщика.
  • модель жизненного цикла (life cycle model): Структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования.
  • система (system): Комплекс, состоящий из процессов, технических и программных средств, устройств и персонала, обладающий возможностью удовлетворять установленным потребностям или целям.
  • пользователь (user): Лицо или организация, которое использует действующую систему для выполнения конкретной функции.

 

  • Ссылки на открытые ресурсы:
  • http://ru.wikipedia.org/wiki/внедрение_програмного_обеспечения
  • http://www.uml-diagrams.org
  • http://www.rup-rus.ru
  • http://pro-spo.ru/
  • http://gost.prototypes.ru/oks/35.020/

 

  • Обновляемый блок:
  • Внедрение программного обеспечения — процесс настройки программного обеспечения под определенные условия использования, а также обучения пользователей работе с программным продуктом. http://ru.wikipedia.org/wiki/внедрение_програмного_обеспечения
  • Внедрение нового программного продукта в бизнес-процессы предприятия включает в себя технические и административные мероприятия и, как правило, состоит из установки нового ПО на рабочих местах, отладки его в реальных задачах, настройки интерфейсов и прав доступа, а также обучения пользователей на их рабочих местах. Начало и конец периода внедрения определяется введением реальных данных в автоматизированную систему и готовностью персонала к самостоятельной работе. Время этого этапа будет складываться из оговорённого срока внедрения (ориентировочно полгода), количеством совместно работающих приложений, объёма дополнительных доработок, не вошедших в техзадание, и срока персональной работы специалистов - интеграторов с сотрудниками - пользователями на рабочих местах. http://orgcentr.com/kompaniya_orgcentr/uslugi/vnedrenie/
  • Внедрение систем - это комплекс специфических задач, выполнение которых позволяет добиться реальной эксплуатации решения в организации. В общем случае процесс внедрения состоит из ряда организационных действий, подготовительных работ технического и административного плана тестовой (опытной) и промышленной эксплуатации. 

http://www.rus-lib.ru/book/38/men/21/3.8..html

 

  • Комментарии:

Внедрение информационных систем – сложный многоэтапный процесс настройки программного обеспечения под определенного пользователя. На сегодняшний день, существует множество методологий и стандартов внедрения. Большинство из них иностранного происхождения. Во время сбора информации для выполнения данной работы, трудности вызвало нахождения ГОСТОВ, описывающих данный этап жизненного цикла программного обеспечения. Удивило что ГОСТ 19.102-77 (Единая система программной документации. Стадии разработки), введенный 01.01.80 до сих пор действующий.

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

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

 

  • Полезные ссылки:
    • http://www.aksionbkg.com/articles/2 
      Статья «Некоторые проблемы внедрения корпоративных информационных систем»
    • http://www.cfin.ru/itm/manit.shtml

Статья «Менеджмент внедрения информационных технологий в систему управления предприятием»

Сегодняшняя ситуация на рынке  консалтинга характеризуется двумя  особенностями: с одной стороны, достаточно много предложений по разработке и внедрению решений  класса ERP (Enterprise Resource Planning), с другой - практически отсутствует положительный опыт их успешной реализации.

В статье проведен анализ причин такого положения и рассмотрена  возможность применения системного подхода при проведении изменений.

 

    • http://www.rugost.com/  Проект RUGOST1.0 предназначен для помощи IT компаниям в работе с государственными заказчиками. Сайт содержит ГОСТы, примеры разработанных документов по ГОСТ (ТЗ, ТП,РД), шаблоны документов по ГОСТ.
    • http://www.intuit.ru/department/itmngt/isimman/

Курс «Управление  внедрением информационных систем» Цель курса - объединить рекомендации методологий внедрения и стандартов управления проектами, чтобы дать читателю целостное представление о методических основах выполнения специфических проектов - проектов внедрения информационных систем.

 

  • Практики:

Внедрение ERP на практике: описание примера внедрения  системы Microsoft Dynamics AX

ООО "ГСК" ("Группа Строительной Комплектации") — профессиональный специализированный поставщик комплектующих для  систем отопления, водоснабжения и  климатконтроля помещений. Компания имеет распределенную структуру: головной офис находится в Санкт-Петербурге, филиалы — в нескольких городах России, в которых располагаются офисы продаж и распределительные центры.

Централизованная база данных находится в головном офисе компании, филиалы получают доступ к БД через "тонкие" клиенты и через терминальные серверы.

Решение является масштабируемым, что позволяет быстро и без  привлечения компании-внедренца  подсоединять новые филиалы в  общее информационное пространство.

Компания работает в основном с иностранными поставщиками, номенклатурный ассортимент превышает 5000 позиций. Количество обслуживаемых клиентов – более 1500.

Выбор системы

К моменту принятия решения о внедрении новой  информационной системы бизнес компании ежегодно увеличивался на 40--60% и устаревшая система автоматизации бизнес-процессов  перестала справляться со все  новыми и новыми потребностями.

Руководство компании "ГСК" выбирало замену из следующих информационных систем: Microsoft Dynamics AX, Microsoft Dynamics NAV, Oracle и SAP. Последние две были отметены практически сразу из-за больших затрат на внедрение и высокой совокупной стоимости владения. В итоге была выбрана Dynamics AX как наиболее полно отвечающая следующим критериям: гибкость в адаптации под профиль деятельности заказчика, невысокая стоимость лицензий и внедрения, возможность использования стандартного функционала системы для устоявшихся бизнес-процессов в компании.

Выбор партнера

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

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

Исходя из перечисленных  выше критериев поставщиком системы  была выбрана международная консалтинговая компания Columbus IT.

Проект внедрения

Проект стартовал  в августе 2004 года. Проектная команда  состояла из 6 ведущих специалистов со стороны интегратора, работающих в головном офисе компании "ГСК", и всех ключевых пользователей бизнес-процессов  со стороны заказчика. При реализации проекта использовалась методология DIAMOND, в основу которой заложен пошаговый механизм внедрения, гарантирующий соответствие полученного решения поставленным задачам и обеспечивающий оперативную и гибкую реакцию на изменения бизнеса в процессе внедрения.

Методология DIAMOND предусматривает следующие этапы  работ:

Анализ и  дизайн

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

Построение  системы

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

Внедрение

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

Запуск

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

Поддержка

  • техническая поддержка системы силами специалистов интегратора.

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

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

Существовало три разных инсталляции системы, каждая со своим приложением и собственной БД:

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

Для регистрации  и планирования выполнения задач  на проекте, а также для оперативной  отчетности по статусам каждой конкретной модификации или заявки пользователя на доработку служила система  отслеживания и контроля запросов, разработанная в Columbus IT. Систему применяли как специалисты интегратора, так и представители ИТ-отдела заказчика.

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

Функциональные  характеристики внедренного решения

В рамках проекта  внедрения были автоматизированы следующие  участки заказчика.

1. Закупки

Операции по регистрации закупок товара от поставщиков.

2.Управление  складом

Учет складских  запасов, перемещение запасов, оперативная отчетность по складским запасам на всех складах компании, ABC и XYZ анализ.

3. Продажи

Уникальные  бизнес-процессы заказчика по продажам товаров клиентам были полностью  отражены в информационной системе.

4. Управление  цепочками поставок

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

5. Расчеты с  поставщиками

Регистрация исходящих  платежей, сопоставление фактур с оплатами.

6. Расчеты с  клиентами

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

7. Финансовая  и управленческая отчетность

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

8. Сводное планирование

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

Технические характеристики внедренного решения

Система построена  в трехуровневой архитектуре  с использованием двух серверов приложений Axapta Object Server, объединенных в кластер, одного сервера терминального доступа, файлового сервера, на котором находится приложение, и сервера баз данных Microsoft SQL Server 2000.

 

Dependency 

  • Основной дескриптор: «Dependency».

 

  • Эквивалентные понятия: «Dependency relationships»

 

  • Использованные стандарты:
  • UML – Unified Modeling Language
  • Рабочие определения:
  • In UML, a dependency relationship is a relationship in which one element, the client, uses or depends on another element, the supplier. [UML – Unified Modeling Language]
  • Dependency: A dependency is a directed relationship used when some element or a set of elements requires (needs) other model elements for specification or implementation. It means that complete semantics of the depending elements is either semantically or structurally dependent on the the supplier element(s). [UML – Unified Modeling Language]

 

  • Обновляемый блок:
  • A dependency in the Unified Modeling Language exists between two defined elements if a change to the definition of one may result in a change to the other. [Wikipedia - http://en.wikipedia.org/wiki/Dependency_(UML)]
  • A dependency is a semantic relationship where a change to the influent or independent modeling element may affect the semantics of the dependent modeling element. [Wikipedia - http://en.wikipedia.org/wiki/Dependency_(UML)]
  • A dependency identifies a set of model elements that requires other model elements for their specification or implementation. The complete semantics of the depending elements is either semantically or structurally dependent upon the definition of the supplier element(s). [Wikipedia - http://en.wikipedia.org/wiki/Dependency_(UML)]
  • Тип связи: предмет - процесс

 

Artifact

  • Основной дескриптор: «Artifact».

 

  • Эквивалентные понятия: «model elements», « model».

 

  • Использованные стандарты:
  • RUP - Rational Unified Process
  • UML – Unified Modeling Language
  • Рабочие определения:
  • Artifacts are either final or intermediate work products that are produced and used during a project. Artifacts are used to capture and convey project information. [RUP - Rational Unified Process]
  • An artifact is a classifier that represents some physical entity, a piece of information that is used or is produced by a software development process, or by deployment and operation of a system. Artifact is a source of a deployment to a node. A particular instance (or "copy") of an artifact is deployed to a node instance.[ UML – Unified Modeling Language]
  • Тип связи: процесс - предмет

 

Deployment target 

  • Основной дескриптор: «Deployment target».
  • Использованные стандарты:
  • UML – Unified Modeling Language

 

  • Рабочие определения:
  • Deployment target is the location for a deployed artifact.[UML – Unified Modeling Language]

 

  • Открытые источники:

Artifacts are deployed to deployment targets. Deployment target is the location for a deployed artifact.

UML 2.4 definition of deployment target

Instance specification was extended in UML 2.0 to allow instance of a node to be deployment target in a deployment relationship.

Property was also extended in UML 2.0 with the capability of being a deployment target in a deployment relationship. This enables modeling the deployment to hierarchical nodes that have properties functioning as internal parts.

Deployment target owns the set of deployments that target it.

Deployment target has no specific notation by itself, see notations for subclasses.

[http://www.uml-diagrams.org/composite-structure-diagrams.html#part]

  • Тип связи: процесс - предмет

Процесс

  • Основной дескриптор: «Процесс».

 

  • Эквивалентные понятия: «Рабочий процесс»

 

  • Использованные стандарты:
  • ГОСТ Р ИСО 9000-2001 - Системы менеджмента качества. ОСНОВНЫЕ ПОЛОЖЕНИЯ И СЛОВАРЬ.
  • RUP - Rational Unified Process
  • Рабочие определения:
  • Процесс – набор частично упорядоченных шагов для достижения цели. В ПО, цель – необходимость построения программного продукта или расширения существующего. В технологии, цель состоит в том, чтобы расширить или увеличить модель процесса; соответствует деловому прецеденту использования в деловой разработке. [RUP]
  • Рабочий процесс – описание осмысленной последовательности задач и их взаимодействия между ролями, создающих видимый результат.[RUP]
  • процесс (process): Совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующая входы в выходы. [ГОСТ Р ИСО 9000-2001]
  • Тип связи: причина - следствие

 

Проект 

  • Основной дескриптор: «проект».

 

  • Использованные стандарты:
  • ГОСТ Р ИСО 9000-2001 - Системы менеджмента качества. ОСНОВНЫЕ ПОЛОЖЕНИЯ И СЛОВАРЬ.
  • Cobit 4.1 Control Objectives for Information and Related Technology (Задачи информационных и смежных технологий) 

 

  • Рабочие определения:
  • Проект (project): Уникальный процесс, состоящий из совокупности скоординированной и управляемой деятельности с начальной и конечной датами, предпринятый для достижения цели, соответствующей конкретным требованиям, включая ограничения сроков, стоимости и ресурсов.[ ГОСТ Р ИСО 9000-2001]
  • Проект (project): Структурированный комплекс видов деятельности, имеющий целью создать для организации новую возможность (что необходимо, но недостаточно для достижения требуемых результатов бизнеса), основанный на согласованном графике и бюджете.[ Cobit 4.1 Control Objectives for Information and Related Technology]

 

  • Открытые источники:
  • Проект - Уникальное предприятие, предполагающее координированное выполнение взаимосвязанных действий из различных функциональных областей, для достижения определенных целей в условиях временных и ресурсных ограничений. [http://www.prjman.ru/theory/19/]

 

 

  • Тип связи: вид - род

 

Поставщик

  • Основной дескриптор: «Поставщик».

 

  • Эквивалентные понятия: «Производитель», «организация».

 

  • Использованные стандарты:
  • ГОСТ Р ИСО/МЭК 12207-99 - ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ
  • ГОСТ Р ИСО/МЭК 15288 — 2005 - СИСТЕМНАЯ ИНЖЕНЕРИЯ

Процессы жизненного цикла систем

 

 

  • Рабочие определения:
  • поставщик (supplier): Организация, которая заключает договор с заказчиком на поставку системы, программного продукта или программной услуги на условиях, оговоренных в договоре. [ГОСТ Р ИСО/МЭК 12207-99]
  • организация (organization): Группа работников и необходимых средств с распределением ответственности, полномочий и взаимоотношений. [ГОСТ Р ИСО/МЭК 15288 — 2005]

Внедрение информационной системы 📙 Контрольная → 🆔 17281

Внедрение информационной системы 📙 Контрольная → 🆔 17281

Внедрение информационной системы