Файл: Стратегическое управление развитием корпоративных информационных систем.pdf

Введение

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

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

Цель работы ˗ разработать и внедрить проект ERP системы.

В достижении поставленной цели были выделены следующие этапы: провести теоретическое исследование аспектов внедрения ERP II-системы управления на предприятие;

− определить понятие и сущность проектного управления; − произвести описание существующих ERP II-систем управления;

− проанализировать текущее состояние предприятия, описать стратегию развития ООО «АЭРОКОМПОЗИТ» и выявить проблемные области, требующие изменений в части информационного обеспечения ООО «АЭРОКОМПОЗИТ»;

− привести общую характеристику предприятия;

− выявить проблемы функций ERP II-систем управления ООО «АЭРОКОМПОЗИТ»;

− разработать проект по повышению конкурентоспособности предприятия на основе внедрения системы управления ERP II-систем;

− привести описание проекта автоматизации функций планирования и контроля проекта внедрения ERP (ERP II) системы.

Объект исследовани - ООО «АЭРОКОМПОЗИТ».

Предмет работы - внедрение ERP II- системы управления на предприятие ООО «АЭРОКОМПОЗИТ».

---

Глава 1. Сущность, значение и особенности корпоративных информационных систем

Структура информационного обеспечения

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

Рис.1. Этапы жизненного цикла проекта автоматизации

Как правило, мы отдаем предпочтение спиральной модели, которая включает в себя гибкие методологии разработки Agile. Тем не менее, иногда мы используем каскадную модель (которая также носит название »Водопад») и ее производные для выполнения небольших или несложных проектов. В данной статье мы дадим описание каскадной модели, которая является классическим типом жизненного цикла программного обеспечения.

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

Давайте поочередно рассмотрим все этапы жизненного цикла:

Анализ требований

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

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

---

Видение проекта

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

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

Сбор требований

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

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

Проектирование программного обеспечения

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

Масштабы и границы проекта

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

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

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

---

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

Спецификация требований программного обеспечения

Спецификация требований программного обеспечения (SRS) описывает требования, которым должно отвечать создаваемое программное обеспечение. Она должна быть логичной, последовательной, доступной и полной. Требования могут выражаться в разных формах, например, в виде традиционных утверждений долженствования (н-р, “Система Staff Manager должна поддерживать следующие браузеры: Google Chrome, Apple Safari, Mozilla Firefox, Opera, IE 8+”) или в виде пользовательских историй (н-р, “поскольку я являюсь менеджером, мне необходим доступ к персональной информации всех сотрудников”).

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

Для создания прототипа вам необходимо выяснить следующее:

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

Мокапы (или прототипы) передаются UI/UX-дизайнерам, которые превращают их в красочные шаблоны.

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

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

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

---

4. Тестирование программного обеспечения

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

Техническая поддержка программного обеспечения

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

Модель жц отражает состояние системы, с момента возникновения необходимости в ИС и заканчивается моментом ее изъятия. Модель жизненного цикла - это структура, которая содержит процессы,

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

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

Предпроектная стадия имеет следующие этапы:

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

---