Блог О пользователеtundurundu

Регистрация

Календарь

« Сентябрь 2010  
Пн Вт Ср Чт Пт Сб Вс
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30
1 |2
 

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


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


 
Теги: по
 
 

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


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


 
Теги: по
 
 

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


Естественно, что за 70 лет своего развития техника шагнула далеко вперед, и теперь компьютеры можно спокойно уместить в кармане рубашки. Не осталось в стороне от технического прогресса и программное обеспечение для данных компьютеров. Количество и разноплановость программ, представленных сегодня на рынке высоких технологий, просто поражает. Это программное обеспечение, начиная от простой программки, позволяющей например (как ArtMoney) создавать игроку неограниченное число ресурсов и денег в компьютерных играх, заканчивая таким программным обеспечением для электронного бизнеса, как торговый терминал MetaTrader, позволяющий миллионам людей по всему миру одновременно участвовать в электронных торгах на валютном рынке Forex.


 
Теги: по
 
 

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


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


 
Теги: по
 
 

Ошибки при создании BI систем (part 6)



Ошибка № 8. Во многих организациях проблема создания BI-системы упирается в недостаток взаимопонимания, вызванный отсутствием единой терминологии. Так, например, даже в термин «доход» сотрудники различных подразделений могут вкладывать разный смысл. Начинать внедрение BI, считают в Gartner, следует с определения основных, базисных понятий (мастер-данных) и распространения этого единого «словаря» среди всех сотрудников компании.

Ошибка № 9. Последняя, и самая большая ошибка – отсутствие единой, проработанной и документированной BI-стратегии. Без нее развитие BI-системы становится лишь последовательностью узко-направленных и слабо взаимосвязанных проектов, не приближающих компанию к достижению ее стратегических целей. Gartner рекомендует создавать совместные команды из ИТ-специалистов и бизнес-пользователей, которые смогут разрабатывать, документировать, поддерживать актуальность и контролировать выполнение единой для организации BI-стратегии.


 
Теги: bi
 
 

Ошибки при создании BI систем (part 5)



Ошибка № 7. Компании не хотят финансировать создание глубоких аналитических систем, считая такие проекты слишком рискованными, длительными и дорогостоящими. Как правило, BI-проект ограничивается созданием нескольких панелей управления (dashbords), которые визуализируют некоторые бизнес-показатели. Однако такие показатели зачастую бывают «оторваны от жизни», они не отражают достижение стратегических целей компании. Gartner рекомендует ИТ-службам разрабатывать максимально наглядные отчеты, встраивая в них графики, диаграммы, пиктограммы и т.п.. Это отчасти закроет потребность бизнес-пользователей в быстром получении удобной для восприятия информации. И тогда создание глубоких, продуманных и отражающих суть бизнеса панелей управления можно будет включить в стратегический план развития BI-системы.


 
Теги: bi
 
 

Ошибки при создании BI систем (part 4)



Ошибка № 5. Аналитическая система – это не статичный инструмент для формирования отчетности, который должен быть установлен «раз и навсегда». Система должна развиваться, так, чтобы следовать за меняющимися потребностями бизнеса. В течение первого года после внедрения BI пользователи обычно начинают требовать доработок, которые, как правило, в результате затрагивают от 35% до 50% функционала системы. Следовательно, компании должны иметь четкий план развития, который будет управлять всеми изменениями, чтобы отслеживать устаревшие задачи и реализовывать текущие.

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


 
Теги: bi
 
 

Ошибки при создании BI систем (part 3)


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

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


 
Теги: bi
 
 

Ошибки при создании BI систем (part 2)


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


 
Теги: bi
 
 

Ошибки при создании BI систем (part 1)


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

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

Ошибка № 1. Ценность BI-проекта не очевидна для бизнеса. Проект инициируется ИТ-службой, а среди руководства, бизнес-пользователей, нет понимания того, какие выгоды BI-система может принести для управления. В таких проектах зачастую получается, что созданием BI-системы и сбором данных для нее занято гораздо больше сотрудников, чем использованием ее в повседневной своей работе. Специалисты рекомендуют включать в проектные команды представителей бизнеса, а также организовать специальные центры компетенции по BI, которые объединяли бы в себе необходимые технологические и бизнес-знания, а также умели бы донести эти знания до конечных пользователей.


 
Теги: bi
 
 

Business intelligence


Business intelligence (BI), возможные переводы на русский – под этим понятием чаще всего подразумевают программное обеспечение, созданное для помощи менеджеру в анализе информации о своей компании и её окружении. Существует несколько вариантов понимания этого термина.

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

Бизнес-аналитика – это инструменты, используемые для преобразования, хранения, анализа, моделирования, доставки и трассировки информации в ходе работы над задачами, связанными с принятием решений на основе фактических данных. При этом с помощью этих средств лица, принимающие решения, должны при использовании подходящих технологий получать нужные сведения и в нужное время. Таким образом, BI в первом понимании является лишь одним из секторов бизнес-аналитики в более широком втором понимании. Помимо отчётности туда входят инструменты интеграции и очистки данных (ETL), аналитические хранилища данных и средства Data Mining.

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

 


 
Теги: bi
 
 

Существует 3 уровня поддержки баз данных


.

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

Стандартная поддержка данных в течении 24 / 7 и предоставляеться Клиентам подробный отчет ежемесячно. Услуга включает в себя 2 часа дистанционного администрирования баз данных, которые могут быть использованы в связи с любым вопросом связанным с Oracle, MSSQL, PostgreSQL и MySQL. Данная опция не предусматривает отслеживания потенциальных проблем, но клиент может позвонить в рабочее время, чтобы решить любые вопросы, которые могут возникнуть в связи с работой баз данных. Это хороший вариант для небольших баз данных.

Расширенная поддержка. Отслеживается база данных в течении 24 / 7 и предоставляеться Клиентам подробный отчет о состоянии базы данных ежедневно. Услуга включает в себя 5 часов дистанционного администрирования баз данных, которые могут быть использованы для любого вопроса связанного с Oracle, MSSQL, PostgreSQL и MySQL. Данная опция не предусматривает отслеживания потенциальных проблем, но клиент может позвонить в рабочее время для решения любых сложностей с базами данных. Это хороший вариант для критически важных баз данных или для тех, в которых происходят изменения на постоянной основе.

Круглосуточная поддержка 24 / 7 - поддержка в течении рабочего дня, но в конце рабочего дня клиент может связаться с компанией по e-mail или по телефону, с гарантированным временем реагирования — в 1 час. Такая опция необходима для критически важных баз данных, которые не могут иметь перерывов в работе в нерабочее время.


 

Реляционная СУБД


Реляционная СУБД (РСУБД; иначе Система управления реляционными базами данных, СУРБД) — СУБД, управляющая реляционными базами данных.

Понятие реляционный (англ. relation — отношение) связано с разработками известного английского специалиста в области систем баз данных Эдгара Кодда (Edgar Codd).

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

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

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

Базовыми понятиями реляционных СУБД являются:

  • атрибут
  • отношение
  • кортеж

 

Сетевая СУБД


К основным понятиям сетевой модели базы данных относятся: уровень, элемент (узел), связь.

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

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

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

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


 

Иерархическая база данных


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

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

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

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


 

Система управления базами данных


Система управления базами данных (СУБД) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных.

Основные функции СУБД

·         управление данными во внешней памяти (на дисках);

·         управление данными в оперативной памяти;

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

·         поддержка языков БД (язык определения данных, язык манипулирования данными).

Обычно современная СУБД содержит следующие компоненты:

·         ядро, которое отвечает за управление данными во внешней и оперативной памяти, и журнализацию,

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

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

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

           Классификации СУБД

По модели данных

·         Иерархические

·         Сетевые

·         Реляционные

·         Объектно-ориентированные

            По степени распределённости

·         Локальные СУБД (все части локальной СУБД размещаются на одном компьютере)

·         Распределённые СУБД (части СУБД могут размещаться на двух и более компьютерах).

            По способу доступа к БД

·         Файл-серверные

·         Клиент-серверные

·         Встраиваемые


 

Приемочное тестирование или Приемо-сдаточное испытание (Acceptance Testing)



Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:

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

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

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

-продукт достиг необходимого уровня качества;

-заказчик ознакомлен с Планом Приемочных Работ (Product Acceptance Plan) или иным документом, где описан набор действий, связанных с проведением приемочного тестирования, дата проведения, ответственные и т.д.

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


 

Системное тестирование (System Testing)


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

Можно выделить два подхода к системному тестированию:

-на базе требований (requirements based)

Для каждого требования пишутся тестовые случаи (test cases), проверяющие выполнение данного требования.

-на базе случаев использования (use case based)

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


 

Интеграционное тестирование (Integration Testing)


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

Уровни интеграционного тестирования:

-Компонентный интеграционный уровень (Component Integration testing)

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

-Системный интеграционный уровень (System Integration Testing)

Проверяется взаимодействие между разными системами после проведения системного тестирования.

Подходы к интеграционному тестированию:

-Снизу вверх (Bottom Up Integration)

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

-Сверху вниз (Top Down Integration)

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

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


 

Компонентное или Модульное тестирование (Component or Unit Testing)


Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.). Обычно компонентное (модульное) тестирование проводится вызывая код, который необходимо проверить и при поддержке сред разработки, таких как фреймворки (frameworks — каркасы) для модульного тестирования или инструменты для отладки. Все найденные дефекты, как правило исправляются в коде без формального их описания в системе менеджмента багов (Bug Tracking System).

Один из наиболее эффективных подходов к компонентному (модульному) тестированию — это подготовка автоматизированных тестов до начала основного кодирования (разработки) программного обеспечения. Это называется разработка от тестирования (test-driven development) или подход тестирования вначале (test first approach). При этом подходе создаются и интегрируются небольшие куски кода, напротив которых запускаются тесты, написанные до начала кодирования. Разработка ведется до тех пор пока все тесты не будут успешными.

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

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


1 |2