Реализация

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

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

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

Чаще всего на этапе разработки меняются интерфейсы пользователя. Это обусловлено в том числе и тем, что модули периодически демонстрируются заказчику. Существенно могут меняться и запросы к данным.

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

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

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

Обработка результатов проектирования

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

Желательно, чтобы на этапе проектирования уже была построена матрица «функции-сущности». Это фактически формализованное представление того, что фирма пытается сделать (функции) и какую информацию требуется обработать для достижения результата (сущности). Подобная матрица позволяет проверить следующие моменты:

• имеет ли каждая сущность конструктор - функцию, создающую экземпляры сущности (create);
• есть ли ссылки на данную сущность, то есть используется ли где-либо данная сущность (references);
• имеют ли место изменения данной сущности (update);
• имеет ли каждая сущность деструктор – функцию, которая удаляет экземпляры сущности (delete).

Часто роль деструктора выполняет комплект программ архивирования данных. Нередко в информационных системах информацию просто накапливают. Это допустимо лишь в том случае, если в течение всего периода накопления информации (а фактически в течение всей жизнедеятельности информационной системы) характеристики ее производительности удовлетворяют требованиям заказчика. На практике это чрезвычайно редкое стечение обстоятельств. Связано это в основном с ростом обрабатываемых объемов информации. Следует отметить, что надеяться в этом случае только на мощность СУБД или аппаратного обеспечения нельзя, так как подобные экстенсивные методы повышения производительности дают низкий расчетный прирост скорости. Фактически задача реагирования системы или отдельных ее частей на рост объема обрабатываемых данных является наиболее вероятной задачей тестирования. В таком случае группа тестирования создает модуль генерации (пусть даже абстрактных) данных, выбирается набор запросов, для которых скоростные характеристики критичны, далее производятся замеры и строится зависимость скорости выполнения от объема данных для каждого из запросов. Такое простое действие позволит избежать серьезных ошибок и в проектировании, и в реализации информационной системы.

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

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

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

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

Системные модули

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

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

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

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

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

Средства мониторинга информационной системы

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

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

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

Интерфейсы

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

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

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

При обработке результатов запросов данных следует также особое внимание уделить вопросам соответствия типов включающего языка и СУБД, в том числе вопросам точности числовых типов, так как представление их у разных СУБД существенно различается. Кроме того, обратите внимание на запросы к данным, которые используют функции, зависящие от операционной системы, например функции работы с байтами и словами значения атрибута (например, на Intel и SUN SPARC эти функции будут работать по-разному). Типы данных могут быть приведены или явно в запросе функциями приведения cast и встроенными в СУБД функциями, или в функции прикладной программы. Не для всех СУБД неявное преобразование типов дает один и тот же результат, поэтому если информационая система использует данные из нескольких баз данных под управлением разных СУБД, то неявных преобразований типов лучше избегать.

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

Версии базы данных

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

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

• проконтролировать, какие объекты данных и данные имеют место в объектах загрузки A и B, и загрузить в базу данных только «разницу» A и B (произвести обновление версии);
• проконтролировать, не конфликтуют ли изменения, имеющие место в объектах выгрузки C и D, по сравнению с объектом выгрузки A (произвести слияние версий).

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

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

Размещение логики обработки

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

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

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

Шаблоны

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

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

Тестирование

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

Чем сложнее проект, тем больше будет потребность в автоматизации системы хранения ошибок - bug tracking. Подобная система обеспечивает следующие функции:

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

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

Собственно тесты систем можно разделить на несколько категорий:

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

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

• отказ отдельного компонента информационной системы;
• отказ группы компонентов информационной системы;
• отказ основных модулей информационной системы;
• отказ операционной системы;
• «жесткий» сбой (отказ питания, жестких дисков).

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

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

Эксплуатация и сопровождение

пытная эксплуатация перекрывает процесс тестирования. Как правило, система вводится в эксплуатацию не полностью, постепенно.

Ввод в эксплуатацию проходит по крайней мере три фазы:

накопление информации;

выход на проектную мощность.

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

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

В период накопления информации можно столкнуться со знаменитым «упала база». При самом плохом раскладе окажется, что СУБД не выдерживает потока информации. При хорошем - просто параметры конфигурации неверны. Первый случай опасен, так как повлиять на производителя СУБД довольно сложно, а заказчик очень не любит ссылок на службу технической поддержки СУБД. Решать проблему отказа СУБД придется не производителю, а вам - менять схему, снижать поток запросов, менять сами запросы; в общем - вариантов много. Хорошо, если время восстановления базы вписывается в запланированное.

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

Другие подходы к разработке приложений

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

• Все внимание сконцентрировано на экранных формах, а то, что касается правил обработки данных и системных функций, остается за кадром. Есть соблазн начать работу с отчетов, в то время как отчет является не стартовым, а производным продуктом информационной системы.
• Пользователи полагают, что если вариант прототипа согласован, то модуль готов. На самом деле это может быть всего лишь картинка с набором «заглушек» для вызовов системных функций и взаимодействия с другими модулями.
• Модули проектируются изолированно друг от друга (наверное, большинство из вас сталкивались с бухгалтерскими программами, где каждый АРМ является автономным и функции часто дублируются). Следствием этого являются противоречия модулей, дублирование функций и данных, что может быть выявлено только при тестировании комплекса модулей.
• Функциональные возможности наращиваются параллельно в нескольких направлениях, значит, структура базы данных должна контролироваться жестко. При УРП схема базы данных превращается в свалку, где таблицы «лепятся» наскоро, в результате чего имеет место набор противоречивых и дублирующихся данных.
• Документация при использовании метода УРП, как правило, отсутствует, а вернее, о необходимости документировать систему забывают, поскольку создается иллюзия, что пользователь и без того понимает, что происходит. Когда же приложение начинает работать не так, как предполагает пользователь, возникает масса проблем.
• Обработка исключительных ситуаций для каждого модуля производится своя.
• Целостная система, как правило, не получается, скорее всего, это будет некий набор автоматизированных рабочих мест, наскоро связанных между собой.

Методы УРП и СРП можно использовать далеко не всегда, а лишь в том случае, если:

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

Тем не менее методом УРП лучше разрабатывать небольшие и, желательно, автономные части проекта.

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

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

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

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

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

Метафора (metaphor). Общий вид системы определяется при помощи метафоры или набора метафор, над которыми совместно работают заказчик и программисты.

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

Простой проект (simple design). В каждый момент времени разрабатываемая система выполняет все тесты и поддерживает все взаимосвязи, определяемые программистом, не имеет дубликатов кода и содержит минимально возможное количество классов и методов. Это правило кратко можно выразить так: «Каждую мысль формулируй один и только один раз».

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

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

При написании тестов самими программистами (особенно в условиях сверхурочных работ) эти тесты не полнофункциональны, и уж тем более не учитывают особенностей многопользовательской работы. На более продвинутые тесты у разработчиков обычно не хватает времени. Можно, конечно, построить систему разработки так, что всем будут заниматься одни и те же люди, но все-таки не стоит превращать проект в аналог телепередачи «Сам себе режиссер». К сказанному необходимо добавить, что тестирование системы вовсе не исчерпывается тестами компонентов (units); не менее важны тесты взаимодействия между ними, это же относится и к тестам надежности работы. И тем не менее метод экстремального программирования не предусматривает создания тестов данного класса. Это объясняется тем, что сами такие тесты могут представлять достаточно сложный код (особенно это касается тестов-имитаторов реальной работы системы). В данной технологии также никак не учитывается еще один важный класс тестов - тесты поведения системы при росте объемов обрабатываемой информации. При высокой скорости изменения версий выполнить такой тест технологически невозможно, поскольку его проведение требует стабильного и неизменного кода проекта, например, в течение недели. Подобные сроки, вообще говоря, не гарантируются из-за частой смены версий. В таком случае придется или приостанавливать разработку компонентов, или на время проведения теста создавать параллельную версию проекта, которая будет сохраняться неизменной, тогда как вторая при этом будет изменяться. Потом нужно будет выполнять процесс слияния кода. Но в этом случае тест придется создавать снова, так как методы экстремального программирования просто не предусматривают разработку средств, позволяющих прогнозировать поведение системы при тех или иных изменениях.

Переработка системы (refactoring). Архитектура системы постоянно эволюционирует. Текущий проект трансформируется, при этом гарантируется правильное выполнение всех тестов.

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

Программирование в паре (pair programming). Весь код проекта пишут два человека, которые используют одну настольную систему.

Возникает вопрос: кто-нибудь видел двух совершенно одинаковых программистов, каждый из которых к тому же в конце рабочего дня успевал бы писать документацию для напарника? Можно ли найти таких программистов-близнецов, согласных во всем?

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

Непрерывная интеграция (continuous integration). Новый код интегрируется в существующую систему не позднее, чем через несколько часов. После этого система вновь собирается в единое целое и прогоняются все тесты. Если хотя бы один из них не выполняется корректно, внесенные изменения отменяются.

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

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

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

Заказчик с постоянным участием (on-site customer). Заказчик, который в период работы над системой находится в команде разработчиков.

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

40-часовая неделя (40-hour weeks). Объем сверхурочных работ не может превышать по длительности одну рабочую неделю. Даже отдельные случаи сверхурочных работ, повторяющиеся слишком часто, являются сигналом серьезных проблем, которые требуют безотлагательного решения.

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

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

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

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

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

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

КомпьютерПресс 2"2002

Обычно выделяют следующие этапы создания ИС:

1. формирование требований к системе,

2. проектирование,

3. реализация,

4. тестирование,

5. ввод в действие,

6. эксплуатация и сопровождение.

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

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

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

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

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

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

Этап тестирования обычно оказывается распределенным во времени.

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

2. Понятие «архитектура информационной системы»

Рассмотрим определение "архитектуры информационной системы", которое дают различные источники:

Архитектура – это организационная структура системы.

АрхитектураИС – концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы.

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

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

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

Если все эти определения объединить, то получим следующее:

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

Под архитектурой программных систем будем понимать совокупность решений относительно:

· организации программной системы;

· выбора структурных элементов, составляющих систему и их интерфейсов;

· поведения этих элементов во взаимодействии с другими элементами;

· объединение этих элементов в подсистемы;

· архитектурного стиля, определяющего логическую и физическую организацию системы: статические и динамические элементы, их интерфейсы и способы их объединения.

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

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

Наглядное представление этапов внедрения.

Более подробная схема см. приложение №2.

Этап 1: диагностика

Эта стадия начинается с предварительной деятельности, главная цель который -- создать команду для выполнения диагностики. Как только команда собрана и проинструктирована, высокоуровневый анализ бизнес требований станет своей первой задачей.

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

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

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

Заключительный набор задач состоит в планировании проекта - определение ресурсов, время и бюджет для развертывания решения.

В данном этапе требуется оценить бизнес-требования, объем и рамки проекта, а также план проекта, и по этим данным определить, что лучше использовать - быстрое или полное внедрение Microsoft Dynamics.

Основные результаты стадии:

• * Предложение относительно работы над проектом:
• * описание содержания проекта;
• * предварительный план проекта.
• * Оценка инфраструктуры.

Результаты стадии:

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

Этап 2: анализ.

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

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

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

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

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

Основные результаты этапа:

• * Устав проекта.
• * Тренинги ключевых пользователей.
• * Детальный анализ бизнес-процессов:
  • o анализ разрывов требований с базовой функциональностью;
  • o оценка устранения разрывов;
  • o описание интерфейсов.
• * План миграции данных.
• * План проекта.
• * Функциональные требования:
  • o инфраструктура, функциональность и безопасность;
  • o интеграция.
• * Требования к контролю качества и тестированию.

Основные вехи этапа:

• * Проведено совещание по запуску проекта.
• * Заказчик утверждает Устав проекта.
• * Проводится обучение по проектируемой ИС для ключевых пользователей.
• * Заказчик утверждает «Функциональные требования», включая описания бизнес-процессов, интеграции и миграции данных.
• * Заказчик утверждает обновленный план-график проекта.

Этап 3: дизайн.

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

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

Основные результаты стадии:

• * Спецификация дизайна решения:
• * функциональный дизайн;
• * техническая характеристика.
• * Дизайн интеграции с внешними системами.
• * Дизайн миграции данных и определение соблюдения структур данных.
• * План и сценарии тестирования.

Главные этапы стадии:

• * Клиент одобряет спецификацию дизайна решения, дизайна интеграции с внешними системами и дизайна миграции данных.
• * Клиент одобряет время развития и оценку расходов.

Этап 4: разработка.

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

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

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

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

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

Основные результаты стадии:

• * Настройка решения проектируемой ИС.
• * Подготовка документации относительно решения проектируемой ИС
• * Развитие дополнительной функциональности (настройки).
• * Контроль и тестирование миграции данных.
• * Тестирование интеграции (включая интеграцию с внешними системами).

Главные этапы стадии:

• * Миграция данных выполнена.
• * Тестирование интеграции выполнено.
• * Клиент принимает созданное решение, результаты тестирования и документации.

Этап 5: развертывание.

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

Основные результаты стадии:

• * План начала и контрольный список.
• * План тестирования системы.
• * План обучения пользователей.
• * Обучение пользователей.
• * Рабочая система.

Главные этапы стадии:

• * План старта и контрольный список.
• * План тестирования системы.

Этап 6: эксплуатация.

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

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

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

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

По этому вопросу взаимодействие с клиентом проводится в пределах ранее скоординированной поддержки продукта (с подписанием соответствующего контракта). Команда консультанта переключается на следующий проект.

Основные результаты стадии:

• * Принятие системы клиентом.
• * Документы для закрытия проекта.
• * Соглашение по поддержке системы.

Главные этапы стадии:

• * Клиент признает, что спроектированный ЯВЛЯЕТСЯ и подписывает акт входа в коммерческой операции.
• * Клиент формально закрывает проект.
• * Клиент подписывает контракт поддержки.

Модель методологии проектируемой ИС также определяет две дополнительные стадии, которые можно реализовать после запуска решения

Проектируемая ИС в рабочей среде клиента:

Цель стадии оптимизации: создание структуры управления процессами, происходящими после процедуры Go-Live. Эта стадия также позволяет поддерживать отношения с клиентом после оригинального проекта введения или может стать первым шагом на способе предоставить услуги новому клиенту.

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

Стадия оптимизации - отражение процесса полного внедрения. Эта стадия включает перечисленные ниже действия:

• * Аналитические действия, направленные на сбор информации о процессе, контроле и производительности.
• * Предложения относительно объема работ.
• * Работа над выполнением и расширением оптимизации.

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

• * анализ;
• * планирование;
• * определение оптимизации;
• * расширение оптимизации;
• * эксплуатационные операции.

Обновление.

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

Потребность полного внедрения, вызванного сложностью обновления, определённого во время анализа. Это начинается со стадии диагностики.

В рамках обновления следующие действия могут быть выполнены:

• * анализ;
• * планирование;
• * обновление работы;
• * тестирование;

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

Каждая стадия методологии Sure Step Methodology включает ряд определенных операций и задач. Результат выполненной работы в рамках операции, как правило, отражен в конечных результатах с рекомендациями и инструкциями о дальнейших шагах процесса внедрения.

ТАВРИЧЕСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ

им. В.И. ВЕРНАДСКОГО

Экономический факультет

кафедра экономической кибернетики

дневное отделение

МАЛЫШЕВ СЕРГЕЙ ИВАНОВИЧ

ВНЕДРЕНИЕ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ (СИСТЕМ) В ДЕЯТЕЛЬНОСТЬ ПРЕДПРИЯТИЯ

Курсовая работа

Студент 2 курса, гр. 201К ______________ Малышев С.И.

Научный руководитель,

доцент, к.ф.-м.н. ______________ Круликовский А.П.

Симферополь, 2009

ВВЕДЕНИЕ ……………………………………………………………………….3

ГЛАВА 1

ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В ЭКОНОМИКЕ ………………………………………………………………...6

1.1. История развития информационных систем………………………….....6

1.2. Классификация информационных технологий и систем…………….....8

1.3. Виды информационных систем в организации………………………...16

1.4. Потенциальные потребители информационных технологий…………19

1.5. Опыт использования информационных систем ……………………….21

ГЛАВА 2

ВЫБОР, ВНЕДРЕНИЕ И ЭКСПЛУАТАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ …………………………………………………………………...22

2.1. Проблема выбора информационной системы………………………….22

2.2. Критерии выбора системы……………………………………………....24

2.3. Методы внедрения системы……………………………………………..27

2.4. Этапы внедрения информационной системы………………………….30

ЗАКЛЮЧЕНИЕ………………………………………………………………………….…32

СПИСОК ИСТОЧНИКОВ……………………………………………………………...35

Введение

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

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

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

Существует множество определений данному термину, например:

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

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

Для новой информационной технологии характерны:

Работа пользователя в режиме манипулирования;

Сквозная информационная поддержка на всех этапах прохождения информации на основе интегрированных баз данных, предусматривающих единую унифицированную форму представления, хранения, поиска, отображения, восстановления и защиты данных;

Безбумажный процесс обработки документов;

Интерактивный режим решения задач;

Возможности коллективного исполнения документов на основе сетевой технологии клиент - сервер, объединенных средствами коммуникации;

Возможности, адаптивной перестройки форм и способа представления информации в процессе решения задачи.

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

Что может дать внедрение информационной системы?

Снижение общих затрат предприятия в цепи поставок (при закупках),

Повышение скорости товарооборота,

Сокращение излишков товарных запасов до минимума,

Увеличение и усложнение ассортимента продукции,

Улучшение качества продукции,

Выполнение заказов в срок и повышение общего качества обслуживания заказчиков.

Реформа методов управления экономическими объектами повлекла за собой не только перестройку организации процесса автоматизации управленческой деятельности, но и распространение новых форм реализации этой деятельности. Цель данной работы исследовать – методы внедрения новой информационной системы, рассмотреть результаты ее использования.

1.1. История развития информационных систем

История развития информационных систем и цели их использования на разных периодах представлены в таблице 1.

Таблица 1. Изменение подхода к использованию информационных систем

Период времени	Концепция использования информации	Вид информационных систем	Цель использования
1980 -???? гг.	Бумажный поток расчетных документов Основная помощь в подго­товке отчетов Управленческий контроль реализации (продаж) Информация - стратегичес­кий ресурс, обеспечиваю­щий конкурентное преиму­щество	Информационные системы обработки расчетных доку­ментов на электромехани­ческих бухгалтерских маши­нах Управленческие информа­ционные системы для про­изводственной информации Системы поддержки приня­тия решений Системы для высшего звена Управления Стратегические информаци­онные системы. Автоматизированные офисы	Повышение скорости обра­ботки документов Упрощение процедуры об­работки счетов и расчета зарплаты Ускорение процесса подго­товки отчетности Выработка наиболее рацио­нального решения Выживание и процветание фирмы

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

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

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

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

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

Таблица 2. Классификация информационных технологий.

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ	По способу реализации в ИС	Традиционные
		Новые информационные технологии
	По степени охвата задач управления	Электронная обработка данных
		Автоматизация функций управления
		Поддержка принятия решений
		Электронный офис
		Экспертная поддержка
	По классу реализуемых технологических операций	Работа с текстовым редактором
		Работа с табличным процессором
		Работа с СУБД
		Работа с графическими объектами
		Мультимедийные системы
		Гипертекстовые системы
	По типу пользовательского интерфейса	Пакетные
		Диалоговые
	По способу построения сети	Локальные
		Многоуровневые
		Распределенные
	По обслуживаемым предметным областям	Бухгалтерский учет
		Банковская деятельность
		Налоговая деятельность
		Страховая деятельность

Рассмотрим, связь между информационными системами и информационными технологиями.

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

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

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

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

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

Все виды информации, необходимой для управления на предприятии, представляют собой информационную систему. Система управления и система информации на любом уровне управления образует единство. Управление без информации невозможно.

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

Ввод информации из внешних или внутренних источников;

Обработка входной информации и представление ее в удобном виде;

Вывод информации для представления потребителям или передачи в другую систему;

Обратная связь - это информация, переработанная людьми данной организации для коррекции входной информации.

Рис. 1. Процессы в информационной системе

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

Информационная система определяется следующими свойствами:

Любая информационная система может быть подвергнута анализу, построена и управ­ляема на основе общих принципов построения систем;

Информационная система является динамичной и развивающейся;

При построении информационной системы необходимо использовать системный под­ход;

Выходной продукцией информационной системы является информация, на основе ко­торой принимаются решения;

Информационную систему следует воспринимать как человеко-компьютерную систе­му обработки информации.

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

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

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

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

При классификации информационных систем удобно выделять системы CRM (работа с клиентами), ERP (управление предприятием) и MPC (управление на основе финансовых показателей).

На отечественном рынке границы подобной классификации сильно размыты, например известная финансовая система 1C позиционируется как ERP, при этом было бы не корректно заявлять, что 1C является конкурентом такой ERP системы как Navision Axaptra.

Первые системы, которые были разработаны для решения задач управления на предприятии, в основном охватывали сферу складского или материального учета (IC – Inventory Control). Их появление связано с тем, что учет материалов (сырья, готовой продукции, товаров) с одной стороны является извечным источником различных проблем для руководителя предприятия, а с другой (на предприятии относительно крупного размера) одной из самых трудоемких областей, требующих к себе постоянного внимания. Основной «деятельностью» такой системы является учет материалов.

Следующий этап усовершенствования материального учета был ознаменован системами планирования производственных или материальных (в зависимости от направления деятельности организации) ресурсов. Эти системы, вошедшие в стандарт, а вернее два стандарта (MRP – Material Requirements Planning и MRP II – Manufacturing Requirements Planning), очень широко распространены на Западе и давно и успешно используются предприятиями, в первую очередь производственных отраслей. Основные принципы, которые легли в основу систем стандарта MRP, включают

Описание производственной деятельности как потока взаимосвязанных заказов;

Учет ограничения ресурсов при выполнении заказов;

Минимизацию производственных циклов и запасов;

Формирование заказов снабжения и производства на основе заказов реализации и производственных графиков.

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

Наиболее популярным на данный момент новым видом информацион-ных систем являются системы стандарта ERP - Enterprise Resource Planning. ERP- системы в своей функциональности охватывают не только складской учет и управление материалами, что в полном объеме предоставляют вышеописанные системы, но добавляют к этому все остальные ресурсы предприятия, прежде всего денежные. То есть ERP-системы должны охватывать все сферы предприятия, непосредственно связанные с его деятельностью. В первую очередь, здесь имеются в виду производственные предприятия. Системы данного стандарта поддерживают осуществление основных как финансовых, так и управленческих функций. Например, в системах Baan – это:

Финансы и бухгалтерия,

Производство,

Сбыт (включая складской учет, торговлю и маркетинг),

Транспорт,

Сервис и обслуживание оборудования,

Управление проектами,

А также единая управленческая панель – модуль Информационная Система Руководителя, на которой руководитель может видеть все основные подразделения и производственные показатели.

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

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

Несмотря на это, надлежит выделить несколько основных требований к системе, общих для всех «потребителей»:

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

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

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

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

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

Эти требования являются основными, но далеко не единственными критериями выбора корпоративной информационной системы для предприятия.

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

Таблица 3. Типы информационных систем.

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

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

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

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

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

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

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

1.4 . Потенциальные потребители информационных технологий

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

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

· внедрена интегрированная информационная система, разработанная «под заказ» и включающая в себя компоненты из перечисленного списка возможных модулей, но не соответствующая современному уровню и требованиям постоянно появляющихся новых стандартов;

· практически не используются информационные технологии (за исключением бухгалтерии) в управлении процессами и ресурсами;

· предпринята попытка внедрить промышленную систему, характеристики которой соответствуют требованиям одного из принятых стандартов (MRP, MRPII, ERP и т.д.), но результат внедрения - неудовлетворительный.

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

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

Менеджеры, у которых уже работают какие-либо информационные системы, стоят перед дилеммой: либо потратить немалую сумму на «интегрированное решение», эффект от которого далеко не очевиден, и при этом выбросить на свалку «старые добрые» программы, которые не соответствуют современному уровню реализации, но проверены временем и «работают»; либо оставить все как есть и забыть про современные концепции ERP, e-business и прочие достижения в области менеджмента и соответственно потерять определенные конкурентные преимущества.

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

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

1 .5. Опыт использования информационных систем

Многие крупные компании США и Европы уже несколько лет назад перешли на использование информационных систем стандарта ERP. Про страны Азии такого сказать пока нельзя. Большинство финансовых менеджеров азиатских компаний едва ли слышали о таких системах, не говоря уж об их внедрении.

Хотя есть компании, которые решились перейти на ERP-системы.

Разработчики информационных систем, в частности SAP, Baan, Oracle, PeopleSoft и J.D.Edwards, довольно агрессивно рекламируют свои продукты, что создает впечатление у плохо осведомленных в данной области людей впечатление, что эти программы способны решить все проблемы их компаний.

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

Например, руководство компании FoxMeyer утверждает, что ошибочное внедрение ERP-системы привело ее к банкротству. Компания обвиняет в этом создателей системы и консультантов. Такая же участь постигла и компании Dell Computer, Dow Chemical и Kellogg’s.

Но существуют также примеры успешного использования ERP-систем. Так, например, телекоммуникационная компания Aliant заявляет, что проект по внедрению системы ERP был очень удачным. Ожидаемая норма возврата на инвестиции в данный проект составила 33%.

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

Глава 2.Выбор, внедрение и эксплуатация информационной системы

2.1. Проблема выбора информационной системы

Требования к информационной системе.

Информационная система управления для промышленного предприятия не должна замыкаться только в рамках управления бизнес-процессами. Данная система должна объединить в себе все три уровня управления процессами происходящими на предприятии:

· управление бизнес процессами

· управление проектно-конструкторскими разработками

· управление технологическим процессом производства.

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

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

“Становым хребтом” единой информационной системы управления предприятием является система управления бизнес процессами предприятия - система класса ERP (Enterprise Resources Planning - Планирование ресурсов предприятия). Необходимым элементом являются системы автоматизации проектно конструкторской деятельности и технологической подготовки производства (САПР/АСТПП - CAD/CAM/CAE/PDM), обеспечивающие снижение времени производственного цикла и повышения качества продукции. Третий элемент - системы управления технологическим процессом производства. Связующее программное обеспечение обеспечивает взаимодействие всех ранее описанных решений в рамках единой информационно - аналитической системы управления предприятием.

Проблемы выбора.

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

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

По моему мнению, крупным предприятиям следует ориентироваться на западные системы. И следующий вопрос, на который необходимо дать ответ - какую западную систему выбрать?

Для украинского пользователя выбор таких систем ограничен. Не так уж много западных фирм вышли на постсоветский рынок. Реально это SAP, Computer Associates, BAAN и ISF. Попытки выйти делали ORACLE, JDEdvards, SSA, JBA и QAD. Причем реальные внедрения имеются только у продуктов SAP и Computer Associates. Кроме того, различные системы предназначены для разных предприятий. Одни, такие как SAP или CA-Masterpiece, ориентированны на корпоративный рынок, другие, как BAAN или MK Enterprise (ранее MANMAN/X) на рынок промышленных предприятий или компаний. И предприятию нужно сделать правильный выбор, чтобы в результате ошибки не оказаться обладателем системы не подходящей для него.

2.2. Критерии выбора системы

Функциональные возможности.

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

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

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

Совокупная стоимость владения.

Совокупная стоимость владения – сравнительно новое понятие. Под ним понимается сумма прямых и косвенных затрат, которые несет владелец системы за период ее жизненного цикла.

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

Перспективы развития.

Перспективы развития закладываются в систему поставщиком системы и комплексом стандартов, которым она удовлетворяет.

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

Технические характеристики.

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

Архитектуру системы,

Надежность,

Масштабируемость,

Способность к восстановлению,

Наличие средств резервного копирования,

Средства защиты от технических нападений,

Возможность интеграции с другими системами.

Минимизация рисков.

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

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

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

· процесс создания системы

· оборудование

· программное обеспечение

· персонал

· управление задачами

Для каждого объекта затрат выдвигается целый ряд характеристик, которому он должен удовлетворять с целью снижения рисков.

2.3. Методы внедрения системы

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

Необходимо:

1. Добиться веры в успех и преданности делу со стороны тех, кто играет ключевую роль в реализации проекта.

2. Определить, кто будет штатным руководителем проекта по внедрению системы. Этот человек должен обладать необходимыми навыками для выполнения такой работы, желательно, чтобы он имел опыт внедрения систем.

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

4. Убедиться, что люди, выполняющие эти функции, обладают необходимыми навыками.

5. Разработать подробный план работы, разбить его на этапы, определите сроки выполнения задач и придерживаться их.

Прежде чем приступить к внедрению системы, необходимо продумать организационную структуру и бизнес-процессы:

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

2. Описать методы ведения хозяйственной деятельности и действия, которые должны быть выполнены в результате их применения.

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

4. Описать организационную структуру и подумать о том, в максимальной ли степени она отвечает целям предприятия.

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

Обеспечить создание необходимой технической инфраструктуры:

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

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

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

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

Управлять изменениями, подстраиваясь под сотрудников.

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

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

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

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

После проведенных мероприятий можно приступать непосредственно к внедрению системы.

2.4. Этапы внедрения информационной системы

Следует выделить три этапа внедрения информационной системы:

1. Исследование. Компания-внедренец проводит исследование бизнес процессов вашей компании.

2. Доработка системы. Программисты компании-внедренца настраивают или дорабатывают требуемую функциональность системы.

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

Исследование бизнес процессов.

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

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

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

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

Доработка системы.

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

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

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

Запуск системы.

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

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

Развитие информационной системы.

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

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

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

З аключение

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

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

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

Обеспечить надежный учет и контроль поступлений и расходования денежных средств на всех уровнях управления.

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

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

Гарантировать полную безопасность и целостность данных на всех этапах обработки информации.

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

Итак, для успешного внедрения системы управления предприятием необходимо:

При выборе системы основываться не на ее присутствии на рынке, а на том, насколько она подходит для удовлетворения потребностей бизнеса компании;

Приступить к внедрению, имея сильного руководителя проекта и план проекта, который был тщательно продуман;

Пересмотреть методы ведения хозяйственной деятельности компании до выбора системы;

Регулярно общаться с сотрудниками, стремясь привлечь их к участию во внедрении системы и дать им возможность убедиться в том, что их потребности учтены;

Следить за ходом выполнения проекта, сверяясь с намеченными основными этапами и сроками выполнения задач;

Установить реальные сроки и составить незаниженный бюджет;

Привести в соответствие с новыми требованиями уровень подготовки сотрудников отдела информационных систем;

Поручить осуществление проекта кому-либо из тех, кто знает деятельность вашей компании изнутри.

Типовой план внедрения был разработан в компании Oliver Wight, но опыт показывает, что в той или иной степени практически все фирмы следуют этой стратегии.

Данный план состоит из следующих этапов:

1. Предварительное обследование и оценка состояния компании;

2. Предварительная переподготовка;

3. Техническое задание (анализ проблемы построения системы);

4. Технико-экономическое обоснование (анализ «затраты-эффект»);

5. Организация проекта (назначение ответственных лиц, состав комитетов);

6. Выработка целей (что мы ожидаем от проекта);

7. Техническое задание на управление процессами;

8. Начальная переподготовка (переподготовка сотрудников);

9. Планирование и управление верхнего уровня;

10. Управление данными;

11. Одновременное внедрение различных технологий организации и управления;

12. Программное обеспечение;

13. Опытный пример;

14. Получение результатов;

15. Анализ текущего состояния;

16. Постоянная переподготовка.

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

Список источников:

1. Барановская Т. П. и др. Информационные системы и технологии в экономике Издательство: Финансы и статистика, 416 стр., 2003 г.

2. Баронов В.П., Титовский И.Л., статья «Методы построения систем управления»

3. Божко В. П. Информационные технологии в статистике Издательства: Финстатинформ, КноРус, 144 стр., 2002 г.

4. Веревченко А. П., и др. Информационные ресурсы для принятия решений Издательства: Деловая Книга, Академический проект; 560 стр., 2002г.

5. Волокитин А. В., и др. Средства информатизации государственных организаций и коммерческих фирм. Справочное пособие Издательство: ФИОРД-ИНФО 272 стр., 2002 г.

6. Гаскаров Д. В. Интеллектуальные информационные системы Издательство: Высшая школа, 432 стр., 2003 г.

7. Герасимова Л.Н. Информационное обеспечение маркетинга Издательство: Маркетинг, 120 стр., 2004 г.

8. Годин В. В., Корнеев И. К. Информационное обеспечение управленческой деятельности Издательства: Высшая школа, Мастерство; 240 стр., 2001 г.

9. Гринберг А. С., Король И. А. Информационный менеджмент Издательство: Юнити-Дана; 416 стр., 2003 г.

10. Гринберг А. С., Шестаков В. М. Информационные технологии моделирования процессов управления экономикой Издательство: Юнити-Дана; 400 стр., 2003 г.

11. Душин В. К. Теоретические основы информационных процессов и систем Издательство: Дашков и Ко, 250 стр., 2002 г.

12. Калянов Г. Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе Издательство: Горячая Линия – Телеком 208 стр., 2004 г.

13. Карабутов Н. Н. Информационные технологии в экономике Издательство: Экономика; 208 стр., 2003 г.

14. Когаловский М. Р. Перспективные технологии информационных систем Издательства: ДМК Пресс, Компания АйТи; 288 стр., 2003 г.

15. Колесников С.И., статья «Об оценке эффективности внедрения и применения ERP систем»

16. Липаев В. В. Системное проектирование сложных программных средств для информационных систем Издательство: Синтег; 268 стр., 2002 г.

17. Майкл Дж. Д. Саттон Корпоративный документооборот. Принципы, технологии, методология внедрения

18. Издательства: Микро, Азбука, 446 стр., 2002 г.

19. Маклаков С. В. Моделирование бизнес-процессов Издательство: Диалог – МИФИ, 240 стр., 2003 г.

20. Меняев М. Ф. Информационные технологии управления. Книга 3. Системы управления организацией, 464 стр., 2003 г.

21. Патрушина С. М. Информационные системы в экономике. Издательство: Бизнес, 352 стр., 2004 г.

22. Прокушева А. П., Липатникова Т. Ф., Колесникова Н. А. Информационные технологии в коммерческой деятельности Издательство: Маркетинг, 192 стр., 2001 г.

23. Родионов И. И., и др. Рынок информационных услуг и продуктов Издательство: МК-Периодика 552 стр., 2002 г.

24. Сар Эрмако Джонии, статья «Быть или не быть ERP?»

25. Синюк В.Г., Шевырев А.В. Использование информационно-аналитических технологий при принятии управленческих решений Издательство: ДМК Пресс; 160 стр., 2003 г.

26. Скрипкин К. Г. Экономическая эффективность информационных систем Издательство: ДМК Пресс; 256 стр., 2002 г.

27. Стрелец И. А. Новая экономика и информационные технологии Издательство: Экзамен, 256 стр., 2003 г.

28. Уткин В. Б., Балдин К. В. Информационные системы в экономике Издательство: Финансы и статистика, 288 стр., 2004 г.

29. Хорошилов А. В., С. Н. Селетков Мировые информационные ресурсы Издательство: Питер; 176 стр., 2004 г.

30. Шафрин Информационные технологии. Часть 2 Издательство: Бином. Лаборатория знаний; 320 стр., 2002 г.

31. Эриксен Т. Х. Тирания момента. Время в эпоху информации Издательство: Весь Мир, 208 стр., 2003 г.

Использованы материалы с сайтов:

32. www.altrc.ru

33. www.bankreferatov.ru

34. www.economics.ru

35. www.erp-people.com

39. www.parus.ru

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

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

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

Программа реализуется с 2012 года.

За это время прошли обучение несколько сотен человек из Владивостока, Екатеринбурга, Тулы, Самары, Воронежа, Сочи, Новгорода, Читы, Москвы и других городов.

Программа разработана с учетом требований профессиональных стандартов:

• Руководитель проектов в области информационных технологий (Утвержден Приказом Минтруда России №893н от 18.11.2014)
• Системный аналитик (Утвержден Приказом Минтруда России № 809н от 28.10.2014)

Форма обучения:	заочная (дистанционная)
Срок обучения по программе:	8 месяцев
Выдаваемый документ:	диплом установленного образца Высшей школы экономики о профессиональной переподготовке. Диплом дает право на ведение профессиональной деятельности в сфере управления информационными технологиями
Начало занятий:	05 июня 2019 года Прием документов до 25 мая 2019 года
Условия поступления:	Лица, имеющие среднее профессиональное или высшее образование; - лица, получающие профильное (техническое, экономическое, управленческое) высшее образование.
Стоимость	136 000 рублей. Оплата производится частями. Минимальный платеж - 1 раз за 2 месяца.

Подайте заявку на обучение

ЦЕЛИ ПРОГРАММЫ

• Дать слушателям необходимые теоретические знания в области системного анализа и ИТ-менеджмента;

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

Изучить практику управления ИТ-проектами в российских компаниях и организациях;

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

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

Структура и содержание программы

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

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

Программа разработана ведущими преподавателями НИУ ВШЭ и практиками-экспертами, имеющими большой опыт практической работы и обучения взрослых людей.

Для задания необходимой логики изучения, а также приобретения практических навыков, программа разбита на четыре блока с соответствующими контрольными практическими заданиями (КДЗ):

1. Анализ предметной области и формирование требований к ИС

• Информатизация предприятия
• Анализ требований к автоматизированным информационным системам
• Архитектура предприятия
• Моделирование бизнес-процессов
• Оптимизация бизнес-процессов
• Контрольное домашнее задание 1.

2. Разработка и проектирование ИС

• Модели жизненного цикла и методологии разработки корпоративных систем
• Технологии и средства разработки корпоративных систем
• Проектирование информационных систем
• Применение ГОСТ 34 в проектах создания современных автоматизированных систем
• Основы проектирования реляционных баз данных
• SQL и процедурно-ориентированные языки
• Контрольное домашнее задание 2

3. Внедрение ИС

• ИТ-стратегия
• Управление внедрением информационных систем
• Гибкая процессная методология Agile
• Управление проектами в соответствии со стандартом PMI PMBOK
• Управление проектами по технологии быстрого результата
• Контрольное домашнее задание 3.

4. ВЫПУСКНАЯ АТТЕСТАЦИОННАЯ РАБОТА

Особенности заочного (дистанционного) обучения

Материалы дисциплин представлены в виде видеофильмов или электронного текста.

Возможность обучения 24ч 7 дней в неделю: обучение и контроль знаний происходят полностью дистанционно в любое время суток и в любой стране мира. Для обучения слушателям нужны только компьютер и доступ в интернет.

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

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

Контроль знаний проводится после изучения каждой темы (лекции) и после завершения изучения каждой дисциплины. Это необходимое условие аттестации. Только этим задается определенная очередность изучения материала.

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