????? ??????????? ???????? ?????? Microsoft Project MPP ? by Zcc38aCl

VIEWS: 157 PAGES: 51

									                        Вопросы для экзамена по курсу “Проектирование АСОИУ”/ 12/2006
1. Общая характеристика процесса проектирования АСОИУ. Цели и этапы разработки
консалтинговых проектов .......................................................................................................................... 2
2. Разработка системного проекта на основе стандарта ISO 12207. Основные процессы
жизненного цикла программного обеспечения АСОИУ. ....................................................................... 5
3. Модели жизненного цикла программного обеспечения АСОИУ. Подход RAD. ........................ 7
4. Структурный подход к проектированию информационной системы. Функциональная модель
АСОИУ. Количественный анализ диаграмм IDEF0 и DFD. ................................................................. 10
5. Объектно-ориентированный подход к анализу и проектированию информационной системы.
Унифицированный язык моделирования UML...................................................................................... 11
6. Моделирование бизнес-процессов спецификация требований на основе структурного
подхода. ...................................................................................................................................................... 14
7. Моделирование бизнес-процессов спецификация требований на основе объектно-
ориентированного подхода. Методика RUP. ......................................................................................... 15
8. Разработка модели защиты данных в АСОИУ. ............................................................................. 16
9. Разработка пользовательского интерфейса. .................................................................................. 17
10. Проектирование распределенной обработки данных. .................................................................. 18
11. Анализ и оценка производительности АСОИУ. ........................................................................... 20
12. Управление проектом АСОИУ ....................................................................................................... 20
13. Проектная документация АСОИУ. Требования ГОСТов к документации, содержание
документации. ........................................................................................................................................... 22
14. Инструментальные средства проектирования АСОИУ. ............................................................... 24
15. Типизация проектных решений АСОИУ. Использование коробочных продуктов и
адаптируемых интегрированных систем. ............................................................................................... 25
16. Графические средства представления проектных решений АСОИУ (IDEF, DFD, UML, ERD и
т.д.) ............................................................................................................................................................ 29
17. Распределенная обработка данных. ................................................................................................ 31
18. Системное проектирование Программных систем на основе стандартизации. ......................... 33
19. Стандартизированные показатели качества сложных программных систем ............................. 34
20. Понятие и виды CASE-средств ....................................................................................................... 35
21. Стандарты для информационных систем управления MRP, ERP, CSRP, CRM ........................ 36
22. Аспекты внедрения ERP-систем. Стратегии и типы производства ............................................ 38
23. Стратегии производства и период поставки .................................................................................. 39
24. Стратегии производства и методы планирования......................................................................... 39
25. Выбор типа управления производством ........................................................................................ 40
26. Эффективность внедрения корпоративной информационной системы. Традиционные
финансовые методы .................................................................................................................................. 41
27. Эффективность внедрения корпоративной информационной системы.Качественные методы ..
      ............................................................................................................................................................ 42
28. Эффективность внедрения корпоративной информационной системы. Вероятностные методы
      ............................................................................................................................................................ 43
29. Характеристика рынка программного обеспечения по автоматизации деятельности
организации. Состояние рынка программного обеспечения ................................................................ 44
30. Характеристика рынка программного обеспечения по автоматизации деятельности
организации. Основные участники рынка информационных и телекоммуникационных технологий ..
      ............................................................................................................................................................ 44
31. Характеристика рынка программного обеспечения по автоматизации деятельности
организации. Критерии выбора корпоративной информационной системы....................................... 45
32. Основные подходы внедрения КИС ............................................................................................... 47
33. Стратегии внедрения КИС на примере “Баан” .............................................................................. 49
34. Стратегии внедрения КИС на примере корпорации “Парус” ...................................................... 49




                                                                                   1
   1. Общая характеристика процесса проектирования АСОИУ.
Цели и этапы разработки консалтинговых проектов
     Современные информационные технологии предоставляют широкий набор способов
реализации АСОИУ, выбор которых осуществляется на основе требований со стороны
предполагаемых пользователей, которые, как правило, изменяются в процессе разработки. Для
теории принятия решений процесс проектирования системы – это процесс принятия проектно-
конструкторских решений, направленных на получение версии системы, удовлетворяющей
требования заказчика.
     Под проектом будем понимать проектно-конструкторскую и технологическую
документацию, в которой представлено описание проектных решений по созданию и
эксплуатации системы в конкретной программно-технической среде.
     Под проектированием системы понимается процесс преобразования входной информации
об объекте проектирования, о методах проектирования и об опыте проектирования объектов
аналогичного назначения в соответствии с ГОСТом в проект АСОИУ. С этой точки зрения
проектирование АСОИУ сводится к последовательной формализации проектных решений на
различных стадиях жизненного цикла системы: предпроектного анализа требований, технического
и рабочего проектирования, внедрения и эксплуатации АСОИУ.
     Осуществление проектирования системы предполагает использование проектировщиками
определенной технологии проектирования, соответствующей масштабу и особенностям
разрабатываемого проекта.
     Технология проектирования системы – это совокупность методологии и средств
проектирования системы, а также методов и средств организации проектирования (управление
процессом создания и модернизации проекта системы).
     В основе технологии проектирования лежит технологический процесс, который определяет
действия, их последовательность, состав исполнителей, средства и ресурсы, требуемые для
выполнения этих действий. Технологический процесс проектирования системы в целом делится на
совокупность последовательно-параллельных, связанных и соподчиненных цепочек действий,
каждое из которых может иметь свой предмет.
     Проектирование системы – трудоемкий, длительный и динамический процесс. Технологии
проектирования, применяемые в настоящее время, предполагают поэтапную разработку системы.
Этапы по общности могут разделятся в стадии. Совокупность стадий и этапов, которые проходит
система в своем развитии о момента принятия решения о создании системы до момента
прекращения функционирования системы, называется жизненным циклом системы.
     Суть содержания жизненного цикла разработки системы в различных подходах одинакова и
сводится к выполнению следующих стадий:
     Планирование и анализ требований (предпроектная стадия) – системный анализ.
Исследование и анализ существующей системы, определение требований к создаваемой системе,
оформление технико-экономического обоснования и технического задания на разработку системы.
     Проектирование (техническое проектирование, логическое проектирование). Разработка в
соответствии со сформулированными требованиями состава автоматизируемых функций и состава
обеспечивающих подсистем, оформление технического проекта системы.
     Реализация     проекта    (рабочее    проектирование,    физическое     проектирование,
программирование). Разработка и настройка программ, наполнение баз данных, создание рабочих
инструкций для персонала, оформление рабочего проекта.
     Внедрение (тестирование, опытная эксплуатация). Комплексная отладка подсистем, обучение
персонала, поэтапное внедрение системы в эксплуатацию, оформление акта о приемо-сдаточных
испытаниях системы.
     Эксплуатация системы (сопровождение, модернизация). Сбор рекламаций и статистики о
функционировании системы, исправление ошибок и недоработок, оформление требований к
модернизации системы и ее выполнение.




                                              2
      Консалтинг
      Консалтинг - это деятельность специалиста или целой фирмы, занимающихся
стратегическим планированием проекта, анализом и формализацией требований к
информационной системе, созданием системного проекта, иногда - проектированием приложений.
      Цели и этапы разработки консалтинговых проектов.
      Основными целями разработки консалтинговых проектов являются:
     представление деятельности предприятия и принятых в нем технологий в виде иерархии
       диаграмм, обеспечивающих наглядность и полноту их отображения;
     формирование на основании анализа предложений по реорганизации организационно-
       управленческой структуры;
     упорядочивание информационных потоков (в том числе документооборота) внутри
       предприятия;
     выработка рекомендаций по построению рациональных технологий работы подразделений
       предприятия и его взаимодействию с внешним миром;
     анализ требований и проектирование спецификаций корпоративных информационных
       систем;
     рекомендации и предложения по применимости и внедрению существующих систем
       управления предприятиями (прежде всего классов MRP - manufacturing resource planning и
       ERP - enterprise resource planning).
Структуру подхода к разработке консалтинговых проектов можно представить след. этапами.
1. Анализ первичных требований и планирование работ
Его основными задачами являются: анализ первичных бизнес-требований, предварительная
экономическая оценка проекта, построение план-графика выполнения работ, создание и обучение
совместной рабочей группы.
2. Проведение обследования деятельности предприятия
В рамках данного этапа осуществляется:
     предварительное выявление требований, предъявляемых к будущей системе;
     определение оргштатной и топологической структур предприятия;
     определение перечня целевых задач (функций) предприятия;
     анализ распределения функций по подразделениям и сотрудникам;
     определение перечня применяемых на предприятии средств автоматизации.
3. Построение моделей деятельности предприятия
На данном этапе осуществляется обработка результатов обследования и построение моделей
деятельности предприятия следующих двух видов:
     модели “как есть”;
     модели “как должно быть”
4. Разработка системного проекта
Данный этап является первой фазой разработки собственно системы автоматизации, на которой
требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе
дается ответ на вопрос: "Что должна делать будущая система?".
5. Разработка предложений по автоматизации предприятия
6. Разработка технического проекта
На данном этапе на основе системного проекта и принятых решений по автоматизации
осуществляется проектирование системы. Фактически здесь дается ответ на вопрос: "Как (каким
образом) мы будем строить систему, чтобы она удовлетворяла предъявленным к ней
требованиям?". Этот этап разделяется на два подэтапа:
     проектирование архитектуры системы;
     детальное проектирование;
7. Последующие этапы
В случае разработки собственной системы последующие этапы являются традиционными: по
спецификациям технического проекта осуществляется программирование модулей, их
тестирование и отладка и последующая комплексация в автоматизированные рабочие места и в


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




                                               4
   2. Разработка системного проекта на основе стандарта ISO
12207. Основные процессы жизненного цикла программного
обеспечения АСОИУ.
     Структура курсового проекта:
     Введение
     Применяемые стандарты
     Оформление текста курсовой работы выполняется в соответствии с требованиями ГОСТ.
     Глав. 1. Общая характеристика объекта автоматизации. Подразделения предприятия.
Организационная структура IT службы предприятия. Функциональная структура АСУ.
     Общая характеристика деятельности предприятия.
     Глав. 2. Систематизация документооборота.
     Глав. 3. Общая характеристика применяемых на предприятии тех. и программных средств.
     Глав. 4. Разработка функциональной модели предприятия как есть.
     Глав. 5. Как должно быть.
     Глав. 6. Разработка технического задания.
     Заключение
     Актуальность, цель, задачи (выполненные). Перспективы развития данной работы.
Литература.
     Приложение. Оглавление приложений
     Текст выступления. 3 плаката.
     Структура технического задания.
       1.1. Полное наименование системы, ее условное обозначение.
       1.2. Шифр темы или шифр договора.
       1.3. Наименование предприятия разработчика и заказчика и их реквизиты.
       1.4. Перечень документов, на основании которых, создается данная информационная
           система.
       1.5. Плановые сроки начала и окончания работы.
       1.6. Сведения об источниках и порядке финансирования работ.
       1.7. Порядок оформления и предъявление заказчику порядок работ по созданию проекта.
     2. Назначение и цели создания (развития) системы
       2.1. Вид автоматизируемой деятельности.
       2.2. Перечень объектов, на которых предполагается использовать систему.
       2.3. Наименование и требуемые значения показателей объекта (технических,
технологических, производственно технологических, которые должны быть достигнуты при
продвижении к цели).
     3. Характеристика объекта автоматизации.
       3.1. Краткие сведения об объекте авт.
       3.2. Сведения об условии эксплуатации и окружающей среды.
     4. Требования к системе.
       4.1. Требования к системе в целом.
         4.1.1. Требования к структуре и функционирования системы (перечень подсистем, уровни
иерархии, степень детализации, способы информационного обмена, режимы функционирования,
взаимодействие со смежными системами).
         4.1.2. Требования к персоналу (численность пользователей, квалификация, режим работы,
порядок подготовки).
         4.1.3. Показатели назначения (степень приспасабливоемости системы к процесса в
системе)
         4.1.4. Требования к безопасности, эргономике, эксплуатации, ремонту, защите
информации, патентной чистоте, по стандартизации и унификации.
       4.2. Требования к функциям по под системам.
         4.2.1. Перечень задач стоящих перед автоматизацией.
         4.2.2. Временной регламент реализации каждой функции.
         4.2.3. Требования к структуре выходных результатов.
                                               5
         4.2.4. Перечень и критерии отказов.
       4.3. Требования к видам обеспечений.
         4.3.1. Математическое обеспечение (состав и область применения мат. моделей типовых и
разрабатываемых алгоритмов).
         4.3.2. Информационное (состав, структура и организация данных, обмен данными между
компонентами системами, совместимость между компонентами, используемые классификаторы
шифраторы, СУБД, контроль данных и ведение информационных массивов).
         4.3.3. Лингвистическое обеспечение (языки программирования, языки ввода вывода,
системы кодирования).
         4.3.4. Программное обеспечение. Независимость ПО от платформы. Качество
программных средств, способов его контроля. Использование фондов алгоритмов и программ.
         4.3.5. Метрологическое обеспечение.
         4.3.6. Требования к организационному обеспечению (структура и функции
технологическому обеспечению, защита от ошибочных действий персонала)
         4.3.7. Требования к методическому обеспечению (состав нормативно технической
документации)
     5. Состав и содержание работ по поддержанию систем (перечень стадий и этапов работ)
       5.1. Перечень стадий и этапов работ.
       5.2. Сроки исполнения
       5.3. Состав организации исполнителей работ
       5.4. Вид и порядок экспертизы технической документации
       5.5. Программа обеспечения надежности
       5.6. Программа метрологического обеспечения
     6. Порядок контроля и приемки системы.
       6.1. Виды, состав, объем и методы испытаний системы
       6.2. Общие требования к приемке работ по стадиям
       6.3. Статус приемной комиссии
     7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу
системы в действии.
       7.1. Преобразование входной информации к машиночитаемому виду
       7.2. Изменения в объекте автоматизации
       7.3. Сроки и порядок комплектования и обучения персонала
     8. Требования к документированию.
       8.1. Перечень подлежащих к разработке документов
       8.2. Перечень документов на машинных носителях
     9. Источники разработки. Это документы и информационные материалы, на основании
которых разрабатывается ТЗ и информационная система.
     Основные процессы ЖЦ
     ISO 12-207
     Жизненный цикл определяется как период времени который начинается с момента принятия
решения о необходимости о его разработке проекта до полной утилизации. Основной
нормативный документ определяющий ЖЦ ИС является стандарт ISO 12-207: 1995.
     Он определяет структуру ЖЦ содержащие процессы, действия и задачи которые должны
быть выполнены во время создания ПО. Программный продукт- это набор компьютерных
программ, процедур и возможно связанной с ним документации и данных. Процесс- это
совокупность взаимосвязанных действий преобразующий некоторые входные данные в выходные.
Каждый процесс характеризуется определенными задачами, исходными данными полученными от
других процессов и результатами. Каждый процесс разделен на действия, каждое действие
включает набор задач. Причем каждый процесс, действие или задача инициализируется или
выполняется по мере необходимости. Причем не существует заранее определенных
последовательностей выполнения. Согласно со стандартом ISO 12-207 процессы делятся на три
группы: основные, вспомогательные, организационные.




                                               6
  3. Модели жизненного цикла программного обеспечения
АСОИУ. Подход RAD.
     Модель жизненного цикла - это структура, определяющая последовательность
выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Наибольшее
распространение получили каскадная, а затем спиральная модели.
     Рассмотрим каскадную и спиральную модели подробнее:
                                       1. Каскадная модель
     Данная модель предполагает строго последовательное (во времени) и однократное
выполнение всех фаз проекта с жестким (детальным) предварительным планированием в
контексте предопределенных или однажды и целиком определенных требований к программной
системе. [4]
     Каскадная модель разбивает процесс ЖЦ на пять этапов, выполняемых последовательно,
один за другим:




                             Рисунок 5. Каскадная схема разработки ПО
     Недостатки:
      часто возникает потребность в возврате к предыдущим этапам для уточнения или
пересмотра ранее принятых решений. В результате процесс принимает вид “модели с
промежуточным контролем”




                     Рисунок 6. Каскадная схема с промежуточным контролем
       существенное запаздывание с получением результатов,
       требования к ИС "заморожены" в виде технического задания на все время ее создания,
и, в случае неточного изложения требований или их изменения за время создания ПО, модель
автоматизируемого объекта устаревает к моменту реализации.
                                     2. Спиральная модель
      Спиральная модель была впервые сформулирована Барри Боэмом (Barry Boehm) в 1988 году.
Делает упор на начальные этапы ЖЦ - анализ и проектирование. Реализуемость технических решений
проверяется на этих этапах путем создания прототипов.




                                                    7
                       Рисунок 7. Спиральная модель жизненного цикла ПО
     Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем
уточняются цели и характеристики проекта, определяется качество и планируются работы
следующего витка.
     Главная задача при работе по спиральной модели - возможно быстрее показать
пользователю работоспособный продукт, чтобы активизировать процесс уточнения и
дополнения требований.
     Сам Барри Боэм так характеризует спиральную модель разработки (используется с
разрешения автора):
     “Главное достижение спиральной модели состоит в том, что она предлагает спектр
возможностей адаптации удачных аспектов существующих моделей процессов жизненного цикла.
В то же время, ориентированный на риски подход позволяет избежать многих сложностей,
присутствующих в этих моделях. В определенных ситуациях спиральная модель становится
эквивалентной одной из существующих моделей. В других случаях она обеспечивает возможность
наилучшего соединения существующих подходов в контексте данного проекта.
     Спиральная модель обладает рядом преимуществ:
      Модель уделяет специальное внимание раннему анализу возможностей повторного
использования. Это обеспечивается, в первую очередь, в процессе идентификации и оценки
альтернатив.
      Модель предполагает возможность эволюции жизненного цикла, развитие и изменение
программного продукта. Главные источники изменений заключены в целях, для достижения
которых создается продукт. Подход, предусматривающий скрытие информации о деталях на
определенном уровне дизайна, позволяет рассматривать различные архитектурные альтернативы
так, как если бы мы говорили о единственном проектном решении, что уменьшает риск
невозможности согласования функционала продукта и изменяющихся целей (требований).
      Модель предоставляет механизмы достижения необходимых параметров качества как
составную часть процесса разработки программного продукта. Эти механизмы строятся на основе
идентификации всех типов целей (требований) и ограничений на всех “циклах” спирали
разработки. Например, ограничения по безопасности могут рассматриваться как риски на этапе
специфицирования требований.
      Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию
ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах проекта.
Это достигается явно определенными работами по анализу рисков, проверке различных
характеристик создаваемого продукта (включая архитектуру, соответствие требованиям и т.п.) и
подтверждение возможности двигаться дальше на каждом “цикле” процесса разработки.
      Модель позволяет контролировать источники проектных работ и соответствующих затрат.
По-сути речь идет об ответе на вопрос – как много усилий необходимо затратить на анализ
требований, планирование, конфигурационное управление, обеспечение качества, тестирование,
формальную верификацию и т.д. Модель, ориентированная на риски, позволяет в контексте

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




         Рисунок 8. Оригинальная спиральная модель жизненного цикла разработки по Боэму
     Недостатки:
     Основная проблема спирального цикла - определение момента перехода на следующий
этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов
жизненного цикла.
     Переход с этапа на этап осуществляется в соответствии с планом, даже если не вся
запланированная работа закончена. План составляется на основе статистических данных,
полученных в предыдущих проектах, и личного опыта разработчиков.
                                     3. Методология RAD
     Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является
получившая в последнее время широкое распространение методология быстрой разработки
приложений - RAD (Rapid Application Development).
     Методология RAD предполагает:
      маленький коллектив 2 – 10 чел.
                                             9
      короткий график от 2 до 6 мес.
      повторяющийся цикл
     Основные принципы методологии RAD
      итерационность процесса разработки приложений;
      необязательность полного завершения работ на каждом этапе;
      максимальное вовлечение пользователей в разработку;
      использование CASE - средств, обеспечивающих целостность проекта;
      использование генераторов программного кода;
      использование прототипирования для уточнения потребностей пользователей;
      тестирование и развитие проекта одновременно с разработкой;
      небольшие квалифицированные команды разработчиков;
      четкое планирование и контроль на всех этапах работы.
     Методология RAD дает хорошие результаты при выполнении относительно небольших
проектов для конкретного заказчика.
     Однако, ее нельзя использовать:
      при разработке типовых систем, которые затем адаптируются к особенностям
объектов внедрения;
      для построения сложных расчетных программ, операционных систем, программ
управления сложными объектами (системы АСУ ТП);
      к приложениям, у которых интерфейсная часть не определяет логику работы системы;
      к разработке систем, от которых зависит безопасность людей (например: управление
самолетом или АЭС).
     Оценка размера приложения, а значит и необходимого количества разработчиков ПО,
производится, исходя из количества функциональных элементов в будущей системе.

   4. Структурный подход к проектированию информационной
системы. Функциональная модель АСОИУ. Количественный
анализ диаграмм IDEF0 и DFD.
      При структурном подходе как разновидности системного требуется синтезировать варианты
системы из компонентов (блоков) и оценивать варианты при их частичном переборе с
предварительным прогнозированием характеристик компонентов.
      Структурно-функциональный подход к проектированию
      Принципы:
  – Разделяй и властвуй;
  – иерархическое упорядочение;
  – абстрагирование (выделение существенных аспектов и отличие их от несущественных);
  – непротиворечивость (каждый элемент системы независим и не вступает в разнобой с
    остальными);
  – структурирование данных.
      Средства:
      DFD – диаграмма потоков данных;
      SADT – IDEF0, IDEF1, … – функциональные диаграммы;
      ERD – диаграмма "сущность–связь".

     Формирование требований к программному обеспечению:
     SADT и DFD – AS-IS/TO-BE/ShouldBE
     Стадия проектирования:
     SADT (1973г. Дуглас Росс)
     Основа метода – IDEF0 (Интегрированная компьютеризация производства)
     SADT отображает функциональную структуру объекта, производимые им действия и связи
между действиями.
     1) Блоки и дуги – взаимодействие блоков друг с другом описываются посредством
интерфейсных дуг.
                                             10
     2) Строгость и четкость – синтаксические правила, определяющие корректность диаграммы
(на одной диаграмме д.б. 3-6 блоков, нумерация блоков, различие имен).
     IDEF3
     Аналогичен IDEF0, но менее требователен к синтаксису.
     Существует понятие перекрестка – элемент который служит сигналом к началу нескольких
работ при окончании нескольких, либо он показывает, что для начала одной работы надо ждать
завершения нескольких работ.
     Объект ссылки – выражает идею, которую нельзя связать со стрелкой, перекрестком или
работой.
     DFD
     Методы Йордана и Гейна-Сэрсона.
     1) Внешние сущности – материальный объект или физическое лицо, организующее
(определяющие) источник/приемник информации;
     2) Подсистемы (№ поля/имя поля/физическая реализации);
     3) Процессы – преобразование входных потоков данных в выходные в соответствии с
определенным алгоритмом;
     4) Накопители данных – абстрактное устройство для хранения информации, которое можно в
любой момент поместить в накопитель и в любой момент извлечь;
     5) Потоки данных – определяет информацию, передаваемую через некоторое соединение от
источника данных к приемнику.

   5. Объектно-ориентированный подход к анализу и
проектированию информационной системы.
Унифицированный язык моделирования UML.
     В рамках языка UML все представления о модели сложной системы фиксируются в виде
специальных графических конструкций, получивших название диаграмм. В терминах языка UML
определены следующие виды диаграмм:
      Диаграмма вариантов использования (use case diagram)
      Диаграмма классов (class diagram)
      Диаграммы поведения (behavior diagrams)
     o       Диаграмма состояний (statechart diagram)
     o       Диаграмма деятельности (activity diagram)
     o       Диаграммы взаимодействия (interaction diagrams)
                  Диаграмма последовательности (sequence diagram)
                  Диаграмма кооперации (collaboration diagram)
      Диаграммы реализации (implementation diagrams)
     o       Диаграмма компонентов (component diagram)
     Диаграмма развертывания (deployment diagram)

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

     Графическое обозначение варианта использования
      Актеры
     Актер представляет собой любую внешнюю по отношению к
моделируемой системе сущность, которая взаимодействует с системой и
использует ее функциональные возможности для достижения
определенных целей или решения частных задач.
      Интерфейсы
     Интерфейс (interface) служит для спецификации параметров модели, которые видимы извне
без указания их внутренней структуры. Применительно к диаграммам вариантов использования,
интерфейсы определяют совокупность операций, которые обеспечивают необходимый набор
сервисов или функциональности для актеров.
                                               11
      В языке UML имеется несколько
стандартных видов отношений между
актерами и вариантами использования:
       Отношение ассоциации (association
relationship) между актером и вариантом
использования

           Отношение расширения (extend relation-
ship)
     Так, если имеет место отношение
расширения от варианта использования А к
варианту использования В, то это означает, что свойства экземпляра варианта использования В
могут быть дополнены благодаря наличию свойств у расширенного варианта использования А.




           Отношение обобщения (generalization relationship)

        Отношение
        
включения (include
relationship)




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




    Один из вариантов последующего уточнения диаграммы вариантов использования для
примера рассматриваемой системы продажи
    Класс


                                                     12
     Класс (class) в языке UML служит для обозначения множества объектов, которые обладают
одинаковой структурой, поведением и отношениями с объектами из других классов. Графически
класс изображается в виде прямоугольника, который дополнительно может быть разделен
горизонтальными линиями на разделы или секции (рис. 5.1). В этих разделах могут указываться
имя класса, атрибуты (переменные) и операции (методы).




                 Рис. 5.1. Графическое изображение класса на диаграмме классов
     Диаграмма состояний




    Рис. 6.5. Диаграмма состояний для моделирования почтовой программы-клиента
    Диаграмма деятельности (activity diagram)




                                              13
   6. Моделирование бизнес-процессов спецификация
требований на основе структурного подхода.
     На сегодняшний день в программной инженерии существуют два основных подхода к
разработке ПО ИС: функционально-модульный или структурный. В его основу положен принцип
функциональной декомпозиции, при которой структура системы описывается в терминах
иерархии ее функций и передачи информации между отдельными функциональными элементами.
Второй, объектно-ориентированный подход использует объектную декомпозицию.
     Итак, сущность структурного подхода к разработке ПО ЭИС заключается в его
декомпозиции (разбиении) на автоматизируемые функции: система разбивается на
функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те — на задачи и
так далее до конкретных процедур. При этом автоматизируемая система сохраняет целостное
представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы
"снизу вверх", от отдельных задач ко всей системе, целостность теряется, возникают проблемы
при описании информационного взаимодействия отдельных компонентов.
     Базовыми принципами структурного подхода являются:
      принцип "разделяй и властвуй"
      принцип иерархического упорядочения - принцип организации составных частей системы
в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

                                             14
      принцип абстрагирования – выделение существенных аспектов системы и отвлечение от
несущественных;
      принцип непротиворечивости — обоснованность и согласованность элементов системы;
      принцип структурирования данных - данные должны быть структурированы и
иерархически организованы.
     В структурном подходе используются в основном две группы средств, описывающих
функциональную структуру системы и отношения между данными.
      DFD (Data Flow Diagrams) — диаграммы потоков данных;
      SADT(Structured Analysis and Design Technique - метод структурного анализа и
проектирования) — модели и соответствующие функциональные диаграммы; (IDEF0)
      ERD (Entity-Relationship Diagrams) — диаграммы "сущность-связь".
     Диаграммы потоков данных и диаграммы "сущность-связь" - наиболее часто используемые в
CASE-средствах виды моделей.

   7. Моделирование бизнес-процессов спецификация
требований на основе объектно-ориентированного подхода.
Методика RUP.
     Объектно-ориентированный подход использует объектную декомпозицию, при этом
статическая структура системы описывается в терминах объектов и связей между ними, а
поведение системы описывается в терминах обмена сообщениями между объектами. Каждый
объект системы обладает своим собственным поведением, моделирующим поведение объекта
реального мира.
     Концептуальной основой объектно-ориентированного подхода является объектная модель.
Основными ее элементами являются:
      абстрагирование (abstraction);
      инкапсуляция (encapsulation);
      модульность (modularity);
      иерархия (hierarchy).
     Кроме основных имеются еще три дополнительных элемента, не являющихся в отличие от
основных строго обязательными:
      типизация (typing);
      параллелизм (concurrency),
      устойчивость (persistence).
     Абстрагирование - это выделение существенных характеристик некоторого объекта,
которые отличают его от всех других видов объектов и, таким образом, четко определяют его
концептуальные границы относительно дальнейшего рассмотрения и анализа.
     Инкапсуляция — это процесс отделения друг от друга отдельных элементов объекта,
определяющих его устройство и поведение. Инкапсуляция служит для того, чтобы изолировать
интерфейс объекта, отражающий его внешнее поведение, от внутренней реализации объекта.
     Модульность — это свойство системы, связанное с возможностью ее декомпозиции на ряд
внутренне связных, но слабо связанных между собой модулей. Инкапсуляция и модульность
создают барьеры между абстракциями.
     Иерархия — это ранжированная или упорядоченная система абстракций, расположение их
по уровням. Основными видами иерархических структур применительно к сложным системам
являются структура классов (иерархия по номенклатуре) и структура объектов (иерархия по
составу). Примерами иерархии классов являются простое и множественное наследование (один
класс использует структурную или функциональную часть соответственно одного или нескольких
других классов), а иерархии объектов - агрегация.
     Типизация — это ограничение, накладываемое на класс объектов и препятствующее
взаимозаменяемости различных классов (или сильно сужающее ее возможность). Типизация
позволяет защититься от использования объектов одного класса вместо другого или по крайней
мере управлять таким использованием.


                                             15
     Параллелизм — свойство объектов находиться в активном или пассивном состоянии и
различать активные и пассивные объекты между собой.
     Устойчивость — свойство объекта существовать во времени (вне зависимости от процесса,
породившего данный объект) и/или в пространстве (при перемещении объекта из адресного
пространства, в котором он был создан).
     Основные понятия объектно-ориентированного подхода — объект и класс.
     Объект определяется как осязаемая реальность (tangible entity) - предмет или явление,
имеющие четко определяемое поведение.
     Класс — это множество объектов, связанных общностью структуры и поведения. Любой
объект является экземпляром класса. Определение классов и объектов - одна из самых сложных
задач объектно-ориентированного проектирования.
     Понятие полиморфизма может быть интерпретировано как способность класса
принадлежать более чем одному типу. Наследование означает построение новых классов на
основе существующих с возможностью добавления или переопределения данных и методов.
     Важным качеством объектного подхода является согласованность моделей деятельности
организации и моделей проектируемой системы от стадии формирования требований до стадии
реализации. Требование согласованности моделей выполняется благодаря возможности
применения абстрагирования, модульности, полиморфизма на всех стадиях разработки. Модели
ранних стадий могут быть непосредственно подвергнуты сравнению с моделями реализации. По
объектным моделям может быть прослежено отображение реальных сущностей моделируемой
предметной области (организации) в объекты и классы информационной системы.

    8. Разработка модели защиты данных в АСОИУ.
     Большое внимание в настоящее время уделяется вопросам формирования принципов
построения механизмов защиты информации (ЗИ) и системы требований к ним. На основе
имеющегося опыта можно сформулировать следующие фундаментальные принципы организации
защиты информации:
      системность;
      специализированность;
      неформальность.
     Основные требования принципа системности сводятся к тому, что для обеспечения
надежной защиты информации в современных АСОИУ должна быть обеспечена надежная и
согласованная защита во всех структурных элементах, на всех технологических участках
автоматизированной обработки информации и во все время функционирования АСОИУ.
     Специализированность как принцип организации защиты предполагает два аспекта:
     1) ввиду специфических особенностей рассматриваемой проблемы надежный механизм
защиты может быть спроектирован и организован лишь профессиональными специалистами по
защите информации,
     2) для обеспечения эффективного функционирования механизма защиты в составе АСОИУ
должны функционировать специалисты по защите информации.
     В соответствии с данным принципом значительное распространение за рубежом получает
специализация по различным аспектам ЗИ. В США, например, на вопросах ЗИ специализируется
свыше 100 фирм.
     Принцип неформальности означает, что методология проектирования механизма защиты и
обеспечения его функционирования в основе своей является неформальной. Эта неформальность
интерпретируется в том смысле, что в настоящее время не существует инженерной методики
проектирования механизма защиты в традиционном понимании этого термина.
     Общие требования к механизму защиты следующие:
     1) адекватность, т.е. обеспечение требуемого уровня защиты (определяется степенью
секретности подлежащей обработке информации) при минимальных издержках на создание
механизма защиты и обеспечение его функционирования;
     2) удобство для пользователей, основу чего составляет требование, чтобы механизм защиты
не создавал для пользователей дополнительных трудностей, требующих значительных усилий для
их преодоления; минимизация привилегий в доступе, предоставляемых пользователям, т.е.
каждому пользователю должны предоставляться только действительно необходимые ему права по
                                               16
обращению к ресурсам системы и данным;
     3) полнота контроля, т.е. обязательный контроль всех обращений к защищаемым данным;
наказуемость нарушений, причем наиболее распространенной мерой наказания является отказ в
доступе к системе;
     4) экономичность механизма, т.е. обеспечение минимальности расходов на создание и
эксплуатацию механизма;
     5) несекретность проектирования, т.е. механизм защиты должен функционировать
достаточно эффективно даже в том случае, если его структура и содержание известны
злоумышленнику.
     В автоматизированных банках данных должно быть предусмотрено наличие в них средств
идентификации пользователей и ресурсов системы с периодической сменой идентифицирующей
информации, многоаспектного разграничения доступа к элементам баз данных (по элементам, по
разрешенным процедурам, по условиям операций и др.), криптографического закрытия данных,
регистрации обращений к защищаемым данным, контроля за использованием защищаемых
данных и т.д.
     Основные положения по разработке систем ЗИ могут быть сформулированы так:
     1) защита информации является не разовым мероприятием и даже не совокупностью
мероприятий, а непрерывным процессом, который должен протекать (осуществляться) во все
время и на всех этапах жизненного цикла АСОИУ;
     2) осуществление непрерывного процесса защиты информации возможно лишь на базе
промышленного производства средств защиты;
     3) создание     эффективных     механизмов    защиты     может     быть     осуществлено
высококвалифицированными специалистами-профессионалами в области защиты информации;
     4) поддержание и обеспечение надежного функционирования механизмов защиты
информации в АСОИУ сопряжено с решением специфических задач и поэтому может
осуществляться лишь профессионально подготовленными специалистами.
     Сохранность информации может быть нарушена в двух основных случаях: при получении
несанкционированного доступа к информации и нарушении функционирования ЭВМ. Система
защиты от этих угроз включает следующие основные элементы: защиту АСОИУ и ее аппаратуры,
организационные мероприятия по обеспечению сохранности информации, защиту операционной
системы, файлов, терминалов и каналов связи. Следует при этом иметь в виду, что все типы
защиты взаимосвязаны и при выполнении своих функций хотя бы одной из них сводит на нет
усилия других. Предлагаемые и реализованные схемы защиты информации в СОД очень
разнообразны, что вызвано в основном выбором наиболее удобного и легко осуществимого
метода контроля доступа, т.е. изменением функциональных свойств системы.
     В качестве классификационного признака для схем защиты можно выбрать их
функциональные свойства. На основе и этого признака выделяются системы: без схем защиты; с
полной защитой; с единой схемой защиты.

    9. Разработка пользовательского интерфейса.
      Проектирования интерфейса пользователя – сложная многофакторная и многовариантная
задача, требующая системного подхода. В настоящее время считается доказанным, что решение
данной задачи заключается не в том, чтобы рационально «вписать» человека в контур управления,
а в том, чтобы, исходя из задач управления объектом, разработать систему взаимодействия двух
равноправных партнеров (человек-оператор и аппаратно-программный комплекс АСОИУ).
      Цель создания эффективного эргономичного пользовательского интерфейса состоит в том,
чтобы отобразить информацию настолько эффективно насколько это возможно для человеческого
восприятия и структурировать отображение на дисплее таким образом, чтобы привлечь внимание
к наиболее важным единицам информации.
      Пользователь должен иметь возможность манипулировать объектами в среде приложения.
Неплохо, если они (графические элементы) будут ему понятны и станут нести в себе информацию
о том, что это такое и что произойдет, если выбрать или произвести действие над каким-то
объектом. Иллюстрация этой идеи – панель быстрого доступа Word'a. Что еще, кроме как
сохранение файла, можно ожидать от кнопки с изображением дискеты? Необходимо, чтобы

                                              17
пользователь имел наглядное средство отображения информации на различных этапах решения
задач, он должен видеть, как его действия влияют на объекты, расположенные на экране.
     Создание эффективного интерфейса заключается в быстром, насколько это возможно,
развитии у пользователей простой концептуальной модели интерфейса. Концепция
согласованности состоит в том, что при работе с компьютером у пользователя формируется
система ожидания одинаковых реакций на одинаковые действия, что постоянно подкрепляет
пользовательскую модель интерфейса.
     Приложение должно проектироваться таким образом, чтобы пользователь в любой момент и
на любом этапе работы мог получить помощь, контекстную справку или подсказку.
     Безусловно, пользователю нужно дать возможность экспериментировать в приложении
(нажатие любых кнопок, изменение настроек и т. д.). Но при этом необходимо избавить его от
тупиковых ситуаций: все последствия экспериментов должны быть исправимы, а в лучшем случае
еще и обратимы.
     Интерфейс должен предоставлять информацию о том, что происходит в данный момент на
компьютере. Нельзя допускать, чтобы пользователь долгое время ожидал реакции приложения на
некоторое свое действие.
     Цветовая гамма, компоновка элементов, пиктограммы, звуки, анимация – все должно
помогать пользователю при выполнении задачи. Но здесь важно не переборщить, т.к. в этом
случае внимание человека начнет рассеиваться, у него появится раздражение и, как следствие
снизится эффективность работы.
     Начальным этапом разработки пользовательского интерфейса являются создание его
ассоциативной модели, после чего осуществляется проработка концептуального дизайна. Здесь
необходимо разработать необходимый набор интерфейсных элементов, каждый из которых
должен обладать определенным цветом, формой, надписью и т. п., и все вместе они должны
составлять единую систему, вызывающую стойкую систему ассоциаций у пользователей.
     Цвет – мощный визуальный инструмент, который необходимо использовать очень
осторожно, чтобы не вызвать неадекватной реакции пользователя.
     Целесообразно ограничить число цветов до 4 на экране и до 7 для последовательности
экранов. Для неактивных элементов рекомендуется использовать бледные цвета. Необходимо
использовать цвета согласно представлениям пользователя. Например, для картографа зеленый
цвет – лес, желтый – пустыня, синий – вода. Если цвет используется для кодировки информации,
необходимо удостовериться, что код адекватно воспринимается пользователем: красный –
опасность/стоп, зеленый – нормально/продолжение работы, желтый – предостережение. Для
привлечения внимания наиболее эффективны белый, желтый и красный цвета.
     Меню необходимый элемент любой автоматизированной системы, позволяющий
пользователю выполнять задачи внутри приложения и управлять процессом решения.
Достоинство меню в том, что пользователи не должны помнить название элемента или действия,
которое они хотят выполнить – они должны только распознать его среди пунктов меню.
     Сообщения необходимы для направления пользователя в нужную сторону, подсказок и
предупреждений для выполнения необходимых действий на пути решения задачи. Они также
включают подтверждения действий со стороны пользователя и подтверждения, что задачи были
выполнены системой успешно либо по каким-то причинам не выполнены. Сообщения могут быть
обеспечены в форме диалога, экранных заставок и т.п.

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

                                              18
     Для распределенной обработки осуществляется сегментация прикладных программ.
Передача данных происходит при помощи удаленного вызова процедур либо электронной почты.
Первая технология характеризуется высоким быстродействием, а вторая – низкой стоимостью.
Известны также программные средства Системы Управления Распределенной Базой Данных
(СУРБД), содержатся инструментальные средства распределенной среды обработки данных.
     Распределенная среда обработки данных – представляет собой технологию распределенной
обработки данных.
     Эта среда обычно - набор сетевых служб, предназначенный для выполнения прикладных
процессов, рассредоточенных по группе абонентских систем гетерогенной сети. Основные ее
компоненты показаны в табл. 1.
                               Табл 1. Основные компоненты распределенной обработки данных.
 № Служба                                           Выполняемые функции
 п/п
  1. Имена                      База Данных имен пользователей и средств, предназначенных для
                                доступа пользователей к сетевым службам.
  2. Удаленный доступ           Технология, обеспечивающая взаимодействие двух прикладных
                                программ, расположенных в различных абонентских системах.
  3. Защита данных              Программное Обеспечение разрешения на доступ к ресурсам
                                системы или сети.
  4. Многопоточностъ            Программы, обеспечивающие одновременное выполнение
                                нескольких задач.

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


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

    11. Анализ и оценка производительности АСОИУ.
     Теоретические положения системного анализа определенное время рассматривались только
как некая философия инженера и поэтому при решении задач создания искусственных систем
иногда не учитывались. Однако развитие техники привело к тому, что без СА, одним из
результатов к-го явл-ся концептуальные модели, исследование функционирования систем
становится невозможным.
     Первоначально комп отождествлялся с центральным процессором, основной и понятной х-
кой были быстродействие, измеряемое числом команд в единицу времени. Поэтому современные
методики оценки отражают только возможности центрального процессора. В основе такой оценки
лежит понятие производительности. При этом выделяют так называемое «чистое» процессорное
время – период работы собственно процессора при выполнении внутренних операций и время
ответа, включающее выполнение операций ввода-вывода, работу ОС и т.д.
     Есть 2 показателя производительности процессов по «чистому» времени:
     1.показатель производительности процессоров на операциях с данными целочисленного типа
     MIPS – отношение числа команд в программе к времени ее выполнения
     2.показатель производительности процессоров на операциях с данными вещественного типа
     при все кажущейся простоте критерия оценки (чем > MIPS, тем быстрее выполняется
программа) его использование затруднено вследствие нескольких причин:
     1.процессоры разной архитектуры имеют различный набор команд
     2.применение матем-х сопроцессоров и оптимизирующих компиляторов увеличивает
     производительность системы, но рейтинг MIPS может уменьшится, т.к. время выполнения
команд для операций над данными с плавающей точкой значительно больше и за единицу
времени м.б. выполнено меньшее число команд, нежели при выполнении соответствующих этим
командам подпрограмм
     3.научные приложения в основном связаны с интенсивными вычислениями над
вещественными
     числами с плавающей точкой, коммерческие и офисные – с целочисленной арифметикой и
обработкой транзакций БД. Графические приложения критичны и к вычислительным мощностям,
и к параметрам графической подсистемы.
     Еще более сложные проблемы появляются при необходимости оценок многопроцессорных
систем. Такое положение привело к разработке и использованию ряда тестов, ориентированных на
оценку вычислительных систем с учетом специфики их предполагаемого использования. Поэтому
оценка процессоров с разной архитектурой основана на создании тестовой смеси из типовых
операторов, влияющих на их производительность.

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

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

     Как правило, универсальные системы календарного планирования обеспечивают следующий набор
функциональных возможностей:
     • средства визуального проектирования структуры работ проекта;
     • средства планирования по методу критического пути;
     • средства ресурсного планирования (описание, назначение и оптимизация загрузки ресурсов);
     • возможности стоимостного анализа;
     • средства контроля за ходом исполнения проекта;
     • средства создания отчетов и графических диаграмм;
     • средства организации групповой работы.
     Программное обеспечение для управления проектами традиционно разделяется на
профессиональные системы и системы для массового пользователя.
     Профессиональные системы предоставляют гибкие средства реализации функций планирования и
контроля, но требуют больших затрат времени на подготовку и анализ данных и соответственно
высокой квалификации пользователей. Системы для массового пользователя адресованы пользователям-
непрофессионалам, для которых управление проектами не является основным видом деятельности. От
пользователей, использующих пакеты планирования лишь время от времени при необходимости
спланировать небольшой комплекс работ или ввести фактические данные по проекту, нельзя ожидать
серьезных затрат времени и усилий на то, чтобы освоить и держать в памяти какие-либо
специфические функции планирования или оптимизации расписаний. Для них более важным является
простота использования и скорость получения результата.
     В настоящее время даже относительно дешевые системы способны поддерживать планирование
проектов, состоящих из десятков тысяч задач и использующих тысячи видов ресурсов. Основные
различия между системами проявляются в реализации функций ресурсного планирования и
многопроектного планирования и контроля. Возможности эффективного внедрения системы
управления проектами во многом зависят от возможностей настройки системы на специфические
показатели конкретных проектов, гибкости средств обмена данными, возможностей стандартизации
управленческой среды и обеспечения групповой работы с данными проекта.
     Microsoft Project и Time Line - недорогие системы управления проектами, просты в
использовании, доступны для новичков и непрофессионалов. Они содержат базовые возможности,
позволяющие осуществлять достаточно гибкое планирование и управление людскими ресурсами,
поддерживают несложное многопроектное планирование и контроль.
     Microsoft Project 98 - один из лидеров по возможностям объединения участников проекта
средствами электронной почты или Интранет. При описании ресурса для каждого исполнителя
может быть указан адрес его электронной почты. Информация о работах проекта может сохраняться
в формате HTML и публиковаться на внутреннем Web-сервере. Кроме стандартных форматов
файлов Microsoft Project (MPP и МРХ) пользователь может сохранять информацию о проекте в
форматах ODBC, Excel и Access. Формат MPD (Microsoft Project Database) позволяет хранить все
данные о проекте в структуре, доступной как из Microsoft Project 98, так и из Access.
     Что касается Time Line, то система позволяет хранить все данные, касающиеся проектов
организации, в единой базе данных. Отдельный модуль импорта/экспорта позволяет обмениваться
данными с другими системами (Microsoft Project, Time Line 1.0 for Windows), базами данных (dbf) и
электронными таблицами. Система Time Line 6.5 поддерживает стандарты ODBC, OLE 2.0, DDE и мак-
роязык Symantec Basic.
     Однако возможности недорогих систем, к которым относятся Microsoft Project и Time Line, не
позволяют в полной мере реализовать режим многопользовательской работы с информацией проекта,
поскольку не обеспечивают режим распределенного ввода данных и системы ограничения доступа к
данным.
     Open Plan Professional (Welcom Software) - представитель класса профессиональных систем.
Одним из основных отличий системы являются мощные средства ресурсного и стоимостного
планирования, которые позволяют значительно облегчить задачу нахождения наиболее
                                                21
эффективного распределения ресурсов и составления их рабочего расписания. Кроме того,
пользователями интегрированной системы управления проектами организации являются как
профессиональные менеджеры, осуществляющие согласование и оптимизацию планов проектов,
анализ рисков, прогнозирование и т.д., так и участники проектов, выполняющие сбор, уточнение и
актуализацию данных, готовящие отчеты. Если для профессионалов важны мощность и гибкость
предоставляемых системой функций планирования и анализа состояния проектов, то для остальных
пользователей важнее простота и прозрачность системы. Open Plan обеспечивает как полную
интеграцию между профессиональной и настольной версиями системы, так и открытость для
обмена данными с внешними приложениями.
      Open Plan поставляется в двух вариантах (Professional и Desktop), каждый из которых отвечает
различным потребностям исполнителей, менеджеров и других участников проекта. Обе версии
работают с одной базой данных. Совместное использование профессиональной и "облегченной"
версий системы управления проектами дает возможность не только учесть потребности всех групп
пользователей, но и значительно снизить стоимость решения.
      Open Plan обладает прямым доступом к базам данных. Пользователь может выбрать, в каком
формате хранить данные по проектам (в собственном формате Open Plan, в форматах Oracle, SQL Serv-
er, Sybase, xBase).
      Open Plan обеспечивает ограничение доступа к данным проекта, предоставляя различные права на
доступ к определенным данным, делая их доступными ограниченному кругу лиц и регулируя их
совместное использование. Средство "Директор управления проектами", встроенное в Open Plan,
позволяет упорядочить применение стандартных элементов проектов и процедур. В Open Plan
предлагается 65 моделей, построенных на базе руководств PMI (Project Management Institute -
Институт проектного менеджмента, США), которые можно настроить для создания документов,
отвечающих требованиям стандартов ISO.

   13. Проектная документация АСОИУ. Требования ГОСТов к
документации, содержание документации.
       Стадии создания
       Стандарт распространяется на автоматизированные системы (АС), используемые в
различных видах деятельности (исследование, проектирование, управление и т.п.), включая их
сочетания, создаваемые в организациях, объединениях и на предприятиях (далее организациях).
Стандарт устанавливает стадии и этапы создания АС, а также содержание работ на каждом этапе.
       Процесс создания АС представляет собой совокупность упорядоченных во времени,
взаимосвязанных, объединенных в стадии и этапы работ, выполнение которых необходимо и
достаточно для создания АС, соответствующей заданным требованиям. Стадии и этапы создания
АС в общем случае:
       1. Формирование требований к АС
       2. Разработка концепции АС
       3. Техническое задание
       4. Эскизный проект
       5. Технический проект
       6. Рабочая документация
       7. Ввод в действие
       8. Сопровождение АС
       Допускается исключать стадию "Эскизный проект" и отдельные этапы работ на всех стадиях,
объединять стадии "Технический проект" и "Рабочая документация" в одну стадию
"Технорабочий проект". В зависимости от специфики создаваемых АС и условий их создания
допускается выполнять отдельные этапы работ до завершения предшествующих стадий,
параллельное во времени выполнение этапов работ, включение новых этапов работ.
       Требования к содержанию документов
       Настоящие методические указания распространяются на автоматизированные системы (АС),
используемые в различных сферах деятельности (управление, исследование, проектирование и
т.п.), включая их сочетание, и устанавливают требования к содержанию документов,
разрабатываемых при создании АС.

                                                 22
     Содержание документов является общим для всех видов АС и, при необходимости, может
дополняться разработчиком документов в зависимости от особенностей создаваемой АС.
Допускается включать в документы дополнительные разделы и сведения, объединять и исключать
разделы. Содержание каждого документа определяет разработчик в зависимости от объекта
проектирования (системы, подсистема и т.д.).
     1. Пояснительные записки к эскизному, техническому проектам содержат разделы: общие
положения; описание процесса деятельности; основные технические решения; мероприятия по
подготовке объекта автоматизации к вводу системы в действие.
     2. Схема функциональной структуры содержит:
      элементы функциональной структуры АС (подсистемы АС); автоматизированные функции
и/или задачи (комплексы задач); совокупности действий (операций), выполняемых при реализации
автоматизированных функций только техническими средствами (автоматически) или только
человеком;
      информационные связи между элементами и с внешней средой с кратким указанием
содержания сообщений и/или сигналов, передаваемых по связям, и при необходимости, связи
других типов (входимости, подчинения и т. д.);
      детализированные схемы частей функциональной структуры (при необходимости).
     3. Описание автоматизируемых функций содержит разделы: исходные данные; цели АС и
автоматизированные функции; характеристика функциональной структуры; типовые решения
(при наличии).
     4. Описание постановки задачи (комплекса задач) содержит разделы: характеристики
комплекса задач; выходная информация; входная информация.
     5. Общее описание системы содержит разделы: назначение системы; описание системы;
описание взаимосвязей АС с другими системами; описание подсистем (при необходимости).
     6. Программа и методика испытаний должна содержать перечни конкретных проверок
(решаемых задач), которые следует осуществлять при испытаниях для подтверждения выполнения
требований ТЗ, со ссылками на соответствующие методики (разделы методик) испытаний.
Перечень проверок, подлежащих включению в программу испытаний, включает: соответствие
системы ТЗ; комплектность системы; комплектность и качество документации; комплектность,
достаточность состава и качество программных средств и программной документации; количество
и квалификация обслуживающего персонала; степень выполнения требований функционального
назначения системы; контролепригодность системы; выполнение требований техники
безопасности, противопожарной безопасности, промышленной санитарии, эргономики;
функционирование системы с применением программных средств.
     Программа испытаний содержит разделы: объект испытаний; цель испытаний; общие
положения; объем испытаний; условия и порядок проведения испытаний; материально-
техническое обеспечение испытаний; метрологическое обеспечение испытаний; отчетность.
     7. Схема организационной структуры содержит:
      состав подразделений (должностных лиц) организации, обеспечивающих
функционирование АС либо использующих при принятии решения информацию, полученную от
АС;
      основные функции и связи между подразделениями и отдельными должностными лицами,
указанными на схеме, и их подчиненность.
     8. Описание организационной структуры содержит разделы: изменения в
организационной структуре управления объектом; организация подразделений; реорганизация
существующих подразделений управления
     9. Методика автоматизированного проектирования содержит разделы: общие положения;
постановка задачи; методика проектирования; исходные данные; проектные процедуры; оценка
результатов.
     10. Перечень входных сигналов и данных содержит разделы: перечень входных сигналов;
перечень входных данных.
     11. Перечень выходных сигналов (документов) содержит разделы: перечень выходных
сигналов; перечень выходных документов.
     12. Описание информационного обеспечения системы содержит разделы: состав
информационного обеспечения; организация информационного обеспечения; организация сбора и
                                              23
передачи информации; построение системы классификации и кодирования; организация
внутримашинной информационной базы; организация внемашинной информационной базы.
     13. Описание организации информационной базы содержит описание логической и
физической структуры базы данных и состоит из двух частей: описание внутримашинной
информационной базы; описание внемашинной информационной базы. Части документа содержат
следующие разделы: логическая структура; физическая структура (для внутримашинной
информационной базы); организация ведения информационной базы. В разделе "Логическая
структура" приводят описание состава данных, их форматов и взаимосвязей между данными. В
разделе "Физическая структура" приводят описание избранного варианта расположения данных на
конкретных машинных носителях.
     14. Описание систем классификации и кодирования содержит перечень применяемых в
АС зарегистрированных классификаторов всех категорий по каждому классифицируемому
объекту, описание метода кодирования, структуры и длины кода, указания о системе
классификации и другие сведения по усмотрению разработчика.
     15. Описание массива информации содержит: наименование массива; обозначение
массива; наименование носителей информации; перечень реквизитов в порядке их следования в
записях массива с указанием по каждому реквизиту: обозначения алфавита, длины в знаках и
диапазона изменения (при необходимости), логических и семантических связей с другими
реквизитами данной записи и другими записями массива; оценку объема массива; другие
характеристики массива (при необходимости).
    Документация по проекту:
     Полный пакет включает следующие: пояснительная записка схема функциональной
структуры; общее описание системы; описание автоматизируемых функций; описание постановки
задачи; описание информационного обеспечения системы; описание организации инфо базы;
перечень входных сигналов и данных; перечень выходных сигналов/документов; описание ПО;
техническое задание; описание программы; пояснительная записка; программа и методика
испытаний.

    14. Инструментальные средства проектирования АСОИУ.
      Для реализации программных проектов ЛАНИТ использует широкий спектр современных
инструментальных средств:
       CASE-средства - позволяющие значительно сократить сроки проектирования (за счет его
организации в форме последовательной формализации и детализации знаний о проектируемой
системе) и повысить качество проекта (за счет его представления в виде целостной модели,
описывающей псе стороны функционирования автоматизируемого объекта); Westmount I-CASE
фирмы CADRE, CASE/4/0 фирмы MICROTOOL, S-Dcsiirnor фирмы SYBASE (POWERSOFT).
SilverRun фирмы CSA и др.
       4С1-средства проектирования многоплатформенных приложений -позволяющие в
минимальные сроки создавать прикладные программы, работающие практически на любых
программно-аппаратных платформах: UNIFACE фирмы COMPUWARE, PowerBuilder фирмы
SYBASE (POWERSOFT), Delphi фирмы BORLAND, JАМ фирмы IYACC и др.,
       монитор транзакций TUXEDO фирмы BFA SYSTEMS для проектирования критически
важных приложений реального времени (например, в банковской сфере),
       Internet / Intranet - средства проектирования: фирм ORACLE, NOVELL, MICROSOFT.
BORLAND,
       системы управления базами данных: фирм ORACLE, INFORMIX, SYBASE, MICROSOFT,
BTRIEVE,
       средства тестирования программного обеспечения, администрирования вычислительной
среды и поддержки работы приложений (фирмы COMPUWARE),
       технологические решения третьих фирм, которые встраиваются в проект системы и
значительно сокращают трудоемкость проектирования, повышают качество проекта: системы
работы с изображениями, средства обеспечения коллективной работы, системы электронной
почты и т. д.


                                             24
     ЛАНИТ имеет официальные отношения с фирмами–производителями соответствующих
инструментальных средств, являясь дистрибьютором и бизнес-партнером фирм BEASYSTEMS,


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




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

                                              25
     Данный подход предполагает разработку АСОИП собственными силами, без привлечения
сторонних организаций и приобретения тиражируемого прикладного программного обеспечения.
Исторически это первый из сложившихся подходов к построению систем автоматизации учета и
управления. Он, разумеется, имеет право на существование и сегодня; и на первый взгляд даже
является достаточно заманчивым для руководства ряда предприятий, имеющих в штате
программистов. Однако использование этого подхода для большинства предприятий в
перспективе может привести к бесполезной трате времени и средств. Позволим себе привести
следующий пример.
     Государственное предприятие прошло этап акционирования и в той или иной степени
перепрофилировало область деятельности. На смену наукоемким технологиям пришел выпуск
несложной в техническом плане продукции, пользующейся спросом на рынке (например, вместо
координатных устройств ввода для оцифровки картографической информации выпускаются
кассовые окна и лотки для пунктов обмена валюты). Объемы производства и сбыта растут, однако
постепенно возрастает и конкуренция, встает вопрос о повышении эффективности управления для
снижения издержек и себестоимости продукции. В этом случае аргументом, выдвигаемым
руководителем в пользу самостоятельной разработки АСОИП, часто может являться, например,
следующее соображение: незачем тратить деньги на приобретение программ и услуги сторонних
организаций, когда у нас есть свои программисты, которые и так получают зарплату (и которых
иногда просто нечем занять!). Руководитель этих программистов часто поддерживает такое
мнение руководства, поскольку заинтересован в получении длительного источника
финансирования своего коллектива, и заявляет, что в состоянии построить АСОИП, полностью
удовлетворяющую особенностям предприятия. В результате коллектив, который до этого вполне
успешно занимался, например, разработкой программ для микропроцессорных систем управления
прецизионным оборудованием, прочитав несколько книжек, принимается за создание АСОИП.
Это один из самых ярких примеров неудачного подхода к созданию АСОИП, поскольку
результаты подобной работы на 99% будут «выброшены в корзину» из-за отсутствия
необходимого уровня квалификации и опыта разработки.
     Некоторые читатели могут возразить, что в приведенном примере отражен некий
«вырожденный случай» и аргументами в пользу самостоятельной разработки могут служить, в
частности, недостаточные качество и надежность тиражируемых средств. Однако в любом случае
вы должны учитывать следующие недостатки этого подхода. Разрабатывающие систему
сотрудники будут оторваны от своих прямых обязанностей по эксплуатации уже
функционирующих программ, проект может сорваться из-за ухода одного-двух ведущих
специалистов или нехватки сил для построения действительно мощной системы (практика
показывает, что для создания АСОИП, отвечающей современным требованиям, необходимы
десятки и сотни человеко-лет).
     Здесь нельзя не отметить еще одно обстоятельство. При самостоятельной разработке
системы часто (явно или неявно) имеется ввиду ее дальнейшее коммерческое распространение.
Нужно сразу сказать, что в сегодняшних условиях подобные надежды вряд ли имеют основания.
Слишком велика в настоящее время конкуренция и требования к качеству систем, чтобы рядовая
«доморощенная» система имела реальные шансы на коммерческий успех.
     Мы позволим себе выразить мнение, что для предприятий, рассматриваемых в этой книге,
все соображения по возможной экономии средств, полного соответствия создаваемой системы
особенностям бизнеса и пр. при самостоятельной разработке АСОИП являются мифом. В
большинстве случаев для этих предприятий такой подход будет наиболее дорогим, длительным по
срокам реализации и рискованным в смысле достижения поставленных целей.
     Потенциально эффективным этот подход может быть для крупных предприятий, имеющих
большой коллектив разработчиков, уже обладающих опытом разработки и внедрения
комплексных систем автоматизации.
                                        Заказные системы
     При данном подходе вы заказываете разработку АСОИП, как, например, заказывают
нестандартную мебель. Это второй исторически сложившийся подход к построению АСОИП. В
«чистом виде» он предполагает разработку системы, полностью соответствующей особенностям
конкретного предприятия, что и является его основным преимуществом. В потенциале этот


                                              26
подход характеризуется сравнительно меньшей стоимостью и меньшими сроками реализации, чем
самостоятельная разработка.
     В современных условиях при выборе этого подхода мы рекомендуем вам учитывать
следующие его технологические и организационные особенности.
     С технологической точки зрения наивно полагать, что разработчики будут создавать
заказанную вами систему действительно «с нуля» (а если вдруг и будут, то это явный путь к
провалу проекта). У них наверняка есть заранее наработанные решения, которые будут
адаптироваться к вашим требованиям. Таким образом, во многих случаях сегодня «заказная»
разработка фактически сводится к неявному использованию тиражируемых систем, которые
имеются в распоряжении исполнителя. Результат разработки в этот случае во многом будет
определяться качеством этих систем. Поэтому прежде чем остановиться на данном подходе имеет
смысл внимательно познакомиться с возможностями построения АСОИП с явным применением
тиражируемых средств, поскольку эти варианты могут быть дешевле при той же
функциональности и надежнее в связи с применением широко апробированных решений.
     С организационной точки зрения этот подход может быть реализован двумя способами:
создание временного коллектива разработчиков на вашем предприятии путем привлечения
специалистов со стороны и заключение договора со специализированной фирмой. Несмотря на то
что первый способ может оказаться существенно дешевле (программистов, ищущих
дополнительные заработки, в России хватает), мы настоятельно не рекомендуем его использовать.
После окончания разработки (даже при ее успешном завершении) вы скорее всего останетесь с
системой «один на один», поскольку созданный временный коллектив может распасться или
заняться другими (например, более выгодными для него материально) делами. Можно, конечно,
иметь в виду создание этим коллективом на основе вашей системы тиражируемого продукта и
последующее участие вашей фирмы в его продажах. Но это уже тема для совсем другого
разговора.
     В целом с учетом высказанных выше соображений использование подхода с разработкой
заказных АСОИП можно рекомендовать предприятиям с действительно уникальными
особенностями бизнеса.
                             Тиражируемые (коробочные) продукты
     При использовании этого подхода вы приобретаете программы автоматизации различных
видов хозяйственного учета так же, как например, офисные программы или компьютерные игры.
В ряде случаев программы поставляются в красочно оформленной упаковке (коробке), откуда,
собственно, и пошло их название. В комплект поставки входит более или менее подробная
инструкция по установке и эксплуатации программы, пользуясь которой в большинстве случаев
можно достаточно быстро ввести эту программу в эксплуатацию.
     Основными преимуществами подобного подхода являются сравнительно низкая стоимость
программ, простота и, соответственно, небольшие сроки их освоения и, в ряде случаев, хороший
сервис по сопровождению обновления версий программного обеспечения. Кроме того, продукты
ведущих фирм тиражируются в больших количествах, следовательно можно ожидать, что они
хорошо апробированы и не содержат часто проявляющихся ошибок.
     Единственным недостатком такого подхода является то, что собственно АСОИП с его
помощью практически создать не удается. Это объясняется недостаточной функциональностью и
масштабом «коробочных» продуктов, а также проблемами совместимости систем различных
производителей.
     Использование коробочных продуктов целесообразно для малых предприятий и на средних
предприятиях на начальных стадиях автоматизации финансово-хозяйственной деятельности.
                            Адаптируемые интегрированные системы
     Подход к построению АСОИП с применением адаптируемых интегрированных систем,
которые, как мы уже говорили, появились на российском рынке во второй половине 90-х годов,
удачно сочетает ряд преимуществ уже рассмотренных нами подходов и свободен от их основных
недостатков. Это, на первый взгляд, не совсем очевидное обстоятельство объясняется
особенностями построения адаптируемых интегрированных систем, которые, если не вдаваться в
технические подробности, состоят в следующем.
     Во-первых, как мы уже отмечали в обзоре развития систем автоматизации, основу
адаптируемой интегрированной системы составляет тщательно проработанное и предназначенное
                                              27
для тиражирования программное ядро. Это ядро изначально функционально ориентировано на
возможность обеспечения комплексной автоматизации управленческого и других видов учета,
данные которых необходимы в АСОИП. Таким образом наличие этого ядра с одной стороны в
потенциале обеспечивает интегрированным системам такие преимущества тиражируемых систем,
как использование апробированных решений и, с другой – устраняет недостаточный уровень
функциональности и проблемы совместимости «коробочных» продуктов.
     Во-вторых, адаптируемые интегрированные системы содержат гибкие средства настройки
характеристик и возможностей создаваемой АСОИП на особенности бизнеса конкретной
организации. Поэтому при таком подходе к разработке АСОИП появляется возможность
удовлетворения требований заказчика, как это характерно для самостоятельно разрабатываемых
или заказных систем, но сроки и риск неудачного выполнения работ здесь могут быть
существенно сокращены за счет использования апробированного тиражируемого ядра.
     В результате, АСОИП, построенные с использованием этого подхода отличаются
сравнительно небольшим временем разработки, эффективностью решения задач автоматизации
управления и сравнительной простотой модификации при изменении организационной структуры
предприятия или существующих бизнес-процессов.
     Отмеченные преимущества подхода к построению АСОИП с применением адаптируемых
интегрированных систем позволяют рекомендовать его использование большинству из
рассматриваемого в книге вида предприятий.
     Как видно из приведенной выше схемы, адаптация интегрированной системы в принципе
может производиться как силами заказчика, так и силами сторонней фирмы. Далеко не все из
рассматриваемых в книге предприятий обладают специалистами, квалификация которых
позволяет самостоятельно провести адаптацию, поскольку, как мы увидим ниже, это достаточно
емкий процесс, в котором необходимо учитывать целый ряд факторов. В рамках данного подхода
для большинства из рассматриваемых в книге предприятий можно рекомендовать использование
адаптируемых интегрированных систем с настройкой разработчиком или третьей (но обязательно
специализированной) фирмой. Особенности построения АСОИП на основе адаптируемых
интегрированных систем мы рассмотрим в следующем разделе.
      Адаптируемые интегрированные системы как платформа современных комплексных
                                   систем автоматизации
     Разработка АСОИП на базе адаптируемых интегрированных систем ведется, как правило, на
основе соответствующего договора между заказчиком и исполнителем. Содержание этих
договоров при работе с различными поставщиками систем может, естественно, быть достаточно
разнообразным. Однако практика показывает, что процесс создания АСОИП на базе
адаптируемых интегрированных систем в общем случае включает в себя несколько этапов.
     Заключение договора. Это очень важный и ответственный этап, который в ряде случаев
может определить успех или неудачу всей дальнейшей работы.
     Обследование предприятия. Целью обследования является получение материалов для оценки
эффективности управленческо-организационных механизмов компании, способов ведения работ,
выполнения бизнес-процессов, принятых в конкретной компании, принятых схем учёта,
используемой информации для принятия решений, т.е. общей технологии работы.
     Проектирование модели бизнеса. Строится модель функционирования компании в том виде,
в каком этот процесс должен быть после устранения проблем, обнаруженных на этапе
обследования.
     Консультации. Несмотря на то, что этот этап выделен у нас отдельным пунктом,
консультации могут осуществляться на протяжении всего проекта, параллельно с другими
работами, например, по вопросам постановки управленческого и других видов учета,
минимизации налогообложения, юридическо-правовым нормам и т.п.
     Настройка автоматизированной системы на модель бизнеса. На этом этапе происходит
собственно адаптация интегрированной системы исходя из построенной модели бизнеса. Работа
здесь выполняется в основном исполнителем. Заказчик может использовать это время для
реорганизации управления в соответствии с построенной моделью бизнеса.
     Технологическое внедрение. На этом этапе проводится установка у заказчика необходимого
оборудования и соответствующих программ. Этап для крупных проектов может выполняться
последовательно. Здесь же проводятся обучение пользователей работе с новой системой и ее
                                             28
опытная эксплуатация, по результатам которой могут вноситься определенные изменения в
настройки системы. Этап завершается передачей системы в плановую эксплуатацию с
оформлением соответствующих документов.
     Сопровождение и развитие. В зависимости от условий договора на создание системы могут
осуществляться необходимые консультации, поставка обновленных версий программных
модулей, разработка при необходимости, новых функциональных модулей и т. д.
     Отметим, что у различных поставщиков адаптируемых интегрированных систем
наименования этапов и состав работ на этих этапах могут отличаться от приведенных выше.
Однако суть дела при этом не меняется, хотя вопрос о полноте оказываемых исполнителем услуг
при создании АСОИП в практическом плане является весьма важным.

   16. Графические средства представления проектных
решений АСОИУ (IDEF, DFD, UML, ERD и т.д.)
     Графические средства моделирования предметной области позволяют разработчикам в
наглядном виде изучать существующую АСОИУ, перестраивать ее в соответствии с
поставленными целями и имеющимися ограничениями.
     CASE-средства обладают следующими основными особенностями :
     а) имеют мощные графические средства для описания и документирования АСОИУ,
обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие
возможности;
     б) осуществляют интеграцию отдельных компонент CASE-средств, обеспечивающую
управляемость процессом разработки систем;
     в) используют специальным образом организованное хранилище проектных метаданных
(репозитория).
     Интегрированное CASE-средство должно содержать следующие компоненты:
     а) репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение
версий проекта и его отдельных компонентов, синхронизацию поступления информации от
различных разработчиков при групповой разработке, контроль метаданных на полноту и
непротиворечивость;
     б) графические средства анализа и проектирования, обеспечивающие создание и ре-
дактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели АСОИУ;
     в) средства разработки приложений, включая языки 4GL и генераторы кодов;
     г) средства конфигурационного управления;
     д) средства документирования;
     е) средства тестирования;
     ж) средства управления проектом;
     з) средства реинжиниринга.
     Современный рынок программных средств насчитывает около 300 различных CASE-средств,
наиболее мощные из которых используются практически всеми ведущими западными фирмами.
     Все современные CASE-средства могут быть классифицированы в основном по типам и
категориям. Классификация по типам отражает функциональную их ориентацию на те или иные
процессы ЖЦ.
     Классификация по категориям определяет степень интегрированности по выполняемым
функциям и включает следующее :
     а) отдельные локальные средства, решающие небольшие автономные задачи (tools);
     б) набор частично интегрированных средств, охватывающих большинство этапов
жизненного цикла систем (toolkit);
     в) полностью интегрированные средства, поддерживающие весь ЖЦ систем и связанные
общим репозиторием.
     Помимо этого CASE-средства можно классифицировать по следующим признакам:
     а) применяемым методологиям и моделям систем и БД;
     б) степени интегрированности с СУБД;
     в) доступным платформам.
     Классификация по типам в основном совпадает с компонентным составом CASE-средств.

                                             29
     На сегодняшний день российский рынок программного обеспечения располагает
следующими наиболее развитыми CASE-средствами: Vantage Team Builder (Westmount I-CASE),
Designer/2000, Silverrun, ERwin+Bpwin, S-Designor, CASE-Аналитик, CASE /4/0, PRO-IV, System
Architect, Visible Analyst Workbench, EasyCASE; VIS; RATIONAL ROSE.
     DFD- диаграммы потоков данных являются основным средством моделирования
функциональных требований к проектируемой системе. С их помощью эти требования
представляются в виде иерархии процессов, связанных потоками данных. Главная цель
представления – продемонстрировать, как каждый процесс преобразует свои входные данные в
выходные, а также выявить отношения между этими процессами. Модель системы определяется
как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования
информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней
иерархии определяют основные процессы с внешними входами и выходами. Они детализируются
при помощи диаграмм нижнего уровня.
     Основные компоненты: внешние сущности, системы и подсистемы, процессы, накопители
данных, потоки данных.
     Внешняя сущность – материальный объект или физическое лицо, представляющее собой
источник или приемник информации. Внешняя сущность обозначается квадратом,
расположенным над диаграммой и бросающим на нее тень.
     Процесс преобразования входных потоков данных в выходные. Номер процесса служит для
его идентификации. В поле имени вводится наименование процесса (вычислить информацию,
рассчитать поступление денег). Информация в поле физической реализации показывает, какое
подразделение организации, программа, аппаратное устройство выполняет данный процесс.
     Накопитель данных – абстрактное устройство для хранения информации, которую можно
извлечь. Накопитель данных на диаграмме идентифицируется буквой D и произвольным числом.
Имя накопителя выбирается из соображений информативности.
     Поток данных определяет информацию, передаваемую через некоторое соединение от
источника к приемнику. Он изображается линией, оканчивающейся стрелкой которая показывает
направление потока. Каждый поток имеет имя, отражающий его содержание.
     ERD – данная нотация используется в CASE средстве Oracle Designer.
     Первый шаг моделирования – извлечение информации из интервью и выделение сущностей.
     Второй шаг моделирования – идентификация связей. Связь это ассоциация между
сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным
количеством экземпляров, а каждый экземпляр сущности-потомка ассоциирован в точности с
одним экземпляром сущности родителя. Имя связи между двумя сущностями должно быть
уникальным. Имена связи модели недолжны, быть уникальны. Имя связи формируется с точки
зрения родителя. Степень и обязательность связи можно показать графически.
     Третий шаг – идентификация атрибута. Атрибут может быть либо обязательным, либо не
обязательным. Каждый атрибут идентифицируется уникальным номером и изображается в виде
списка имен внутри блока ассоциированной сущности, причем каждый атрибут занимает
отдельную строчку. Каждая сущность обладает хотя бы одним возможным ключом.
     Возможный ключ – один или несколько атрибутов, чьи значенья однозначно определяют
каждый экземпляр сущности.
     Супертипы и подтипы: одна сущность является обобщающим понятием для группы
подобных сущностей.
     Взаимно исключающие связи: каждый экземпляр сущности участвует только в одной связи
из группы взаимно исключающих связей.
     Рекурсивная связь – сущность может быть связана сама с собой.
     Неперемещаемые связи – экземпляр сущность не может быть перенесен из одного
экземпляра связи в другой.
     UML - - приемник того поколения методов объектно-ориентированного анализа и
проектирования, которые появились в конце 80-х и начале 90-х годов. UML-является прямым
объединением и унификацией методов Буча, Рамбо, Якобсона. Язык UML находится в процессе
стандартизации, проводимом OMG – организацией по стандартизации в области ОО методов и
технологий, в настоящее время принят в качестве стандартного языка моделирования и получил
широкую поддержку в индустрии ПО. Создатели UML представляют его как язык для
                                             30
определения, представления, проектирования и документирования программных систем,
организационно-экономических и других. UML содержит стандартный набор диаграмм и нотаций:
диаграммы вариантов использования (для моделирования бизнес-процессов организации –
требования к системе), классов (для моделирования статической структуры классов системы и
связи между ними), поведения системы, взаимодействия (для моделирования процесса обмена
сообщениями между объектами), состояния (для моделирования поведения объектов системы при
переходе из одного состояния в другое), деятельности (для моделирования поведения системы в
рамках различных вариантов использования или моделирования деятельности ).
     IDEF0 - диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них
представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса.
Управляющая информация входит в блок сверху, в то время как информация, которая
подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой
стороны. Механизм (человек или автоматизированная система), который осуществляет операцию,
представляется дугой, входящей в блок снизу. Одной из наиболее важных особенностей
методологии SADT является постепенное введение все больших уровней детализации по мере
создания диаграмм, отображающих модель. Построение SADT-модели начинается с
представления всей системы в виде простейшей компоненты - одного блока и дуг, изображающих
интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему
как единое целое, имя, указанное в блоке, является общим. Затем блок, который представляет
систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких
блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции
исходной функции. Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня,
являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие
из нее, потому что блок и диаграмма представляют одну и ту же часть системы. Каждый блок на
диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой
нижнего уровня, которая, в свою очередь, может быть далее детализирована с помощью
необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм. Для того, чтобы
указать положение любой диаграммы ли блока в иерархии, используются номера диаграмм.
Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2.

    17. Распределенная обработка данных.
     Распределенная обработка данных – методика выполнения прикладных программ группой
систем.
     Сущность ее заключается в том, что пользователь получает возможность работать с
сетевыми службами и прикладными процессами, расположенными в нескольких взаимосвязанных
абонентских системах. При этом возможны несколько видов работ, которые он может выполнять:
удаленный запрос, например, команда, позволяющая посылать одиночную заявку на выполнение
обработки данных; удаленная трансакция, осуществляющая направление группы запросов
прикладному процессу; распределенная трансакция, дающая возможность использования
нескольких серверов и прикладных процессов, выполняемых в группе абонентских систем.
     Для распределенной обработки осуществляется сегментация прикладных программ.
Передача данных происходит при помощи удаленного вызова процедур либо электронной почты.
Первая технология характеризуется высоким быстродействием, а вторая – низкой стоимостью.
Известны также программные средства Системы Управления Распределенной Базой Данных
(СУРБД), содержатся инструментальные средства распределенной среды обработки данных.
     Распределенная среда обработки данных – представляет собой технологию распределенной
обработки данных.
     Эта среда обычно - набор сетевых служб, предназначенный для выполнения прикладных
процессов, рассредоточенных по группе абонентских систем гетерогенной сети. Основные ее
компоненты показаны в табл. 1.
                               Табл 1. Основные компоненты распределенной обработки данных.
 № Служба                                           Выполняемые функции
 п/п
  1. Имена                      База Данных имен пользователей и средств, предназначенных для
                                доступа пользователей к сетевым службам.
                                                31
 2. Удаленный доступ           Технология, обеспечивающая взаимодействие двух прикладных
                               программ, расположенных в различных абонентских системах.
 3. Защита данных              Программное Обеспечение разрешения на доступ к ресурсам
                               системы или сети.
 4. Многопоточностъ            Программы, обеспечивающие одновременное выполнение
                               нескольких задач.
     Системы, имеющие программы распределенной среды, соответственно, являются серверами
и клиентами. Серверы связаны (рис. 1) друг с другом логическими каналами, по которым
передают друг другу файлы. Каждый сервер имеет свою группу клиентов.
                 Сервер       Логический
                              канал




    Рис. 1. Связь серверов

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




                                             32
   18. Системное проектирование Программных систем на
основе стандартизации.
     Непрерывный рост масштабов проектов информационных систем и их необозримые для
отдельных     специалистов     привели     к   изменению    отношения  регламентирования,
документированию и дисциплине труда коллективов специалистов при обеспечении ЖЦ
программных средств. (ЖЦ ПС).
     Накопленный мировой опыт обобщен международных национальных и военных стандартах,
которые почти неизвестны отечественным специалистам.
     За рубежом         требования стандартов является обязательным, и определяют
конкурентоспособность продукции.
     Состояние и развитие стандартизации в области ИС характеризуется следующими
особенностями:
     1. Несколько сотен международных и национальных стандартов (зарубежных) не полностью
и неравномерно покрывают потребности в стандартизации информационных систем и компонент.
     2. Большая длительность разработки международных и национальных стандартов от 3 до 5
лет приводит к консерватизму.
     3. Стандартизация современных ИС должны учитывать требования открытых систем и
обеспечить:
     - их распределяемость при наращивании и применении функций.
     - переносимость между разными аппаратными платформами.
     - возможность взаимодействия с другими ИС.
     4. Наиболее сложные творческие процессы создания и развития крупных и распределенных
ИС системный анализ и проектирование, интеграция компонента и систем, испытание и
сертификация почти не поддержание требованиями и рекомендации стандартов.
     5. Чем сложнее объекты и процессы, тем больше необходимых формулирование
предварительных условий которые следует адаптировать и конкретизировать применение в
проекте.
     6. Пробелы и задержки подготовки и издания стандартов приводят к созданию
многочисленных нормативов, методических материалов, отраслевого, ведомственного и
фирменного уровня.
     7. Последующие совершенствования и согласование нормативных документов в ряде
случаев позволить создать на их основе и международных стандартов.

     Основные цели применения стандартов.
     1. Снижение трудоемкости стоимости, длительности и улучшение других тех.-эконом.
показателей проектов ИС.
     2. Повышение качества разрабатываемых текущих компонентов ИС и ИС в целом при
разработке, применении и эксплуатации.
     3. Обеспечение расширяемости ИС и масштабируемости.
     4. Поддержка функций интеграции в ИС задач ранее решавшихся задач.
     5. Обеспечение переносимости прикладных программ между разными стандартно –
программных платформ.

     Группы специалистов, пользователей стандартов:
     1. Руководители проекта и крупных компаний.
     2. Системные аналитики – создание пилотных проектов и алгоритмов решения задач.
     3. Программисты и разработчики.
     4. Интеграторы.
     5. Испытатели и сертификаторы.
     6. Разработки технологии инструментальных средств обеспечение ЖЦ программной
системе.
     В России создание и испытание АС регламентирующих следующими стандартами:
     1. ГОСТ 28195-89 – оценки качества ЛС общее положение.
     2. ГОСТ 28806-90 – качество программных средств. Термины и определения.

                                            33
     3. ГОСТ 34.601-90 – информационная технология. АС. Стадия создания.
     4. ГОСТ 34.201-89 – информационная технология. Виды, комплексность и обозначение
документов при создании АС.
     5. ГОСТ 34.602-89 – информационная технология и ТехЗадания АС.
     6. ГОСТ 34.603-92 – информационная технология. Виды испытания АС.
     7. РД 50-34.698-90 – методические указания. Информационная технология, АС, требования
и содержанию документов.
     Создание и развитие ПС для современных ИС для этих стандартов отображения не
достаточно, а многие их положения устарели, но эти стандарты часто используются.
     В отечественных      разработках целесообразно использовать и выбирать зарубежные
стандарты в этой области основные совр-е зарубежные стандарты ЖЦ ориентированы на сложным
программные системы обращенные информации и управления в реальном режиме времени. Таким
программным системам представляется, наиболее высокие требования к качеству
функционирования. Они создаются большим количеством специалистов в течение длительного
времени.
     Формирование проектов профилей, стандартов при системном проектировании.
     При создании и развитии сложных ПС требуется гибкое формирование и применения
гармонизирующих совокупностей базовых стандартов и нормативных документов разного уровня,
выделения в них требований и рекомендаций необходимых для реализации задач функций ИС.
     Профиль – это совокупность нескольких базовых стандартов с четко определенными и
гармонизированными подмножествами, обязательными факультативных возможностей
представленная для реализации заданной функции или группы функций.
     Стандарты важные для системы должны задаваться в ТЗ на систем. Проект ИС и составляет
ее первичный профиль.
     Целесообразно рассматривать группы профилей.
     1. Профили регламентирует архитектуру и структуру ИС и ее компоненты (функции,
интерфейсы) протоколы взаимодействия формами данных.
     2. Профили регламентирующие процессы проектирования, разработки применения
сопровождения, и развития ИС и их компонент
     Функциональные и технические характеристики ИС определяются заказчиками творчески
без учета положения нормативных документов.

   19. Стандартизированные показатели качества сложных
программных систем
     При создании ИС требуется гибкое формирование и применение гармонизированных
совокупностей базовых стандартов. Для унификации и регламентирования реализации заданных
функций совокупности базовых стандартов адаптируются и конкретизируются применительно к
определенным классам проектов, функций, процессов, компонент. В связи с этим возникло
понятие профилей ИС как основного инструмента функциональной стандартизации. Профиль- это
совокупность нескольких базовых стандартов с четко определенными и гармонизированными
подмножествами функциональных возможностей для реализации заданной функции или группы
функций. Разработка и применение профилей является органической частью процессов
проектирования, разработки, сопровождения, модернизации и развития ИС. Можно выделить две
группы ИС:
     - профили регламентирующие структуру ИС и ее компонент (функции, интерфейсы,
форматы данных);
     - профили регламентирующие процессы проектирования, разработки, сопровождения и
развития ИС и их компонент;
     Стандартизированные показатели качества сложных систем и баз данных
     Базовым международным стандартом является стандарт ISO 91
     Оценка программного продукта, характеристика качества и руководство по их применению.
     Этот стандарт включает набор из 21 показателя объединенных в 6 групп.
     1. Функциональная пригодность. Пригодность для применения, точность, защищенность,
способность к взаимодействию, согласованность со стандартами и правилами проектирования. А)

                                             34
пригодность для применения. Б)точность в) защищенность Г)способность к взаимодействию д)
соответствие стандартам проектирования
     2. Надежность. Уровень завершённости, устойчивость к ошибкам, перезапускаемость системы
     3. Применимость. Понятность, обучаемость, простота использования.
     4. Эффективность. Ресурсная экономичность. Временная экономичность.
     5. Сопровождаемость. Показателей, стабильность, тестируемость.
     6. Переносимость. Адаптируемость, структурируемость, замещаемость, внедряемость.
    Показатели качества баз данных.
     Для баз данным пока отсутствуют международные стандарты. На практике применяют
функциональные и структурные показатели. Функциональные – полнота накопленных
показателей объектов. Количество объектов имеющихся в базе данных к общему числу объектов
по данной тематике (аналогичных базах данных по данной тематике).
     Достоверность – это степень соответствия данных об объектах в базе реальным объектам в
данный момент времени. Изменение реальных данных определяется изменением самих объектов,
изменение данных, верностью расчетов.
     Идентичность данных. Определяется как относительное число объектов не содержащих
ошибки к общему числу объектах в базе данных.
     Актуальность данных. Относительное число морально устаревших данных об объектах в базе
данных к общему числу накопленных и обрабатываемых данных.
     Конструктивные показатели качества информации в базе данных:
     - число записей описания объекта доступных для хранения и обработок;
     - оперативность. Степень соответствия динамики изменения данных в процессе сбора и
обработки состоянию реальных объектов. Или величина запаздывания характеристик реальных
объектов и его изменений в базе данных.
     - периодичность. Это промежуток времени между поставками двух последовательных,
достаточно различающихся информации версий базы данных
     - глубина ретроспективы. Это глубина времени от даты выпуска и записи в базу данных до
настоящего времени
     - динамичность. Это относительное число изменяемых описаний объекта к общему числу
записей за некоторый интервал времени определяющий очередную версию базы данных.
Показатели защищенности БД.

    20. Понятие и виды CASE-средств
     Под термином "CASE-средства" (Computer Aided Software Engineering) понимаются
программные средства, поддерживающие процессы создания и сопровождения АСОИУ, включая
анализ и формулировку требований, проектирование прикладного ПО и баз данных, генерацию
кода, тестирование, документирование, обеспечение качества, конфигурационное управление и
управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и
техническими средствами образуют полную среду разработки АСОИУ.
     Появлению CASE-технологии и CASE-средств предшествовали исследования в области
методологии программирования. Программирование обрело черты системного подхода с
разработкой и внедрением языков высокого уровня, методов структурного и модульного
программирования.
     CASE-технология представляет собой методологию проектирования АСОИУ, а также набор
инструментальных средств, позволяющих в наглядной форме моделировать предметную область,
анализировать эту модель на всех этапах разработки и сопровождения АСОИУ и разрабатывать
приложения в соответствии с информационными потребностями пользователей. Большинство
существующих CASE-средств основано на методологиях структурного (в основном) или
объектно-ориентированного анализа и проектирования, использующих спецификации в виде
диаграмм или текстов для описания внешних требований, связей между моделями системы,
динамики поведения системы и архитектуры программных средств .
     Наиболее трудоемкими этапами разработки АСОИУ являются этапы анализа и
проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых
технических решений и подготовку проектной документации. Графические средства
моделирования предметной области позволяют разработчикам в наглядном виде изучать
                                                35
существующую АСОИУ, перестраивать ее в соответствии с поставленными целями и
имеющимися ограничениями.
      CASE-средства обладают следующими основными особенностями :
а) имеют мощные графические средства для описания и документирования АСОИУ,
    обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие
    возможности;
б) осуществляют интеграцию отдельных компонент CASE-средств, обеспечивающую
    управляемость процессом разработки систем;
в) используют специальным образом организованное хранилище проектных метаданных
    (репозитория).
      Интегрированное CASE-средство должно содержать следующие компоненты:
и) репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий
   проекта и его отдельных компонентов, синхронизацию поступления информации от различных
   разработчиков при групповой разработке, контроль метаданных на полноту и
   непротиворечивость;
к) графические средства анализа и проектирования, обеспечивающие создание и редактирование
   иерархически связанных диаграмм (DFD, ERD и др.), образующих модели АСОИУ;
л) средства разработки приложений, включая языки 4GL и генераторы кодов;
м) средства конфигурационного управления;
н) средства документирования;
о) средства тестирования;
п) средства управления проектом;
р) средства реинжиниринга.
      Современный рынок программных средств насчитывает около 300 различных CASE-средств,
наиболее мощные из которых используются практически всеми ведущими западными фирмами.
      Все современные CASE-средства могут быть классифицированы в основном по типам и
категориям. Классификация по типам отражает функциональную их ориентацию на те или иные
процессы ЖЦ.
      Классификация по категориям определяет степень интегрированности по выполняемым
функциям и включает следующее :
а) отдельные локальные средства, решающие небольшие автономные задачи (tools);
б) набор частично интегрированных средств, охватывающих большинство этапов жизненного
   цикла систем (toolkit);
в) полностью интегрированные средства, поддерживающие весь ЖЦ систем и связанные общим
   репозиторием.
      Помимо этого CASE-средства можно классифицировать по следующим признакам:
а) применяемым методологиям и моделям систем и БД;
б) степени интегрированности с СУБД;
в) доступным платформам.
      Классификация по типам в основном совпадает с компонентным составом CASE-средств.
      На сегодняшний день российский рынок программного обеспечения располагает
следующими наиболее развитыми CASE-средствами: Vantage Team Builder (Westmount I-CASE),
Designer/2000, Silverrun, ERwin+Bpwin, S-Designor, CASE-Аналитик, CASE /4/0, PRO-IV, System
Architect, Visible Analyst Workbench, EasyCASE; VIS; RATIONAL ROSE.

  21. Стандарты для информационных систем управления
MRP, ERP, CSRP, CRM
     Непрерывный рост масштабов проектов информационных систем и их необозримости для
специалистов привели к необходимости изменения отношения к документированию,
регламентированию и дисциплине коллектива специалистов при длительном Жизненном Цикле
(ЖЦ) ПС.
     Накопленный мировой опыт сосредоточен и обобщен в международных, национальных,
военных стандартах, которые неизвестны многим отечественным специалистам. За рубежом
требования стандартов к объектам и документам и процессам жизненного цикла

                                             36
Информационных Систем (ИС) и Программные Средства (ПС) во многих случаях являются
обязательными и определяют конкурентоспособность продукции.
     Состояние развития стандартизации в области ИС имеет следующие особенности:
     - Несколько сотен разработанных за рубежом международных и национальных стандартов не
полностью и неравномерно покрывают потребности в стандартизации объектов и процессов
создания и применения сложных ИС и их компонентов;
     - большая длительность разработки, согласование и утверждение международных и
национальных стандартов (3-5 лет) приводит к консерватизму и хроническому отставанию
требований этих документов от современного состояния;
     - стандарты ИС должны учитывать необходимость построения программных средств как
открытых систем и для этого обеспечивать:
     А) их расширяемость при наращивании и изменении выполняемых функций;
     Б) переносимость ППО между разными аппаратно программными платформами;
     В) возможность взаимодействия с другими ИС той же проблемно ориентированной сферы.
     - в области ИС стандартами поддержаны и регламентированы функционально более простые
объекты и рутинные массовые процессы – телекоммуникация, программирование,
документирование программ и данных и т.д.;
     - наиболее сложные и творческие процессы создания и развития крупных ИС требует
дополнительного изучения проблемы стандартизации.
     Основные цели применения стандартов и нормативных документов:
     - снижение трудоемкости, длительности, стоимости и улучшение других технико-
экономических показателей проектов;
     - повышение качества разрабатываемых или применяемых покупных компонент и ИС в
целом при их разработке, приобретении, эксплуатации и сопровождении;
     - обеспечение расширяемости ИС по набору прикладных функций и масштабируемости в
зависимости от размерности решаемых задач;
     Применение стандартов в проектировании позволяет ориентироваться на построение систем
из крупных функциональных блоков, отвечающие требованиям стандартов. Применять
проверенные проектные решения. Они определяют … интерфейсы и протаколы таким образом,
что разработчику не требуется вдаваться в детали устройства этих компонент.
     Пользователи регламентирующих документов:
     - Руководители проекта и его основных крупных компонент;
     - системные аналитики, создатели пилотных проектов и алгоритмов решения
функционирования задач;
     - программисты, разработчики программ и структур данных;
     - интеграторы функциональных компонент, тестирующие и отсаживающие функциональные
компоненты и систему в целом;
     - испытатели и сертификаторы комплексов программ;
     - разработчики технологии, инструментальных средств, методических, руководящих и
инструктивных документов обеспечивающих жизненный цикл ПС.

     В России создание и испытание АС, которые включают в частности ПС и БД
регламентированы следующими стандартами:
     ГОСТ 28195-89 – Оценка качества программных средств. Общие положения.
     ГОСТ 28806-90 – Качество программных средств. Термины и определения.
     ГОСТ 34.601-90 – Информационная технология (ИТ). Автоматизированные системы.
     ГОСТ 34201-89 – ИТ. Виды, комплектность и обозначение документов при создания АС.
      – ИТ. Техническое задание на создание ИС.
     34.603-92 – ИТ. Виды испытаний АС.
     РД 50-34.698-90 – Методические указания. ИТ. АС. Требования к содержанию документов.
     Наибольшие достижения в регламентировании требований к объектам и процессам ЖЦ ПС и
их реализации сосредоточены в стандартах Министерства Обороны США которые должны
обеспечивать высокое качество и безопасность функционирования критических военных систем
(MIL-STD-498) – включает в себя 3 документа общим объемом 600 страниц.
     – Стандарт – Разработка и документирование ПО
                                             37
     – Руководство – Обзор и адаптация (Подготовка к применению)
     – Руководство – Применение и рекомендации
     Создание ПС рассматривается как часть полного процесса разработки специальных систем
военного назначения. Отмечается, что стандарт базируется на процессах и документах
представленных в стандарте ISO-12207-95.

   22. Аспекты внедрения ERP-систем. Стратегии и типы
производства
      ERP=MRP+CPM+FRP
      MRP – система, которая управляет планированием материальных ресурсов
      CPM – планирование производственных мощностей
      FRP – планирование финансовых ресурсов
      ERP системы – это одни из самых быстрорастущих ИС на рынке программного обеспечения.
      ERP системы объединяют все основные функции предприятия: планирование, производство,
снабжение, сбыт, управление финансами, бухгалтерию и т.д. в единое информационное производство.
      Преимущества ERP:
        – сокращение времени выполнения заказов клиентов
        – лучшее управление оборотными средствами за счет уменьшения уровней запасов.
        – повышение точности управления запасами
        – оптимизация производственных операций
        – лучшее планирование закупок материалов
        – увеличение точности прогнозирования
        – улучшение документооборота
      Во многом результаты внедрения ИС определяют правильным выбором.
      Стратегии и тип производства
      1 Производство на склад
      Планировании производства осуществляется на основании прогноза спроса и имеющихся заказов
на готовую продукцию
      2 Сборка под заказ.
      Изготавливает стандартные детали и компоненты и складирует. При появлении конкретного
заказа производится сборка. Включает в себя этапы сборки и отгрузки.
      Клиент участвует в дизайне конечного продукта путем выбора параметров изделия из
которых будет собран продукт.
      При этой стратегии, создавая небольшой запас сборочных единиц, производитель
обеспечивает практически неограниченное число вариантов изделия.
      Представители: Компании занимающиеся сборкой компьютеров, производители мебели,
дорожные техники, некоторые приборостроительные компании.
      3 Производство под заказ
      Изготовление продукта начинается только тогда, когда изготовитель получит заказ от
клиента.
      Большинство составляющих производится или закупается непосредственно под конкретный
заказ.
      Представители: производители мебели, упаковки, пластиковых окон, полиграфические
комбинаты и т.д.
      4 Разработка под заказ
      Выполнение заказа клиента предварительно требует разработки дизайна заказываемой
продукции. Предприятие изготавливает уникальное изделие под каждый заказ клиента. Период
поставки достаточно велик.
      Представители: Космическая отрасль, оборонные заводы, судоверфи и т.д.

     Изготовитель шкафов-купе производит 10 базовых моделей. 100 размеров базовой модели. 10
– типов материалов. + цвет.



                                               38
    23. Стратегии производства и период поставки
     Главной характеристикой стратегии производства является период доставки – время
поступления заказа от клиента до поставки реального проекта.
     В рыночных условиях равен периоду коммерческого цикла – время в течение которого
покупатель согласен ждать.
     Производство на склад: закупка – производство – сборка – хранение – отгрузка.
     Период поставки (Tn) = отгрузка;
     Сборка под заказ: закупка – производство – хранение – сборка – отгрузка.
     Период поставки (Tn) = сборка + отгрузка;
     Производство под заказ: закупка – хранение – производство – сборка – отгрузка.
     Период поставки (Tn) = производство + сборка + отгрузка
     Разработка под заказ: дизайн – закупка – производство – сборка – отгрузка.
     Период поставки (Tn) = дизайн + закупка + производство + сборка + отгрузка

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

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

     А. – Производство на склад
     Ориентирован на немедленную поставку стандартных готовых изделий. ОПП используется
для поддержания уровня запаса готовой продукции, установленной политикой предприятия. ОПП
формируется на основании прогноза спроса на тот или иной вид товара. Учитывается уровень
страхового запаса. Планирование производится для каждой позиции готовой продукции,
производство поточное (массовое, крупносерийное) или заказное (мелкосерийное). При этом ОПП
и ГОС полностью совпадают.
     Пример: Планирование и управление производством и закупками:
                                               39
     ЗАО      "Измерительные    приборы"     Продукция:    Электроизмерительные   приборы
промышленного и бытового назначения.
     Основные процедуры планирования и управления разработанные в ходе внедрения ERP
системы:
     1. Действия по глобальному планированию.
     - определяются потребности в закупках сырья и ОПП. (
     Отдел продаж – ввод скользящего прогноза на пол года вперед помесячно,
     – статистические задачи
     – разбивка прогноза на ближайший и текущий месяц понедельно)
     1. Формирует ОПП
     2.Оценивает возможности выполнения прогноза на основе ОПП. Для этого используется
следующие функции, поддерживаемые системой:
     а – оценка баланса запаса готовой продукции с учетом потребностей и ожидаемого
производства по ОПП;
     б – оценки ресурсов необходимых для выполнения ОПП. Ресурсы используемые в ТехПроц и
определяемые ключевыми руководителями;
     в – в случае необходимости по результатам оценки мощности корректирует ОПП;
     3. Запускает систему MRP (Планирование потребностей материальных ресурсов)
     Выполняет оценку мощности с учетом календарей цехов.

    2. Действия по закупкам
    По результатам расчета формируется перечень необходимых материалов и комплектующих.
Указывается количество и время закупки. Для реализации используется отчет ИС.
    Анализируются дефициты "горящее" позиции.
    Размещение заказов у поставщиков.

    25. Выбор типа управления производством
      1. Действия по глобальному планированию
      Определяются потребности в закупках сырья, а также ОПП (основной производственный
план)
      Отдел продаж:
      1) ввод скользящего прогноза на полгода вперед помесячно
      2) статические задачи
      2. Разбивка прогноза на текущий и ближайший месяц понедельно.
      Производственный отдел:
      1) формирует ОПП
      2) оценивает возможности выполнения прогноза на основе созданного плана ОПП. Для этого
используются следующие функции поддерживаемые системой.
      а) оценка баланса запаса готовой продукции с учетом потребностей и ожидаемого
производства на ОПП
      б) оценки ресурсов необходимых для выполнения ОПП, определенные в тех процессе, а
также определяемые ключевыми руководителями.
      П: бюджет закупки сырья, площадь складов
      в) в случае необходимости, по результатам оценки мощности корректирует ОПП
      г) запускает систему MRP (планирование потребностей в материальных ресурсах)
      д) выполняет оценку мощности с учетом календарей цехов.
      3) действие по закупкам
      1) по результатам расчета формируется перечень необходимых материалов и ресурсов, кол-
во и время закупки. Для реализации используется отчет ИС.
      2) Анализируются дефициты и горящие позиции
      3) размещаются заказы у поставщиков.




                                              40
   26. Эффективность внедрения корпоративной
информационной системы. Традиционные финансовые
методы
    1 – Традиционные финансовые методы
    2 – Качественные методы
    3 – Финансовые методы

      Результаты, получаемые от внедрения КИС можно разделить на 3 основные группы:
      1 – Новые функциональные возможности.
      Возможности получать качественно новую информацию для принятия управленческих
решений (Прибыльность отдельных подразделений, определение аналитических данных по
продажам и затратам).
      2 – Ускорение и качественное улучшение учета.
      Возможность формирования отчетности организацией за несколько дней вместо нескольких
недель. Возможность избежание многократного ввода информации, потенциальных ошибок,
прозрачность системы для аудита, упрощение процесса получения международной отчетности.
      3 – Оптимизация бизнес-процессов.
      Усредненные результаты от внедрения КИС:
      – снижение транспортно-заготовительных расходов до 60%;
      – снижение задержек готовой продукции до 45%;
      – уменьшение страховых запасов до 40%;
      – снижение производственного брака до 35%;
      – уменьшение затрат на административно-управленческий персонал до 30%;
      – сокращение производственного цикла до 30%.
      Традиционные финансовые методы.
      Эти методы используют традиционные финансовые расчеты с учетом специфики ИТ и
эффективности использование риска.
      1. Экономическая добавленная стоимость. EVA.
      В качестве характеристики используется чистая инвестиционная прибыль из которой
вычитаются соответствующие затраты. При оценке новой ERP системы учитываются все
инвестиции. В том числе первоначальные денежные вложения, расходы на поддержку, затраты на
обучение и т.д. Все это плата за будущую выгоду. Которая будет способствовать увеличению
оборота и снижению издержек.
      "–"
      – Трудно принять решение о покупке нового сервера без проведения промежуточных
расчетов.
      2. Полная стоимость владения (Total Cost of Ownership)
      Эффективный подход нахождения лучшего соотношения цена-качество для организации
таких услуг, как восстановление после сбоев, управление модернизацией и техническая
поддержка. В данных этого подхода учитывается стоимость внедрения, администрирования,
перемещения, технической поддержки, сопровождения, вынужденных простоев и других прямых
затрат.
      Подход получил широкое распространение.
      Методология ТСО хорошо подходит для подсчета текущих стоимостных параметров и с ее
помощью можно анализировать не только …???
      "–": - не учитываются риски, что не позволяет соотнести технологию со стратегическими
целями развития бизнеса и повышения задачи конкурентоспособности;
      3. Совокупный экономический эффект (Total Economic Impact)
      Предназначен для поддержки принятия решений, снижения рисков, обеспечения гибкости
т.е. ожидаемых или потенциальных преимуществ, которые обычно остаются за рамками анализа
экономических преимуществ и затрат.
      Основные параметры:
      - стоимость
      - преимущество
                                             41
    - гибкость
    Для каждого из составляющих определяется свой уровень риска.
    Данная методология работает при оценке двух различных сценариев.

     4. Быстрое экономическое обоснование
     Подобно методу (3) данная методология предусматривает конкретизацию модели полной
стоимости владения за счет установления соответствия между расходов на ИТ и ведения бизнеса.
     Процесс:
     1. Разработка бизнес-плана, отражающего требования всех заинтересованных сторон
включая факторы успеха и …???
     2. совместная проработка влияния технологии на факторы успеха;
     3. анализ критериев стоимости эффективности;
     4. определение потенциальных рисков с вероятностью возникновения;
     5. вычисление стандартных финансовых показателей.
     Данная методология лучше подходит для управления отдельными проектами, а не
портфелями.

   27. Эффективность внедрения корпоративной
информационной системы.Качественные методы
    1 – Традиционные финансовые методы
    2 – Качественные методы
    3 – Финансовые методы

     Результаты, получаемые от внедрения КИС можно разделить на 3 основные группы:
     1 – Новые функциональные возможности.
     Возможности получать качественно новую информацию для принятия управленческих
решений (Прибыльность отдельных подразделений, определение аналитических данных по
продажам и затратам).
     2 – Ускорение и качественное улучшение учета.
     Возможность формирования отчетности организацией за несколько дней вместо нескольких
недель. Возможность избежание многократного ввода информации, потенциальных ошибок,
прозрачность системы для аудита, упрощение процесса получения международной отчетности.
     3 – Оптимизация бизнес-процессов.
     Усредненные результаты от внедрения КИС:
     – снижение транспортно-заготовительных расходов до 60%;
     – снижение задержек готовой продукции до 45%;
     – уменьшение страховых запасов до 40%;
     – снижение производственного брака до 35%;
     – уменьшение затрат на административно-управленческий персонал до 30%;
     – сокращение производственного цикла до 30%.
     Качественные методы
     Эвристические методы, которые направлены на выполнение расчетов с субъективными и
качественными оценками и позволяют определить ценность персонала и процессов
     1. Система сбалансированных показателей
     В рамках этой методики показатели финансовых отчетов (традиционных) объединяются с
операционными параметрами. Это создает ??? схему, позволяющую оценить нематериальные
активы.
     Уровень     корпоративных     инноваций;   степень   удовлетворенности    сотрудников,
эффективность приложений. В системе сбалансированных параметров все параметры
рассматриваются с 4-х точек зрения: финансовой; удовлетворение потребностей клиентов и
внутренних процессов; дальнейший рост и обучение.
     Менеджеры сопоставляют перспективы каждого из этих направлений с общей стратегией
развития бизнеса.
     Многие считают, что метод служит для оправдания.

                                              42
     2. Информационная экономика
     Ориентирована на оценку портфеля проектов, и направление ресурсов туда, где они принесут
большую выгоду. Идея в том, чтобы заставить ИнфСл и бизнесменеджеров расставить правильно
приоритеты и представить объективные заключения для тех или иных проектов организации.
Руководителям ИТ отделов и бизнесменеджеров необходимо составить список из 10 факторов,
влияющих на принятие решений с указанием +, – и рисков. Наиболее быстрый способ
определения затрат и сопоставление с целями.
     3. Управление портфелем активов
     Методология вобрала в себя "+" других подходов к оценке эффективности. Для достижения
конечной цели рассматривают сотрудников ИТ службы и ИТ проекты не как затратную часть, а
как активы, которыми управляют также как другими инвестициями. Т.е. директор ИТ службы
осуществляет контроль за капиталовложениями, оценивает новые инвестиции по критериям
затрат, выгоды и риска. Причем надо минимизировать риски вкладывая деньги в разные
технологические проекты.
     4. Система показателей ИТ
     Ориентирован на информационные технологии и привлечению ИТ ресурсов к решению
стратегических задач. И вместо основных направление системы сбалансированных показателей
рассматривают: развитие бизнеса, производительность, качество (как с внутренней, так и с
внешней точки зрения).
     5. Принятие решений
     При этом программа обладает многоуровневым подходом и позволяет рассчитывать
эффективность на долгие годы.

   28. Эффективность внедрения корпоративной
информационной системы. Вероятностные методы
     1 – Традиционные финансовые методы
     2 – Качественные методы
     3 – Финансовые методы
     Результаты, получаемые от внедрения КИС можно разделить на 3 основные группы:
     1 – Новые функциональные возможности.
     Возможности получать качественно новую информацию для принятия управленческих
решений (Прибыльность отдельных подразделений, определение аналитических данных по
продажам и затратам).
     2 – Ускорение и качественное улучшение учета.
     Возможность формирования отчетности организацией за несколько дней вместо нескольких
недель. Возможность избежание многократного ввода информации, потенциальных ошибок,
прозрачность системы для аудита, упрощение процесса получения международной отчетности.
     3 – Оптимизация бизнес-процессов.
     Усредненные результаты от внедрения КИС:
     – снижение транспортно-заготовительных расходов до 60%;
     – снижение задержек готовой продукции до 45%;
     – уменьшение страховых запасов до 40%;
     – снижение производственного брака до 35%;
     – уменьшение затрат на административно-управленческий персонал до 30%;
      – сокращение производственного цикла до 30%.
     Вероятностные методы
     1. Справедливая цена опционов
     Методология создана на основе модели Блека Шоулза. Удостоена Нобелевской премии.
     Методика направлена на определение количественных параметров гибкости. позволяет
оценить эффективность аренды, слияния, покупки и производства. Используется в качестве
альтернативы стандартным подходам составления плана и бюджета в условиях неопределенного
состояния рынка и экономики в целом, когда на первый план выступает параметр гибкости.



                                              43
   29. Характеристика рынка программного обеспечения по
автоматизации деятельности организации. Состояние рынка
программного обеспечения
     На рынке ПО выделяют 3 основных сегмента: приложения, разработку и развертывание
приложений, системное и структурное ПО.
     На Российском рынке выделяются отрасли: производственные (машиностроение);
инфраструктурные (транспорт, комунальшики); финансовая.
     Особенности Российского рынка ПО:
     - нестабильность законодательной базы;
     - незрелость бизнес отношений;
     - отсутствие современной управленческой практики у менеджеров большинства Российских
организаций. При увеличении роли КИС и ИТ. Недооценка стоимости владения КИС;
     Современное состояние рынка в области автоматизации управленческой деятельности
характеризуется следующими особенностями:
     - Большое число организаций с унаследованными системами на устаревших платформах
разработанных самостоятельно службами АСУ и не сопровождаемых разработчиками;
     - острая нехватка квалифицированного персонала в области ИТ;
     - присутствие на рынке как западных, так и отечественных разработчиков;
     На Российском рынке в настоящее время присутствуют около 20 западных и несколько
десятков отечественных компаний.
     Базовые сегменты рынка:
     - Крупные организации, требующие системы автоматизации (Стоимость: 200 – 300 тыс.$)
     - средние организации 10 – 200 тис.$
     - малые до 10 тыс. $
     Доходы от продажи КИС и их рыночные доли:
     САПР – 61,8 млн. $. – 48,6 %
     Oracle – 14 млн.$ – 11,1
     Галактика – 8.7млн.$ – 7%
     Бан – 7,2 млн.$ 5,6%
     Парус – 3,2млн.$ – 2,5%
     Динамика рынка:
     2000 – Весь рынок ИТ 2953
     2001 – 4158
     2002 – 4934
     Доля ЕРП-систем:
     2001 – 116млн.$
     2002 – 162млн.$
     Машиностроение, пишепром, чимпром, энергетика.

   30. Характеристика рынка программного обеспечения по
автоматизации деятельности организации. Основные
участники рынка информационных и телекоммуникационных
технологий
     1. Производители КИС;
     2. официальные дитребьютеры КИС;
     3. системные интеграторы (осуществляют внедрение КИС. При выборе интегратора
необходимо учитывать:
     - компетенцию и опыт организации аналогичных отраслей либо конкретных бизнес-
процессов;
     - перечень предоставляемых услуг (консалтинг, оптимизация бизнес-процессов, управление
проектами, оценку внедрения КИС, обучение персонала));
     4. консалтинговые организации, занимающиеся консультированием по принципам работы
КИС;
                                              44
     5. поставщики прикладных услуг или ASP;
     6. провайдер торговых услуг;
     7. провайдер Интернет услуг;
     8. поставщики услуг управления в области информационных технологий (менеджмент-
сервис провайдеры);
     На рынке ПО выделяют 3 основных сегмента: приложения, разработку и развертывание
приложений, системное и структурное ПО.
     На Российском рынке выделяются отрасли: производственные (машиностроение);
инфраструктурные (транспорт, коммунальщики); финансовая.
     Особенности Российского рынка ПО:
     - нестабильность законодательной базы;
     - незрелость бизнес отношений;
     - отсутствие современной управленческой практики у менеджеров большинства Российских
организаций. При увеличении роли КИС и ИТ. Недооценка стоимости владения КИС;
     Современное состояние рынка в области автоматизации управленческой деятельности
характеризуется следующими особенностями:
     - Большое число организаций с унаследованными системами на устаревших платформах
разработанных самостоятельно службами АСУ и не сопровождаемых разработчиками;
     - острая нехватка квалифицированного персонала в области ИТ;
     - присутствие на рынке как западных, так и отечественных разработчиков;
     На Российском рынке в настоящее время присутствуют около 20 западных и несколько
десятков отечественных компаний.
     Базовые сегменты рынка:
     - Крупные организации, требующие системы автоматизации (Стоимость: 200 – 300 тыс.$)
     - средние организации 10 – 200 тис.$
     - малые до 10 тыс. $
     Доходы от продажи КИС и их рыночные доли:
     САПР – 61,8 млн. $. – 48,6 %
     Oracle – 14 млн.$ – 11,1
     Галактика – 8.7млн.$ – 7%
     Баан – 7,2 млн.$ 5,6%
     Парус – 3,2млн.$ – 2,5%
     Динамика рынка:
     2000 – Весь рынок ИТ 2953
     2001 – 4158
     2002 – 4934
     Доля ЕРП-систем:
     2001 – 116млн.$
     2002 – 162млн.$
     Машиностроение, пищепром, химпром, энергетика.

   31. Характеристика рынка программного обеспечения по
автоматизации деятельности организации. Критерии выбора
корпоративной информационной системы
     На рынке ПО выделяют 3 основных сегмента: приложения, разработку и развертывание
приложений, системное и структурное ПО.
     На Российском рынке выделяются отрасли: производственные (машиностроение);
инфраструктурные (транспорт, коммунальщики); финансовая.
     Особенности Российского рынка ПО:
     - нестабильность законодательной базы;
     - незрелость бизнес отношений;
     - отсутствие современной управленческой практики у менеджеров большинства Российских
организаций. При увеличении роли КИС и ИТ. Недооценка стоимости владения КИС;


                                            45
     Современное состояние рынка в области автоматизации управленческой деятельности
характеризуется следующими особенностями:
     - Большое число организаций с унаследованными системами на устаревших платформах
разработанных самостоятельно службами АСУ и не сопровождаемых разработчиками;
     - острая нехватка квалифицированного персонала в области ИТ;
     - присутствие на рынке как западных, так и отечественных разработчиков;
     На Российском рынке в настоящее время присутствуют около 20 западных и несколько
десятков отечественных компаний.
     Базовые сегменты рынка:
     - Крупные организации, требующие системы автоматизации (Стоимость: 200 – 300 тыс.$)
     - средние организации 10 – 200 тыс.$
     - малые до 10 тыс. $
     Доходы от продажи КИС и их рыночные доли:
     САПР – 61,8 млн. $. – 48,6 %
     Oracle – 14 млн.$ – 11,1
     Галактика – 8.7млн.$ – 7%
     Баан – 7,2 млн.$ 5,6%
     Парус – 3,2млн.$ – 2,5%
     Динамика рынка:
     2000 – Весь рынок ИТ 2953
     2001 – 4158
     2002 – 4934
     Доля ЕРП-систем:
     2001 – 116млн.$
     2002 – 162млн.$
     Машиностроение, пищепром, химпром, энергетика.

      1. Количество лет нахождения организации производителя в данном бизнесе;
      2. количество лет продажи данной КИС в России;
      3. количество организаций партнеров по внедрению КИС в России;
      4. количество сотрудников в Российском представительстве данной организации;
      5. количество всех инсталляций, в том числе в России;
      6. число пользователей, приходящееся в среднем на одну инсталляцию;
      7. процентное соотношение инсталляций с числом пользователей более 300;
      8. уровень локализации основных модулей в %;
      9. срок полного внедрения КИС;
      10. возможность сопряжения с другими автоматизированными системами (АСУ ТП, САПР,
другими подсистемами, функционирующими в организации; автоматизация склада\производства и
т.д.)
      11. стоимость КИС;
      12. цена консалтинга, связанная с внедрением и сопровождением КИС (100–500% стоимости
КИС)
      Сравнительная характеристика стоимости лицензий:
      Численность        Галактика       IT    САПР3        БАН     Oracle
      Пользователей
      400                 1000          400     1700        1200     1000
      250                  625          250     1125         750      600
      50                   125           50      225         150      120

     13. цена обучения (зависит от маркетинговой политики организации);
     При автоматизации процессов планирования и учета особо выделяют требования к
интерфейсу и переносу данных, формам документов. В связи с развитием Web ориентированных
систем надо учитывать стоимость владения и автоматизации внешних систем интегрированных с
Интернет. При
     – работе с ЕРП системой в удаленном режиме.
                                             46
     – построение электронных магазинов
     – наличию CRM функциональности (отношения с клиентами)
     – наличию SCM функциональности (управление логистическими цепочками поставок)
     Свойства КИС
     – Любая КИС предусматривает возможность использования референтных моделей – это
эталонные схемы планирования и управления разработанные для конкретных отраслей. Эти
модели учитывают опыт внедрения мировых организаций. Включают проверенные на практике
методы и процедуры организации бизнеса. Эти модели позволяют при внедрении КИС сэкономить
время и средства при налаживании модели для аналогичной отрасли и типа производства.
     – КИС обладают свойством динамической функциональности, что обеспечивает
возможность плавной перестройки ИС на базе единой бизнес модели организации. При разработке
новых бизнес-процессов старые процедуры сохраняются. Это обеспечивает расширяемость КИС.
     – Масштабируемость по мощности. Сохранение работоспособности и сохранении функций
КИС при изменении масштабов деятельности предприятия.

    32. Основные подходы внедрения КИС
     1. Эталонный процесс внедрения КИС
     1. Разработка стратегии автоматизации деятельности организации
     2. Анализ экономической деятельности организации
     3. Реорганизация деятельности организации
     Стратегия автоматизации:
     - Цели деятельности
     - область деятельности
     - последовательность деятельности
     Способ автоматизации:
     - по участкам
     - по направлениям
     - комплексная
     Долгосрочная техническая политика:
     (определение внутренних стандартов деятельности предприятия)
     Ограничения:
     - временные
     - технические
     - финансовые
     - трудовые
     - и т.д.
     Процедура управления изменениями плана:
     Стратегический план составляется с учетом:
     - среднего периода между сменой технологии основного оборудования;
     - среднего времени жизни выпускаемых продуктов и их модификаций;
     - анансированых долгосрочных планов поставщиков технических решений в плане их
развития;
     - стратегического плана развития организации включая слияния, присоединения, изменение
номенклатуры и т.д.
     При внедрении КИС необходимо учитывать цели:
     1. Снижение себестоимости продукции;
     2. увеличение количества выпускаемой продукции или ассортимента (товарооборот);
     3. сокращение цикла разработки новых продуктов и выхода их на рынок;
     4. переход от производства "на склад" к производству "под заказчика" с учетом его
индивидуальных особенностей.
     Проблемы:
     - Состояние рынка ИТ;
     - эффективность вложений в ИТ;
     - необходимость реорганизации деятельности организации при внедрении КИС;

                                             47
     2. BSP – технологии моделирования и автоматизации бизнес-процессов.
     Информация рассматривается как важнейший ресурс и ее надо планировать. Нисходящий
подход к анализу. Работы выполняются в следующей последовательности (13 шт.):
     - получение поддержки руководства организации относительно начала проекта по
автоматизации деятельности организации;
     - подготовка к анализу объектов, подлежащих автоматизации;
     - проведение совещания руководителя организации, представителей системного интегратора
и консультантов в связи со стартом проекта по автоматизации деятельности организации;
     - формирование перечня основных направлений деятельности организации и содержащихся в
них бизнес-процессов с кратким их описанием;
     - выделение основных классов данных, формирование матрицы связей (DFD);
     - анализ существующих деловых взаимодействий между руководителями и ИС. Для этого
строится 4 вида матриц для существующих и планируемых ИнфПодсистем:
     1. Руководитель процесса – описывает обязанности руководителей и вовлеченность в
основные бизнес-процессы;
     2. ИнфСист – руководитель – описание систем, используемые руководителем;
     3. ИнфСист – процессы – отношение между ИС и процессами;
     4. ИнфСист – файлы данных – показывает какие данные какими системами используются.
     - корректировка матрицы связей и решение следующих задач: уточнение матриц, оценка
необходимой информации, определение приоритетов потребностей в ИС, определение текущих
задач автоматизации;
     - выявление проблем, возникающих в связи со следующими моментами:
     1. С существующими ИС и будущими ИС в организации;
     2. определяются проблемы не относящиеся к ИС и процессу автоматизации. Они передаются
руководству для принятия необходимых мер.
     - проектирование традиционными методами архитектуры ИС;
     - определение приоритетов в реализации стратегии автоматизации и последовательности
выполнения этапов;
     - планирование модификаций в связи с изменяющимися требованиями;
     - выработка рекомендаций по совершенствованию ИС и планов автоматизации;
     - формирование отчетности по проведенным работам.

      3. TQM – тотальное управление качеством
      Один из подходов к реорганизации деятельности предприятия. "Постоянное улучшение
процессов". В основе – концепция управления качеством выпускаемой продукции. Оно д.б.
направлено на удовлетворение текущих и будущих потребностей потребителя.
      Достижение требуемого уровня качества требует постоянного совершенствования
произв.проц. для решения были предложены принципы, которые составляют основу теории
управления качеством (циклы Деминга).
      Стандарт ИСО9000 – "Стандарт на качество проектирование, разработку, изготовление и
послепродажною поддержку" – определяет базовый набор мероприятий по контролю качества и
схему функционирования бизнес-процессов организации, обеспечивающих высокое качество
работы. ИСО9000 – стандарт качества не только для производимых товаров и услуг, он покрывает
все этапы, весь жизненный цикл.
      ИСО9000 представляет собой серию стандартов 9000-9004. он регламентируют два момента:
      - Наличие и документирование соответствующего бизнес-процесса;
      - изменяемость его качества (бизнес-процесса).
       Сертификации организации по ИСО9000 включает 3 этапа:
      - Применение стандартов в организации заключающиеся в разработке и вводе в действие
мер, предписанных в стандарте;
      - проведение сертификации органами аккредитованными ИСО;
      - периодическая проверка организации на предмет следования стандартам (2 раза в год).

    4. BPR – реорганизация деятельности предприятий при внедрении КИС может
осуществляться на основе BPR-подхода Хаммера и Чаммпи. Ими предлагается фундаментально
                                              48
переосмыслить и радикально перепланировать бизнес-процессы с целью радикального увеличения
показателей по параметрам: затраты, качество, сервис и скорость.
     Положения:
     - Несколько работ объединяются в одну;
     - исполнителям на местах делегируются полномочия по принятию решений;
     - работы или бизнес-процесс выполняется там, где это целесообразно. Но возможна передача
работ на условиях аутсорсинга;
     - снижается доля работ по проверке и контролю;
     - минимизируется количество согласований;
     - ответственный менеджер является единственной точкой контакта с клиентом.

    – Стратегии
    – Организационное обеспечение

    33. Стратегии внедрения КИС на примере “Баан”
     БААН:
     1. Параллельная стратегия – одновременно работают старая и новая системы, их документы
сравниваются, если в течении длительного времени они совпадают – переход на новую систему.
     2. Пилотный проект (самый используемый) – тактика скачка. Применяется к ограниченному
числу бизнес-процессов на небольших участках деятельности организации.
     3. Стратегия «Узкого места» – применяется для небольшой части производственного
процесса. План внедрения формируется для узкого места и для людей на нем работающих.
     В дальнейшем эксплуатация КИС:
     – модернизация программно-аппаратной части;
     – отслеживание изменений в законодательстве;
     – доработка КИС под новые требования пользователей;
     – обеспечение безопасности.
     В зависимости от объекта различают типы внедрения:
     – однозвенное внедрение – простая организация
     1. Техническое внедрение и организационная оптимизация.
     Происходит внедрение, организационная структура сохраняется, а затем выполняется
оптимизация.
     2. Полномасштабное.
     3. Организационная оптимизация и техническое внедрение.
     – многозвенное внедрение – сложная организация
     Все перечисленные выше стратегии могут работать и в этом случае.
     1. Стратегия «Сверху вниз»
     Этапы:
       1. Консолидация и разработка корпоративных решений относительно автоматизации
внедрения КИС
       2. Пилотное внедрение – производится тестирование и уточнение принятого
корпоративного решения.
       3. Штамповка – штамповка сформулированных решений и тотальное внедрение
     2. «Снизу»
     Сначала внедрение КИС на отдельных звеньях без предварительного получения
корпоративного решения. В дальнейшем следует разработка корпоративного решения.

   34. Стратегии внедрения КИС на примере корпорации
“Парус”
1   Комплексный проектный подход
2   Прямое внедрение
3   Горизонтальное тиражирование
4   Информационный консалтинг
Комплексный подход включает:
                                              49
1.1 Экспресс-диагностика
1.2 Подготовительный этап
1.3 Предобследование
1.4 Разработка ТЗ
1.5 Разработка контрольного примера
1.6 Настройка АСУ «Парус»
1.7 Испытание
1.8 Обучение конечных пользователей
1.9 Запуск АС в опытную эксплуатацию
1.10 Опытная эксплуатация
1.11 Запуск АС в промышленную эксплуатацию
Экрпесс-диагностика финансово-хозяйственной деятельности организации заказчика.
Цель: Принятие ключевых решений по инициализации проекта автоматизации.
Работы:
Наименование                                  Результат
Опрос должностных лиц организации             Формируется документ, который называется
заказчика, во главе с руководителем для       «Отчет по экспресс-диагностики»:
выяснения проблем существующей системы        1 Краткое описание предмета бизнеса
управления и пожелания к ее                      заказчика
усовершенствованию.                           2 Описание проблем и слабых мест бизнеса
                                                 заказчика
                                              3 Проектные риски, анализ осуществимости
                                                 проекта
                                              4 Описание организационной структуры
                                                 заказчика
                                              Предложение по методам решения проблем;
                                              Предполагаемая технология построения ИС;
                                              Стоимость решения;
                                              Базовые подходы к ведения проекта и
                                              регламенты к проведению проектных работ.
Подготовительный этап.
Цель: подготовка единого подхода корпорации и заказчика по совместному ведению работ.
Наименование                                  Результат
Формирование управляющего совета и            Протокол совещания;
рабочей группы;
Проведение начального общего собрания;        Приказ о начале внедрения АСУ «Парус» в
                                              организации.
Обучение членов рабочей группы технологии     Аттестационные листы, аттестаты;
внедрения проектных работ и их аттестация;
Разработка устава проекта;                    Устав проекта:
                                                  Технологическая схема проекта
                                                  Рамки проекта
                                                  Организационная структура проекта
                                                  Процессы и регламенты управления
                                                    проектом;
Согласование ???;                                План-график;
Обучение и аттестация ключевых                   Аттестационные ведомости, аттестаты;
пользователей;
Подготовка заказчиком компьютерного класса
на территории своего предприятия;
Согласование план-графика , подготовка
пользователя на территории заказчика;
Обучение аттест.                                 Аттестационные ведомости, аттестаты;
Подготовка и оборудование заказчиком             Акт готовности проектной комнаты к
проектной комнаты на территории                  работе
                                              50
организации
     Предпроектное обследование
     Описываются бизнес-процессы и структуры данных организации заказчика AS-IS.
Согласуется ведение структуры будущей системы. Принимается решение по разработке ТЗ.
Наименование                                 Результат
Отчет о предпроектном обследовании:          План счетов
1. Описание бизнес-процессов и структуры
данных
1.1 Общие сведения
1.2 Виды деятельности
1.3    Цели    проекта    и   предпроектного
обследования
1.4 Рамки проекта
1.5 Структура организации
1.6 Функции структуры подразделений
Классификаторы                бухгалтерского
управленческого учета. Бизнес-процессы «как
есть».
Разделяют по описанию инфраструктуры
существующей системы:
– уровень автоматизации
– компьютерная грамотность пользователей
– инфраструктура IT службы
Альбом выходных форм (образцы первичных
документов и отчетов
2.     Анализ    информации     потребностей Анализ информации потребностей лиц
руководителей:                               принимающих решение
– сбор требовании и пожеланий руководителей
– определение типовых управляющих форм по
альбому к внедрению
– разработка предложения по автоматизации и
рекомендации по удовлетворению информации
потребностей руководителей

    Работа:
Наименование                              Результат
Разработка приложения                     – Предложение по внедрению
                                          – Предложение по архитектуре АРМ’ов с
                                          привязкой к задаче автоматизации
                                          –     предложения       по     аппаратному,
                                          программному обеспечению
                                          – предложение по подготовке конечных
                                          пользователей
Разработка рекомендаций по удовлетворению – раздел документа рекомендации перечня,
информации потребности руководителей      примерные образцы контрольных отчетов
                                          – регламенты автоматизации уведомлений




                                           51

								
To top