1. Специальные программы лицензирования производителей по
Сегодня производители ПО идут навстречу корпоративным клиентам, предлагая им различные схемы покупки программ. Они позволяют клиентам сэкономить до 30% денежных средств и при правильном их использовании гарантируют полную легальность ПО компании. Для государственных и учебных организаций предусмотрены отдельные программы лицензирования, которые позволяют при минимальных затратах максимально использовать ПО. 2. Терминальная (дистанционная) работа с ПО на серверах
При терминальной схеме работы ПО запускается на сервере, а на клиентский компьютер передаётся только изображение. Использование терминальной службы для дистанционного доступа к ПО однозначно приводит к снижению стоимости владения им. Такой эффект достигается простотой сопровождения ПО – оно оказывается сконцентрированным в одном месте, что существенно упрощает процедуры обновления и реконфигурации ПО для всех пользователей. 3. Замена платного ПО бесплатными аналогами
Большая часть коммерческих программ имеет бесплатные альтернативы, что позволяет при достаточно большом компьютерном парке сэкономить очень значительные средства. Правда, бесплатные аналоги могут показаться менее привычными.
4. Разработка необходимого по на заказ
Включает разработку специализированного программного обеспечения в соответствии с требованиями заказчика, проектирование, создание и внедрение комплексных информационных систем управления предприятием.
Пользовательский интерфейс и его эргономика. Интерфейс ис как сценарий поведения пользователя. Роль графического дизайна в ис.
Если мы говорим о людях, то пользователь информационной системы (англ. «Information system user») – это лицо, группа лиц или организация, прибегающие к услугам информационной системы для получения необходимой им информации или решения других задач.
Пользовательский интерфейс – совокупность средств и методов, при помощи которых пользователь взаимодействует с различными, чаще всего сложными, машинами, устройствами и аппаратурой.
С точки зрения категорий пользователей можно выделить:
интерфейс конечного пользователя, обеспечивающий выбор объектов и методов из предлагаемого (чаще всего фиксированного) набора;
интерфейс системного администратора, обеспечивающий расширенный набор средств и позволяющий изменять или создавать новые интерфейсные объекты или сценарии.
Особенности человеческого восприятия
Локус внимания
В любой момент времени человек может сосредоточить свое внимание только на одном предмете. Это может быть какой-то объект реального мира (например, лист бумаги) определенная область экрана или окна, а может и какой-нибудь процесс «в уме» (например, когда человек обдумывает свои действия или что-то рассчитывает). Предмет, на котором сосредоточено внимание человека, будем называть локусом его внимания. С локусом внимания связано как минимум две особенности человеческого восприятия.
При периодическом переключении внимания, например, с рабочей области документа на уведомления об ошибках, эффективность работы снижается. Это связано с тем, что при смене локуса теряется связанная с ним «оперативная» информация, которая содержится в кратковременной памяти. Соответственно, при возвращении к прежнему локусу эту информацию необходимо каким-то образом восстанавливать.
При пристальном сосредоточении внимания все события вне локуса могут игнорироваться или просто оставаться незамеченными.
Формирование привычек
При совершении некоторых действий раз за разом человек перестает уделять внимание их выполнению — действия совершаются неосознанно. Таким образом, у человека формируются привычки — полезные навыки, позволяющие быстрее выполнять рутинные операции. Интерфейс может как способствовать вырабатыванию привычек, так и препятствовать этому — в зависимости от того, могут ли в нем рутинные действия выполняться единообразно.
Привычка может оказаться и вредной. Типичный пример — подтверждение выполнения команды в диалоговом окне. Если диалоговое окно возникает каждый раз при выполнении рутинных операций, то в конце концов человек перестает читать текст в этом окне (и это справедливо не только для таких «классических» пользователей как бухгалтеры или секретарши, но и для самих программистов). Поэтому если похожее окно возникнет, когда пользователь отдал команду по ошибке, то он, не задумываясь, подтвердит команду, потому что это вошло у него в привычку.
Принципы построения интерфейсов
Сохранность пользовательских данных
Назначением большинства программ в конечном итоге является (должно являться) упрощение работы, выполняемой человеком. Пользовательские данные — это результат работы человека. Если этот результат будет утерян, работу придется выполнять снова, что нельзя назвать упрощением. Поэтому любая программа должна обеспечивать сохранность данных пользователя, будь то простое текстовое сообщение, 3D-модель или научная статья. О важности данных может судить только сам пользователь, но никак не программа, с которой он взаимодействует. Путей для обеспечения сохранности данных может быть много: это и автоматическое сохранение любых изменений, и обратимость операций, и создание резервного архива (backup).
Формирование команд по принципу «объект -> действие»
При формировании многих команд может применяться одна из двух моделей:
1. Сначала указать объект, а затем действие, которое необходимо совершить с этим объектом (модель «объект-действие»).
2. Сначала указать действие, а затем объект, к которому следует применить это действие (модель «действие-объект»).
Предпочтительной является первая модель — «объект-действие». Во-первых, она исключает многие модальные ошибки, поскольку переключение действия обычно сопровождается переключением режимов работы. Во-вторых, она проще для восприятия человеком, поскольку, как правило, локус внимания пользователя уже находится на объекте, когда возникает необходимость выполнить какое-то действие с этим объектом.
Использование второй модели — «действие-объект» — тоже допустимо, но только в тех случаях, когда ее применение достаточно аргументировано.
Монотонность
Привычки могут формироваться у человека лишь в том случае, если каждое действие можно выполнить всегда одним и тем же образом. Интерфейс можно назвать монотонным, когда каждое элементарное действие в нем можно выполнить ровно одним способом (т.е. жестом). Часто для одного и того же действия предусматривается несколько способов выполнения: через меню, сочетанием клавиш, щелчком мыши и т.п. Однако подобная практика затрудняет формирование привычек, поскольку пользователь должен каждый раз выбирать, каким способом выполнить действие. И лишь когда он станет выполнять действие всегда только одним способом, т.е. сам сведет немонотонный интерфейс к монотонному, у него появится возможность формировать привычку для выполнения этого действия. Если сразу спроектировать интерфейс так, чтобы он был монотонным, то это сократит время обучения пользователя. Исключение, вероятно, может составлять случай, когда проектируется интерфейс для пользователей с разными устройствами. Например, часть пользователей пользуется настольным ПК с клавиатурой и мышью, а часть — планшетным ПК с сенсорным экраном. Однако и в этом случае стоит подумать о других альтернативах, например, нахождении способа взаимодействия, который будет применим на разных устройствах, или разработке разных версий интерфейса для разных устройств. Иначе есть риск создать интерфейс, который не будет устраивать ни ту, ни другую группу пользователей.
Видимость
Интерфейс программы должен своевременно информировать пользователя о:
1) текущем состоянии системы и смене состояния в результате действий пользователя;
2) способах управления и воздействия на систему.
В случае отсутствия информации о состоянии системы возрастает количество ошибок, допускаемых при работе с программой. Информирование пользователя о состоянии системы включает в том числе и предоставление различного рода обратной связи: подсветку объекта, на который наведен указатель мыши, индикацию о том, что действие пользователя воспринято программой и находится в обработке и т.п.
Состоятельность
Элемент управления является не только видимым, но и состоятельным, если по одному его виду пользователь может определить, как именно с ним взаимодействовать: кнопки — нажимать, полосы прокрутки — перемещать, и т.п. Таким образом, принцип состоятельности дополняет принцип видимости.
Взаимодействие с подобными по виду элементами и объектами должно происходить всегда единообразно, иначе будут возникать ошибки, связанные с модальностью интерфейса. Примером может являться интерфейс, в котором в одной ситуации элемент, выглядящий как кнопка, необходимо нажать, а в другой ситуации элемент, выглядящий подобным образом, необходимо переместить.
Закон фиттса
Время достижения цели прямо пропорционально дистанции до цели и обратно пропорционально размеру цели.
Правила проектирования интерфейса:
Использование горячих клавиш
У пользователя должна быть возможность отменить введенные данные, вернуться на предыдущий шаг или вообще прервать выполнение начатой операции.
Всплывающие подсказки
Предусмотреть быстрый доступ к функционалу программы
Индивидуальная настройка интерфейса (размер, цвет текста, расположение кнопок)
Если компьютер выполняет какие-то длительные действия необходимо показать пользователю, что ПК работает, а не завис.
Сохранение некоторых данных в памяти компьютера (при заполнении анкеты пользователь вводит фио, адрес и если эти данные потребуются в другом месте они должны заполниться автоматически)
Использовать списки и меню (например чтобы пользователь заполнял не код операции, а выбрал из списка саму операцию)
Визуальные подсказки (Изменять форму курсора в зависимости от типа действия)
Использовать панель инструментов (когда пользователи освоят программу они им понадобятся)
Вывести на панель только основные функции остальные скрыть (например под стрелкой)
При переходе из старой системы в новую сохранить контрольные точки в интерфейсе
по дисциплине «Базы данных»
Информация и данные сходства и различия. Технологии баз данных. Модели данных. Принципы построения баз данных и управления ими. Реляционные базы данных (СУБД). Совокупная стоимость владения, решения по оптимизации. Сетевые СУБД. Облачные технологии.
Термин данные происходит от слова data - факт, а информация (informatio) означает разъяснение, изложение, т.е. сведения или сообщение. Данные - это совокупность сведений, зафиксированных на определенном носителе в форме, пригодной для постоянного хранения, передачи и обработки. Преобразование и обработка данных позволяет получить информацию. Информация - это сведения об объектах и явлениях окружающей среды, их параметрах, свойствах и состоянии, которые уменьшают имеющуюся о них степень неопределенности, неполноты знаний. Информация - это результат преобразования и анализа данных.
Отличие информации от данных состоит в том, что данные - это фиксированные сведения о событиях и явлениях, которые хранятся на определенных носителях, а информация появляется в результате обработки данных при решении конкретных задач. Например, в базах данных хранятся различные данные, а по определенному запросу система управления базой данных выдает требуемую информацию. База данных (БД) - именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области (ПО).
С понятием базы данных тесно связано понятие системы управления базой данных. Это комплекс программных средств, предназначенных для создания структуры новой базы, наполнения ее содержимым, редактирования содержимого и визуализации информации. Под визуализацией информации базы понимается отбор отображаемых данных в соответствии с заданным критерием, их упорядочение, оформление и последующая выдача на устройство вывода или передача по каналам связи.
Основными объектами любой базы данных являются ее таблицы. Простейшая база данных имеет хотя бы одну таблицу.
Структуру двумерной таблицы образуют столбцы и строки. Их аналогами в структуре простейшей базы данных являются поля и записи. Если записей в таблице пока нет, значит, ее структура образована только набором полей. Изменив состав полей базовой таблицы (или их свойства), мы изменяем структуру базы данных и, соответственно, получаем новую базу данных.
Свойства полей базы данных
• Имя поля — определяет, как следует обращаться к данным этого поля при автоматических операциях с базой.
• Тип поля — определяет тип данных, которые могут содержаться в данном поле.
• Размер поля — определяет предельную длину (в символах) данных, которые могут размещаться в данном поле.
• Формат поля — определяет способ форматирования данных в ячейках, принадлежащих полю.
• Маска ввода — определяет форму, в которой вводятся данные в поле (средство автоматизации ввода данных).
• Значение по умолчанию
• Условие на значение
• Обязательное поле.
Ядром любой БД является модель данных, с помощью которой могут быть представлены объекты, предметные области и взаимосвязи между ними.
Модель данных – совокупность структур данных и операции их обработки.
Рассмотрим три основных типа моделей данных: иерархическую, сетевую и реляционную.
И
ерархическая
модель
представляет собой совокупность
элементов, расположенных в порядке их
подчинения от общего к частному и
образующих перевернутое по структуре
дерево (граф). (файловая система и реестр
винды, )
Поиск данных всегда начинается с корня. Затем производится спуск с одного уровня на другой пока не будет достигнут искомый уровень. Перемещения от одной записи к другой осуществляются с помощью ссылок.
Основное достоинство иерархических баз данных состоит в экономичном использовании ресурсов памяти и соответственно высоком быстродействии системы. Недостатком является жесткие связи и при изменении модели возникает необходимость в перепрограммировании БД.
В сетевой модели данных понятия главного и подчиненных объектов несколько расширены. Любой объект может быть и главным и подчиненным (в сетевой модели главный объект обозначается термином «владелец набора», а подчиненный — термином «член набора»). Один и тот же объект может одновременно выступать и в роли владельца, и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей.
Использование иерархической и сетевой моделей ускоряет доступ к информации, но требует значительных ресурсов памяти, так как каждый элемент данных содержит ссылки на другие элементы.
Реляционная модель(РМД) была разработана в начале 1970-х годов Эдгаром Ф. Коддом. Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
каждый элемент таблицы — один элемент данных
все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.)
каждый столбец имеет уникальное имя
одинаковые строки в таблице отсутствуют
порядок следования строк и столбцов может быть произвольным
12 правил Кодда
правило 0: Основное правило (Foundation Rule): Реляционная СУБД должна быть способна полностью управлять базой данных, используя связи между данными:
Чтобы быть реляционной системой управления базами данных (СУБД), система должна использовать исключительно свои реляционные возможности для управления базой данных.
правило 1: Явное представление данных (The Information Rule):
Информация должна быть представлена в виде данных, хранящихся в ячейках. Данные, хранящиеся в ячейках, должны быть атомарны. Порядок строк в реляционной таблице не должен влиять на смысл данных.
правило 2: Гарантированный доступ к данным (Guaranteed Access Rule):
Доступ к данным должен быть свободен от двусмысленности. К каждому элементу данных должен быть гарантирован доступ с помощью комбинации имени таблицы, первичного ключа строки и имени столбца.
правило 3: Полная обработка неизвестных значений (Systematic Treatment of Null Values):
Неизвестные значения NULL, отличные от любого известного значения, должны поддерживаться для всех типов данных при выполнении любых операций. Например, для числовых данных неизвестные значения не должны рассматриваться как нули, а для символьных данных — как пустые строки.
правило 4: Доступ к словарю данных в терминах реляционной модели (Active On-Line Catalog Based on the Relational Model):
Словарь данных должен сохраняться в форме реляционных таблиц, и СУБД должна поддерживать доступ к нему при помощи стандартных языковых средств, тех же самых, которые используются для работы с реляционными таблицами, содержащими пользовательские данные.
правило 5: Полнота подмножества языка (Comprehensive Data Sublanguage Rule):
Система управления реляционными базами данных должна поддерживать хотя бы один реляционный язык, который
(а) имеет линейный синтаксис,
(б) может использоваться как интерактивно, так и в прикладных программах,
(в) поддерживает операции определения данных, определения представлений, манипулирования данными (интерактивные и программные), ограничители целостности, управления доступом и операции управления транзакциями (begin, commit и rollback).
правило 6: Возможность модификации представлений (View Updating Rule):
Каждое представление должно поддерживать все операции манипулирования данными, которые поддерживают реляционные таблицы: операции выборки, вставки, модификации и удаления данных.
правило 7: Наличие высокоуровневых операций управления данными (High-Level Insert, Update, and Delete):
Операции вставки, модификации и удаления данных должны поддерживаться не только по отношению к одной строке реляционной таблицы, но по отношению к любому множеству строк.
правило 8: Физическая независимость данных (Physical Data Independence):
Приложения не должны зависеть от используемых способов хранения данных на носителях, от аппаратного обеспечения компьютеров, на которых находится реляционная база данных.
правило 9: Логическая независимость данных (Logical Data Independence):
Представление данных в приложении не должно зависеть от структуры реляционных таблиц. Если в процессе нормализации одна реляционная таблица разделяется на две, представление должно обеспечить объединение этих данных, чтобы изменение структуры реляционных таблиц не сказывалось на работе приложений.
правило 10: Независимость контроля целостности (Integrity Independence):
Вся информация, необходимая для поддержания целостности, должна находиться в словаре данных. Язык для работы с данными должен выполнять проверку входных данных и автоматически поддерживать целостность данных.
правило 11: Дистрибутивная независимость (Distribution Independence):
База данных может быть распределённой, может находиться на нескольких компьютерах, и это не должно оказывать влияние на приложения. Перенос базы данных на другой компьютер не должен оказывать влияния на приложения.
правило 12: Согласование языковых уровней (The Nonsubversion Rule):
Если используется низкоуровневый язык доступа к данным, он не должен игнорировать правила безопасности и правила целостности, которые поддерживаются языком более высокого уровня.
Совокупная стоимость владения (англ. Total cost of ownership, TCO) — это методика, предназначенная для определения затрат на информационные системы (и не только), рассчитывающихся на всех этапах жизненного цикла системы.
Совокупная стоимость владения - сумма материальных и временных затрат, связанных с приобретением, развертыванием, конфигурированием и обслуживанием программного и аппаратного обеспечения. Совокупная стоимость владения включает затраты: - на обновление программного обеспечения и оборудования; - на обучение, обслуживание, администрирование и техническую поддержку.
Упрощенная методика расчета TCO Методика позволяет понять структуру затрат на информационные технологии. Все затраты разделяются на прямые и косвенные.
Прямые затраты — явные — составляют затраты, проходящие через бухгалтерию (заработная плата сотрудников, закупки оборудования и программного обеспечения, оплата услуг консалтинга и др.).
Непрямые затраты — неявные — выявляются сложнее. В них включаются затраты на устранение сбоев или проблем на компьютерах, простои рабочего времени, командировочные, затраты на предотвращение рисков и затраты на устранение их последствий, затраты на обучение персонала и другие подобные затраты.
Обычно неявные затраты превышают явные.
Говоря про TCO применительно к СУБД, можно выделить следующие составные части:
Стоимость самой СУБД, состоящая из первоначального платежа за приобретение лицензий и ежегодных платежей за поддержку от производителя.
Стоимость сопровождения СУБД, которая определяется заработной платой сотрудников, ответственных за обслуживание и администрирование баз данных.
Стоимость платформы для разворачивания СУБД — серверного оборудования и операционной системы. Эта стоимость также складывается из первоначального платежа за приобретение оборудования и лицензий на ОС, а также ежегодных платежей за поддержку от производителей.