Анализ, проектирование и разработка корпоративных информационных систем: теория и практика

Подробности

Опубликовано: 16.07.2018 16:45

Автор: Степанов Дмитрий Юрьевич

Просмотров: 17486

Аннотация: рассмотрены теоретические подходы к анализу, проектированию, разработке, тестированию и промышленному использованию корпоративных информационных систем. Выполнен анализ практических методов реализации систем, включающий использование баз знаний для выявления требований; низкоуровневых методов проектирования с графическими элементами ответственности; принципов контроля полномочий, общего решения и контура обратной связи для реализации программных разработок; всевозможных видов тестирования; последовательной и параллельно-последовательной стратегий перехода к промышленной эксплуатации. 
Скачать: PDF (версия 1), PDF (версия 2).
Ключевые слова: практика внедрения ERP систем, практика внедрения информационных систем, опыт внедрения ERP систем, теория и практика ERP, особенности внедрения информационных систем, внедрение КИС на предприятии, особенности использования и внедрения ERP, теория информационных систем, теория информационных процессов и систем, внедрение информационных систем на предприятии, внедрение информационных систем, внедрение корпоративных информационных систем, преимущества внедрения корпоративных информационных систем, особенности внедрения информационных систем управления, проектирование и разработка корпоративных информационных систем, разработка информационных систем.

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

Рис. 1. Общие этапы внедрения корпоративной информационной системы

Цель и задачи

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

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

1. Обзор литературных источников

Обзор литературных источников [2-4], посвященных анализу и проектированию корпоративных информационных систем (далее – КИС), показал, что существует большое число методов проектирования информационных систем, однако область их применения не вполне определена. В результате непонятно, какой из способов целесообразно применять при решении той или иной задачи. Неправильный выбор чреват увеличением трудозатрат, несопоставимых с начальной постановкой задачи.

Монографии по разработке программ [5-7] описывают исключительно подготовку оптимального программного кода. Описание того, какие принципы должны лежать в основе каждой разработки, отсутствуют. В этом случае, если ошибка первоначально допущена на уровне архитектуры программы, качественно написанный код будет также ошибочен.

Маршрутные карты по проекту внедрения КИС, представленные в книгах [8-10], содержат перечень работ, которые должны быть выполнены, однако детали операций не приводятся. Типичный пример – «необходимо выполнить миграцию данных», но как это сделать, каковы предпосылки и сроки? Ответов на данные вопросы нет. Вышесказанное подчеркивает необходимость детального рассмотрения теоретических основ анализа, проектирования и разработки КИС. 

2. Этапы и уровни внедрения

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

Рис. 2. Определение уровней управления для проекта внедрения КИС

Рассмотрим вопрос анализа требований более подробно. Целесообразно начать с обзора процесса внедрения КИС. Типовые этапы имплементации КИС, приведенные в работе [11], включают: подготовку проекта, проектирование, реализацию, подготовку к опытной эксплуатации, непосредственно опытное применение и переход к промышленному использованию (рис.3). Анализ требований и бизнес-процессов заказчика ведется на этапе проектирования, в результате формируется документ, содержащий функционально-технические требования.

Рис. 3. Этапы и уровни внедрения КИС

Уровни имплементации КИС [12] позволяют разграничить выполняемые операции по содержанию работ: подготовка технической инфраструктуры системы, разработка приложений, управление проектом внедрения (рис.3). Статья ограничивается рассмотрением исключительно уровня приложений. 

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

Правильно заданный вопрос уже содержит ответ. Ситуация с анализом требований и бизнес-процессов заказчика аналогична. В статье [13] приводятся сведения о способах выявления информационных потребностей компании: использование знаний, проведение опроса, обзор управленческой документации, анализ документооборота и наблюдение за выполнением операций (рис.4). По большому счету, все способы выявления потребностей компании служат единственной цели – накопление и последующее использование знаний. 

Рис. 4. Способы выявления информационных потребностей и база знаний

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

Примерами решений, выработанных на основе БЗ, служат типовые отраслевые решения и лучшие мировые практики (best practice). На реальных проектах внедрению КИС предшествуют длительные переговоры, в ходе которых заказчик ожидает формулировки требований и решений именно от подрядчика. Другими словами, понимание требований к системе должно возникнуть намного раньше старта проекта, а это возможно лишь с использованием БЗ. 

4. Проектирование процессов

Выявленные информационные потребности подлежат моделированию. Проектирование процессов может вестись в различных графических нотациях [14], сами же бизнес-процессы претерпевают декомпозицию: чем ниже уровень представления, тем детальнее описываются операции (рис.5). Проектирование ведется в двух моделях «как есть» («as is») и «как будет» («to be») [2]. Если модель «как есть» содержит описание текущих процессов, то «как будет» требует проведения реинжиниринга этих процессов на основе BSP, TQM, CMM и других подходов [15]. 

Рис. 5. Методы проектирования процессов

Выбор метода моделирования зависит от задачи проектирования. Так, в большинстве проектов внедрения КИС используются нотации Swim Lane Diagram или ARIS extended Event Process Chain [13]. Выбор не случаен, ведь именно эти методы содержат элементы описания функционала ответственных сотрудников, входных и выходных документов, а также позволяют вести низкоуровневое проектирование (табл.1). Что весьма критично при реализации проекта КИС.

Таблица 1. Элементы описания, особенности и области применения нотаций 

5. Разработка программ

Модель «как будет» определяет окончательный функциональный объем КИС, необходимый для удовлетворения потребностей заказчика [13]. Доработке КИС предшествует формирование технического задания, содержащего описание необходимых изменений системы [11]. Применив основные принципы системного анализа [16], в работах [13, 17] сформулированы принципы разработки программных продуктов (рис.6).

Рассмотрим реальный пример. Применяя трехуровневую структуру описания программ [17], на рис.7а дана схема web-приложения по учету рабочего времени сотрудников. Алгоритм работы приложения следующий:

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

Рис. 6. Принципы разработки программ

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

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

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

Рис. 7. Практический пример схемы программы в моделях: а) «как есть»; б) «как должно быть» 

6. Тестирование разработок

Разработанное приложение подлежит тестированию для выявления и своевременного устранения дефектов. Существуют разнообразные виды тестирования программного обеспечения [18]. Различают функциональное (безопасности, взаимодействия, функций), нефункциональное (производительности, установки, отказа и восстановления) и тестирование, связанное с изменениями (дымовое, регрессионное, сборки).

Рассмотрим практический пример. Была разработка программа в рамках заданного модуля системы (рис.8). Первое, с чего нужно начать, – выполнить модульное тестирование разработки, состоящее в независимой проверке работоспособности программы. Далее проводится интеграционное тестирование, включающее выполнение сквозного бизнес-процесса, затрагивающего программы из различных модулей системы. И системное тестирование, в котором система рассматривается как единое целое, а контролю подлежит интеграция со смежными информационными системами. Модульное, интеграционное и системное тестирование ведется силами технических специалистов вручную, для чего готовятся соответствующие сценарии тестирования.

Рис. 8. Практический пример объема тестирования программы

Далее проводится нагрузочное тестирование, позволяющее оценить работу системы при обработке пикового объема транзакционных данных, и регрессионное, показывающее, не нарушилась ли логика работы смежных систем после разработки новой программы. Нагрузочное и регрессионное тестирование выполняется техническими консультантами с использованием специальных приложений [19].

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

6. Промышленное использование

Успешно протестированные приложения КИС используются в повседневной жизни компании. Промышленная эксплуатация системы следует за фазой перехода. Стратегия перехода [13] определяет, каким образом будут использоваться предыдущие и новые информационные системы. Выделяют два подхода: последовательный и параллельно-последовательный (рис.9) [20].

Рис. 9. Стратегия перехода: а) последовательная; б) параллельно-последовательная

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

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

К предпосылкам параллельно-последовательного подхода относят реализацию проекта внедрения КИС «с нуля», отсутствие опытной эксплуатации и небольшое число исторических систем. Действительно, если предлагаются ранее нигде не реализованные проектные решения, целесообразно подстраховаться, следуя стратегии «наихудшего результата» из теории принятия решений [21]. Дублирование данных в различные информационные системы оправдано, если число подобных систем невелико, а продолжительность двойного ввода ограничена во времени. 

Выводы

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

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

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

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

Литература

1. Wallace T. ERP: Making it happen. – Canada: John Wiley & Sons, 2001. – 375 p.
2. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
3. Белов В.В., Чистякова В.И. Проектирование информационных систем: учебник. – М.: Академия, 2013. – 352 с.
4. Заботина Н.Н. Проектирование информационных систем: учебное пособие. – М.: ИНФРА-М, 2014. – 330 с.
5. Кнут Д.Э. Искусство программирования. Том 1. Основные алгоритмы / Пер. с англ. Тригуб С. и др. – М.: Вильямс, 2015. – 720 с.
6. Кнут Д.Э. Искусство программирования. Том 2. Получисленные алгоритмы / Пер. с англ. Тертышный В. – М.: Вильямс, 2011. – 832 с.
7. Кнут Д.Э. Искусство программирования. Том 3. Сортировка и поиск / Пер. с англ. Тертышный В. и др. – М.: Вильямс, 2012. – 824 с.
8. ANSI/PMI 99-001-2014. A Guide to the Project Management Body of Knowledge (PMBOK Guide). – Pennsylvan.: Project Management Institute, 2013. – 589 p.
9. Brand H. SAP R/3 Implementation With ASAP: The Official SAP Guide. – NJ.: Sybex Inc, 1999. – 591 p.
10. Shankar C., Bellefroid V. Microsoft Dynamics Sure Step 2010. – Birmingham: Packt Publishing, 2011. – 360 p.
11. Степанов Д.Ю. Обзор проектных документов при внедрении корпоративных информационных систем // Вопросы экономических наук. – 2014. – т.70, №6. – c.54-62.
12. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: аннотация / МГТУ МИРЭА. - М., 2015.
13. Степанов Д.Ю. Проблемы внедрения корпоративных информационных систем: уровень приложений // Менеджмент сегодня. – 2015. – т.87, №3. – c.180-191.
14. Ковалев С., Ковалев В. Секреты успешных предприятий: бизнес-процессы и организационная структура. – М.: БИТЕК, 2012. – 498 с.
15. Реинжиниринг бизнес-процессов. Полный курс MBA / Абдикеев Н. и др. – М.: Эксмо, 2006. – 592 с.
16. Антонов А.В. Системный анализ. – М.: Высшая школа, 2008. – 456 с.
17. Степанов Д.Ю. Формирование универсальных требований к пользовательским программам при подготовке спецификации на ABAP-разработку // Актуальные проблемы современной науки. – 2014. – т.78, №4. – c.258-268.
18. Котляров В.П., Коликова Т.В. Основы тестирования программного обеспечения. Учебное пособие. – М.: Бином, 2006. – 285 с.
19. Винниченко И.В. Автоматизация процессов тестирования. – СПб.: Питер, 2005. – 203 с.
20. Platten J. The data migration go-live strategy – what is it and why does it matter? // Data Migration Pro Expert Journal, – 2009, March 26. – URL: http://datamigrationpro.com/data-migration-articles/2009/3/26/the-data-migration-go-live-strategy-what-is-it-and-why-does.html (дата обращения: 01.06.2015).
21. Черноруцкий И. Методы оптимизации и принятия решений. – М.: Лань, 2001. – 384 с.

Выходные данные

Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: теория и практика // Российский технологический журнал. – 2015. – т.8, №3. – c.227-238. – URL: http://stepanovd.com/science/31-article-2015-2-erpthpr.