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

соврем. модель качества кис и по.

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

31.Качество ЭИС. Критерии оценки

Оценка качества функционирования ЭИС выполняется по комплексу критериев. Оценке подлежат:

система в целом;

отдельные составляющие этапа проектирования;

важнейшие компоненты этапа эксплуатации системы.

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

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

Качество экономических информационных систем.

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

· структурная сложность определяет количество составляющих элементов системы и связей между ними;

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

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

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

32.Внедрение информационных систем

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

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

Для системы управления предприятием основными аспектами являются следующие факторы:

цель деятельности организации;

взаимосвязь общей цели организации с целями и задачами каждого из подразделений предприятия;

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

наличие взаимосвязей между различными элементами системы управления;

наличие органа управления предприятием;

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

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

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

общая цель управления для систем любого уровня;

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

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

постоянное взаимодействие пользователей и технических средств в процессе реализации функций управления;

ориентация системы на автоматизацию обработки информации;

управление с использованием системы обратной связи.

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

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

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

достичь или превзойти уровень эффективности работы конкурентов?

улучшить планирование и контроль исполнения финансовых и оперативных планов?

улучшить взаимоотношения с клиентами?

увеличить объем продаж?

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

уменьшить инвестиции в запасы товаров?

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

Основными причинами создания информационных систем обычно являются следующие:

расширение бизнеса и увеличение объемов производства (продаж);

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

необходимость внедрения системы планирования и бюджетирования;

повышение уровня контроля;

повышение оперативности и достоверности информации.

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

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

централизованное хранение и обработка данных;

упорядочение потоков информации;

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

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

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

разработка силами программистов предприятия;

заказ разработки у специализированного предприятия;

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

Каждый из способов создания ИС имеет свои преимущества и недостатки.

33.Технология внедрения. Анализ возможностей организации

Обеспечение процесса анализа и проектирования ИС возможностями CASE-технологий

Термин "CASE" (Computer Aided Software/System Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина "CASE", ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом.

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

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

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

широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;

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

CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств [Вендров А.М., http://www.citforum.ru/database/case/index.shtml].

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

Большинство CASE-средств основано на парадигме "методология/метод/нотация/структура/средство".

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

Метод - систематическая процедура или технология генерации описаний компонент ПО (например, описание потоков и структур данных).

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

Структуры являются средством для реализации структурного анализа и построения структуры конкретной системы.

Средства - технологические и программные инструменты для поддержки и усиления методов.

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

ускоряют процесс коллективного проектирования и разработки;

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

освобождают разработчика от рутинной работы, оставляя время для творчества;

обеспечивают эффективность и качество разрабатываемого ПО за счет автоматизации контроля всего процесса разработки;

поддерживают сопровождение и развитие системы на высоком уровне.

Следует отметить, что, несмотря на все потенциальные возможности CASE-средств, существует достаточно много примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (Shelfware).

В связи с этим необходимо учитывать следующее:

CASE-средства не обязательно дают немедленный эффект, он может быть получен только спустя какое-то время;

реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

Можно также перечислить следующие факторы, усложняющие определение возможного эффекта от использования CASE-средств:

широкое разнообразие качества и возможностей CASE-средств;

относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

широкое разнообразие в практике внедрения различных организаций;

отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

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

различная степень интеграции CASE-средств в различных проектах.

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

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

Проведение функционального и информационного обследования системы управления (административно-управленческой деятельности) предприятием (рис. 8.12):

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

определение функциональной структуры предприятия;

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

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

обследование деятельности выделенных структурных элементов;

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

Разработка моделей деятельности структурных элементов и системы управления в целом:

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

спецификация входных и выходных информационных потоков;

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

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

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

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

объединение DFD-моделей структурных элементов в единую модель системы управления предприятием.

Разработка информационных моделей структурных элементов и модели информационного пространства системы управления:

определение сущностей модели и их атрибутов;

проведение атрибутного анализа и оптимизация сущностей;

идентификация отношений между сущностями и определение типов отношений;

анализ и оптимизация информационной модели;

объединение информационных моделей в единую модель информационного пространства.

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

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

составление перечня подсистем и логических АРМов (автоматизированных рабочих мест), определение способов их взаимодействия;

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

разработка требований к средствам базового технического обеспечения ИС;

разработка требований к средствам базового программного обеспечения ИС.

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

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

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

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

Модель системы в технологическом CASE-решении

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

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

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

Таким образом, современные CASE-средства вместе с системным программным обеспечением и техническими средствами поддержки образуют полную среду разработки информационных систем

34.Технология внедрения. Определение организационных потребностей

. Определение организационных потребностей

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

Цели организации

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

намерение организации использовать CASE-технологию для помощи в достижении определенных целей или ожиданий (например, определенного уровня CMM или сертификации в соответствии с ISO 9001);

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

наличие у организации собственной программы совершенствования процесса разработки ПО;

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

Потребности организации

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

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

Определению потребностей организации могут помочь ответы на следующие вопросы:

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

какие процессы ЖЦ ПО дают наилучшую (и, соответственно, наихудшую) отдачу; существуют ли конкретные процессы, которые могут быть усовершенствованы путем использования новых методов и средств.

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

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

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

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

Реалистичные ожидания:

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

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

долговременное повышение продуктивности и качества деятельности организации;

ускорение и повышение согласованности разработки приложений;

снижение доли ручного труда в процессе разработки и/или эксплуатации;

более точное соответствие приложений требованиям пользователей;

отсутствие необходимости большой переделки приложений для повышения их эффективности;

улучшение реакции службы эксплуатации на требования внесения изменений и усовершенствований;

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

улучшение коммуникации между пользователями и разработчиками;

последовательное и постоянное повышение качества проектирования;

более высокие возможности повторного использования разработок;

кратковременное возрастание затрат, связанное с деятельностью по внедрению CASE-средств;

последовательное снижение общих затрат;

улучшение прогнозируемости затрат.

Нереалистичные ожидания:

отсутствие воздействия на общую культуру и распределение ролей в организации;

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

сокращение персонала, связанного с информационной технологией;

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

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

достижение абсолютной полноты и непротиворечивости спецификаций;

автоматическая генерация прикладных систем из проектных спецификаций;

немедленное снижение затрат, связанных с информационной технологией;

снижение затрат на обучение.

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

специалисты по планированию внедрения CASE-средств;

выбор и установка;

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

приобретение CASE-средств и обучение;

настройка;

подготовка документации, стандартов и процедур использования средств;

интеграция с другими средствами и существующими данными;

освоение средств разработчиками;

технические средства;

обновление версий.

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

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

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

35 Анализ рынка ПО средств

По оценке IDC объем российского рынка программного обеспечения в 2012 году составил $5 млрд. Таким образом13,9% российских IT затрат пришлась именно на закупки «софта».

Ассоциация предприятий компьютерной техники (АПКИТ) и McKinsey долю ПО в объеме российского рынка ИТ в 2012 году оценили в 20%, однако с абсолютной величиной оценки в $5 млрд. они согласны.

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

Почти до $4,7 млрд выросла выручка российских экспортеров ПО в 2012 году, но темп роста за этот период снизился. Половина от общего дохода пришлась на услуги заказной разработки для внешних компаний, готовые продукты принесли участникам рынка 40% выручки.

Объем российского рынка DLP (Data Loss Prevention) в 2012 году составил 32 млн. долларов (1,3 млрд рублей) в ценах заказчиков. что примерно на 44% больше аналогичного показателя за 2011 год.

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

Сокращение количества проектов по внедрению бизнес-приложений, вероятно, связано с изменением структуры рынка – снизилось число проектов по внедрению «базовой ERP», а инновационные решения, такие как, например, SCM или eCommerce, только на подъеме. Уже в следующем году следует ожидать стабилизации этого показателя.

Основные игроки рынка ПО считают, что к 2017 году общий объем рынка в России будет оцениваться более чем в $6 млрд., при этом $ 3 млрд. будет приходиться на продажу «облачных» сервисов.

Согласно разработанному Минэкономразвития и утвержденному в марте 2013 года, объем рынка программных средств к 2020 году составит от 462 до 582 млрд. руб. в зависимости от сценария развития экономики в целом. Таким образом, рост к 2011 году, когда объем рынка оценивался министерством в 132 млрд. руб., составит от 223% до 281%. Основной тенденцией ИТ-рынка в России на эти годы станет снижение доли аппаратных средств в его общей структуре и переход к формирование рынков ПО и услуг, считают в Минэкономразвития.