Вестник итарк




НазваниеВестник итарк
страница6/13
Дата публикации16.06.2013
Размер1.4 Mb.
ТипДокументы
lit-yaz.ru > Информатика > Документы
1   2   3   4   5   6   7   8   9   ...   13
^

МЕТОДОЛОГИЯ ВЫБОРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ ОРГАНИЗАЦИИ



Ю.В. Гольчевский, А.В. Малдрик 3
Аннотация: В статье предлагается алгоритм выбора наиболее подходящих программных продуктов для решения стоящих перед структурными подразделениями организации задач.

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

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

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

В представленной статье предлагается алгоритм поиска и выбора программных продуктов, способных наиболее оптимально решать стоящие перед структурными подразделениями организации задачи, и, как следствие, способных повышать эффективность работы всей организации в целом. Данный алгоритм применялся в работе отдела программирования Сыктывкарского государственного университета (СыктГУ) в 2010-2011 годах и достаточно хорошо себя зарекомендовал, позволив находить и принимать оптимальные решения. Также он позволил четче формулировать потребности организации в различном программном обеспечении и выбирать наиболее оптимальные варианты из предлагаемых на рынке информационных-технологических продуктов.
Итак, можно выделить, как минимум, пять последовательных этапов реализации данного алгоритма (этапов может быть и больше, если включить верификацию результатов с помощью других методик).
1. ^ Анализ бизнес-процессов организации. Данный этап необходим для формирования четкого понимания конкретных особенностей функционирования подразделений в той области деятельности, которая нуждается в автоматизации.

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

Для углубления понимания процессов и формализации полученных данных далее можно рекомендовать использовать UML-методологию объектно-ориентированного моделирования [2]. Унифицированный язык UML (United Modeling Language) является визуальным языком моделирования, который позволяет представлять свое видение будущей системы в легкой для понимания форме. Это способствует более легкому и точному выявлению и описанию проблем в сфере информатизации исследуемого процесса. Наиболее широко в данном контексте могут использоваться следующие виды диаграмм UML:

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

Рис. 1. Пример диаграммы прецедентов.
2. Диаграмма видов деятельности. Диаграмма видов деятельности UML похожа на блок-схему, в которой точками принятия решений и переходов описывается последовательность шагов. Каждый вид деятельности изображается прямоугольником со скругленными углами, а переход от одного прямоугольника к другому – стрелкой. На диаграмме видов деятельности имеется начальная точка и конечная точка. Точки принятия решения можно изобразить несколькими способами, например, используя изображение ромба (рис. 2).


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

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

Рис. 3. Обобщенный вид диаграммы развертывания.
В качестве третьего шага для повышения эффективности анализа бизнес-процессов применяется методология функционального моделирования IDEF0, являющаяся частью методологии структурного анализа и проектирования SADT [3, 4]. Задача функционального моделирования состоит в представлении бизнес-процесса в виде совокупности взаимосвязанных функций. IDEF0-модель описывает, какие действия выполняются в ходе каждой операции, какой продукт производится на ее выходе, какая информация используется для управления действиями, а также какие ресурсы и средства применяются для исполнения ее функций. Графическое представление модели бизнес-процесса в нотации IDEF0 изображено на рис. 4.

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

Рассмотрим небольшой пример. Ниже, на рис. 5, приведена диаграмма бизнес-процесса «Организация внутреннего документооборота» «как есть» для Сыктывкарского государственного университета.

Рис. 5. SADT-диаграмма бизнес-процесса

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

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

Рис. 6. SADT-диаграмма бизнес-процесса

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

Рис. 7. Декомпозиция SADT-модели бизнес-процесса

«Организация внутреннего документооборота» («как есть»)
2. ^ Формулирование требований. На этой стадии исследования используют результаты анализа бизнес-процессов организации, полученные ранее. Следует заметить, что процедура выявления требований будет неполной без учета представлений и пожеланий потенциальных пользователей. Анализ их видения проблемы позволит задать направление поиска информационной системы, максимально адаптированной к специфике деятельности предприятия. Наиболее распространенными методиками анализа требований пользователей являются устные опросы и анкетирование.

Следующим шагом является структуризация выявленных требований. Требования к информационной системе можно разделить на технические требования и бизнес-требования [4].

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

К бизнес-требованиям чаще всего относят:

- наличие необходимого функционала;

- простота работы с системой;

- эргономичность интерфейса;

- способность адаптации к бизнес-процессам конкретного предприятия;

- надежность механизма защиты информации.

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

  • метание из стороны в сторону в попытке автоматизировать системы организации, приобретение неэффективного аппаратного и программного обеспечения;

  • лоскутная автоматизация;

  • нарушение коммуникаций между структурными подразделениями организации;

  • потеря денег и, возможно, самое главное (особенно для коммерческих организаций) – времени;

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

В случае, если такие взаимосвязанные стратегии отсутствуют – их разработка (хотя бы в черновом варианте) должна предшествовать любому более-менее значимому для предприятия проекту.
3. ^ Анализ рынка программного обеспечения. Для выбора программного продукта, максимально отвечающего потребностям заказчика, может использоваться квалиметрический метод анализа, позволяющий осуществить количественную оценку качественных параметров [5].

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

  • надежность системы защиты данных;

  • «мощность» хранилища документов;

  • наличие необходимого функционала;

  • возможность адаптации к бизнес-процессам организации;

  • простота работы с системой;

  • эргономичный интерфейс;

  • условия сопровождения системы;

  • стоимость системы.

Далее производится оценка каждого продукта по этим параметрам. Если показатель невозможно оценить количественно, ему присваивается соответствующее число баллов по выбранной шкале (например, по пятибалльной шкале оценки). Чтобы мнение по каждой из рассматриваемых систем было наиболее объективным, применяется метод экспертных оценок: несколько специалистов предметной области (обычно не менее пяти) выставляют свою оценку программе по каждому из показателей, после чего производится их усреднение и получение итоговой оценки. Такой набор данных может иметь вид, представленный ниже в табл. 1.
Таблица 1. Результаты экспертной оценки некоторого программного продукта.

Характеристика

Эксперт №1

Эксперт №2


Эксперт №3


Эксперт №4


Эксперт №5


^ Средний балл


1. Защита данных

5

5

5

5

5

5

2. Мощность СУБД

3

3

4

2

3

3

3. Функционал

4

5

4

4

3

4

4. Адаптация к БП

3

3

4

3

3

3,2

5. Простота работы

5

4

5

5

4

4,6

6. Эргономичный интерфейс

5

5

4

5

5

4,8

7. Система сопровождения

4

3

5

4

4

4

8. Стоимость системы

3

2

2

4

2

2,6


На следующем этапе осуществляется перевод абсолютных показателей ^ Q в относительные K для обеспечения сопоставимости их значений. Для этого используется следующая формула:

Kij = Qij / qiэт,

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

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

Информационная система

Показатели и баллы по показателям

Общий

балл

1

2

3

4

5

6

7

8

Информационная система №1

100

60

91

64

96

100

83

52

78,54

Информационная система №2

100

96

100

88

67

50

100

40

76,16

Информационная система №3

100

100

95

80

83

88

100

36

81,77

Информационная система №4

76

92

73

68

83

88

75

40

72,47

Информационная система №5

84

96

86

100

92

88

96

96

92,09

Информационная система №6

96

100

95

92

100

100

100

100

97,83


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

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

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

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

  • заказ на разработку программных продуктов непосредственно под требования конкретной организации;

  • самостоятельная разработка и внедрение программных продуктов непосредственно IT-подразделением предприятия.

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

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

Строгий алгоритм анализа позволяет объективно оценить применимость каждой информационной системы из имеющихся на рынке к решению задач организации. При желании результаты квалиметрического анализа можно уточнить другими способами, например, изучением отзывов специалистов других организаций и предприятий.
4. ^ Разработка проекта внедрения информационной системы. Не будучи грамотно введенной в процесс функционирования предприятия, сама по себе информационная система не представляет особой некой «внутренней» ценности. Даже оптимальный программный продукт не будет работать эффективно, если проект его внедрения был неудачным. Это обуславливает необходимость использования методологии управления проектами.

Одну из таких методологий предлагает Свод знаний по управлению проектами по стандарту PMBOK [6]. Согласно этому документу, эффективный проект предполагает реализацию следующих подготовительных стадий.

1. ^ Календарное планирование проекта. Зная основные этапы деятельности, можно точно определить, какие ресурсы должны участвовать в реализации каждого этапа и какие факторы влияют на качество и своевременность его осуществления. Исходя из структуры календарного плана, можно сформировать списки необходимых ресурсов и контролировать распределение этих ресурсов в течение всего хода реализации проекта. Пример такого календарного плана (несколько усеченный для большей краткости) приведен в табл. 3. Наиболее удобный вид такого плана, на наш взгляд, – диаграмма Ганта.
Таблица. 3. Усеченный пример календарного плана.



Название этапа

Дата

начала

Дата

окончания

Ожидаемый результат

1

Определение состава проектной группы

1.1

Формирование списка ролей

05.04.2011

06.04.2011

Список ролей

1.2

Формирование команды управления проектом

07.04.2011

07.04.2011

Список участников команды управления

1.3

Выявление возможностей совмещения ролей

07.04.2011

08.04.2011

Структурированный список ролей

1.4

Утверждение участников проектной группы

09.04.2011

09.04.2011

Список участников проектной группы

2

Анализ рисков проекта

2.1

Выявление потенциальных угроз

12.04.2011

14.04.2011

Таблица рисков

2.2

Определение путей минимизации влияния рисков

15.04.2011

16.04.2011

Паспорта основных рисков

2.3

Определение действий в случае реализации угрозы

15.04.2011

16.04.2011

2.4

Назначение ответственных лиц

15.04.2011

16.04.2011

3

Анализ соответствия функционала ИС требованиям предприятия

3.1

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

20.04.2011

21.04.2011

Список требований к ИС

3.2

Анализ функциональности ИС

21.04.2011

22.04.2011

Список функций ИС

3.3

Проверка соответствия функций ИС требованиям предприятия

23.04.2011

23.04.2011

Список нереализованных функций

3.4

Настройка ИС

26.04.2011

04.05.2011

Настроенная ИС

4

Определение состава участников пилотного проекта

4.1

Выявление структуры

05.05.2011

05.05.2011

Список участков

4.2

Выбор состава участников пилотного проекта

05.05.2011

05.05.2011

Состав участников пилотного проекта

5

Настройка ИС для реализации пилотного запуска

5.1

Создание временных пользователей

06.05.2011

06.05.2011

Список временных пользователей и паролей

5.2

Временное ограничение функциональности ИС

06.05.2011

07.05.2011

ИС с ограниченным набором функций

6

Разработка сопроводительной документации (в случае собственной разработки)

10.05.2011

14.05.2011

Руководство пользователя

системы и Руководство администратора системы

7

Обучение участников пилотного проекта

17.05.2011

18.05.2011

Овладение участниками принципами работы с ИС

8

Запуск пилотного проекта

8.1


Проверка характеристик компьютеров участников пилотного проекта и настройка техники

19.05.2011

20.05.2011

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

8.2

Установка системы на компьютерах участников пилотного проекта

20.05.2011

20.05.2011

Установленная система на компьютерах участников

8.3

Мониторинг работы с системой участников пилотного проекта

20.05.2011

06.06.2011

Список действий и ошибок пользователей при работе

9

Сбор отзывов о функциональности

системы, производительности и т.п.

07.06.2011

08.06.2011

Отзывы о функциональности системы

10

Анализ отзывов участников пилотного проекта о системе

10.1

Выявление причин негативных отзывов

09.06.2011

13.06.2011

Список причин негативных отзывов

10.2

Анализ возможности устранения причин негативных отзывов

13.06.2011

15.06.2011

Список необходимых доработок системы

11

Настройка системы в соответствии с отзывами участников пилотного проекта

16.06.2011

25.06.2011

Устранение недостатков настройки системы

12

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

12.1

Определение наиболее масштабных потоков движения документации

28.06.2011

30.06.2011

Схема наиболее масштабных потоков движения документации

12.2

Составление последовательности внедрения в структурных подразделениях

30.06.2011

02.07.2011

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

13

Дополнение функционала ИС до рабочей версии

13.1

Создание пользователей

05.07.2011

06.07.2011

Список пользователей и паролей системы

13.2

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

07.07.2011

09.07.2011

Система с полной функциональностью

14

Доработка сопроводительной документации

12.07.2011

13.07.2011

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

15

Обучение пользователей

19.07.2011

30.07.2011

Овладение пользователями принципами работы

16

Передача системы в эксплуатацию

16.1

Проверка технических характеристик компьютеров пользователей

02.08.2011

04.08.2011

Перечень необходимых настроек техники

16.2

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

05.08.2011

06.08.2011

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

16.3

Установка системы на компьютерах пользователей

07.08.2011

09.08.2011

Развернутая система

16.4

Мониторинг работы пользователей с системой, устранение возникающих в процессе работы сбоев и неполадок

09.08.2011

31.08.2011

Список действий и ошибок пользователей при работе с системой


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

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

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

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

Библиографический список


  1. Антошина И.В. Процедуры и модели оценки качества и выбора прикладного программного обеспечения систем обработки информации. Диссертация. – М.: 2001. – 225 с.

  2. Шмуллер Дж. Освой самостоятельно UML за 24 часа, 3-е издание.: Пер. с англ. – М.: Издательский дом «Вильямс», 2005. – 416 с.

  3. Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. – М.: Финансы и статистика, 2007. – 240 с.

  4. Бабенко В.В. Практический анализ бизнес-процессов. – Сыктывкар: Изд-во СыктГУ, 2010. – 288 с.

  5. Варжапетян А.Г. Квалиметрия: Учебное пособие. – СПб.: ГУАП, 2005. – 176 с.

  6. A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Fourth Edition. 2008. Project Management Institute. – 459 с.



Yu.V. Golchevskiy, A.V. Maldrik
^ SOFTWARE SELECTION FOR THE ORGANIZATION

Abstract: The paper offers the method of selection the most appropriate software for resolving the organizational departments problems. It describes the five steps on the way to introduction of information system: business-process analysis, establishing software requirements, IT-market researching, development of software introduction project and analysis of its effectiveness. The methods are the functional (SADT) and object-oriented (UML) modeling, qualimetry method, balanced scorecard (BSC) and key performance indicator (KPI).

Keywords: software, business-planning, business-processes, algorithm of software selection.


1   2   3   4   5   6   7   8   9   ...   13

Похожие:

Вестник итарк iconБюллетень экспериментальной биологии и медицины ▲ Вестник дерматологии...
Вестник Московского университета. Серия 15. Вычислительная математика и кибернетика ▲

Вестник итарк iconЮрген Граф Миф о холокосте Правда о судьбе евреев во второй мировой...
В издательство «Русский Вестник», с просьбой опубликовать этот материал, обратился Институт пересмотра истории (Institute Historical...

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

Вестник итарк iconЗорина Л. Любовь, рожденная на войне // Беловский вестник. – 2000....
Зорина Л. Любовь, рожденная на войне // Беловский вестник. – 2000. – №58 (9969). 18 мая. – С. 2

Вестник итарк iconВестник 2012

Вестник итарк iconЗарубежной историографии
Статья опубликована в журнале Вестник гуманитарного института тгу. – 2010. №2 (6)

Вестник итарк iconОпубликовано в: Вестник Ленинградского государственного университета...
...

Вестник итарк iconМои стихи: «Осень»
Стихотворение, посвященное славному юбилею – 75-летию газеты «Городищенский вестник»

Вестник итарк iconЧауниной Натальи Владимировны
Педагогический вестник. Вып сб науч тр. – Нерюнгри : Изд-во ягу, 1998. – С. 44–46

Вестник итарк iconМузейный вестник
Челябинско-Петраковской добровольческой, орденов Кутузова, Суворова Краснознаменной танковой бригады



Образовательный материал



При копировании материала укажите ссылку © 2013
контакты
lit-yaz.ru
главная страница