31. Язык ProLog. Особенности, применение в решениях.
Пролог – это язык программирования, предназначенный для обработки символьной нечисловой информации. Особенно хорошо он приспособлен для решения задач, в которых фигурируют объекты и отношения между ними.
Пролог означает – ПРОграммирование в ЛОГике. Он был разработан на основе логического доказательства теорем и первоначально использовался для исследований в области обработки естественного языка. Пролог применяется главным образом в приложениях типа экспертных систем и интеллектуальных баз данных, он также полезен и для разработки обычных приложений. Этот язык использует более быстрые механизмы получения логического вывода, чем большинство других языков. Программирование в Прологе существенно отличается от обычного программирования и требует несколько другого подхода в написании программы. Здесь утверждаются логические отношения, а Пролог используется, чтобы определить, являются ли некоторые конструкции истинными, и если да, то каким образом был получен такой вывод. Отсюда следует декларативный стиль программирования. Пролог-программу, можно ввести в компьютер одним из двух способов: 1) при помощи текстового редактора создается файл с программой, которая затем загружается интерпретатором Пролога; 2) программа вводится во время сеанса работы с интерпретатором Пролога.
Пролог (фр. Programmation en Logique) — язык и система логического программирования, основанные на языке предикатов математической логики дизъюнктов Хорна, представляющей собой подмножество логики предикатов первого порядка.
В математической логике, дизъюнкт Хорна — дизъюнкция литералов с не более чем одним положительным литералом.
На Прологе легко определить отношение, подобное отношению родитель, указав п—ку объектов, для которых это отношение выполняется.
Аргументы отношения могут быть (среди прочего): конкретными объектами, или константами (такими, как том и энн), или абстрактными объектами, такими, как Х и Y. Объекты первого типа называются атомами. Объекты второго типа – переменными.
Пользователь может легко задавать пролог-системе вопросы, касающиеся отношений, определенных в программе.
Вопросы к системе состоят из одного или более целевых утверждений (или кратко целей). Последовательность целей, такая как родитель( X, энн), родитель( X, пат) означает конъюнкцию этих целевых утверждений:
Х - родитель Энн и Х - родитель Пат.
Пролог-система рассматривает вопросы как цели, к достижению которых нужно стремиться.
Пролог-программа состоит из предложений. Каждое предложение заканчивается точкой.
Пролог-программы можно расширять, добавляя в них новые предложения.
Прологовские предложения бывают трех типов:
Факты (clauses),
правила (predicates)
вопросы (goal).
Факты содержат утверждения, которые являются всегда, безусловно верными.
Правила содержат утверждения, истинность которых зависит от некоторых условий.
имеетребенка( X) :- родитель( X, Y).
С помощью вопросов пользователь может спрашивать систему о том, какие утверждения являются истинными.
Предложения Пролога состоят из головы и тела. Тело – это список целей, разделенных запятыми. Запятая понимается как конъюнкция.
Факты – это предложения, имеющие пустое тело. Вопросы имеют только тело. Правила имеют голову и (непустое) тело.
По ходу вычислений вместо переменной может быть подставлен другой объект. Мы говорим в этом случае, что переменная конкретизирована.
Интерпретация пролог-программы в математических терминах: пролог-система рассматривает факты и правила в качестве множества аксиом, а вопрос пользователя – как теорему, затем она пытается доказать эту теорему, т.е. показать, что ее можно логически вывести из аксиом.
2 уровня смысла программы на Прологе, а именно:
декларативный смысл (касается только отношений, определенных в программе; определяет, что должно быть результатом работы программы)
процедурный смысл (определяет как этот результат был получен)
Синтаксис и семантика
Простые объекты в Прологе – это атомы, переменные и числа.
Атомы и переменные представляют собой цепочки следующих символов:
прописные буквы А, В. ... Z
строчные буквы а, b. .... z е цифры 0. 1. 2. .... 9
специальные символы, такие как + - * / <> = : . & _
Переменные – это цепочки, состоящие из букв, цифр и символов подчеркивания. Они начинаются с прописной буквы или с символа подчеркивания:
Структурные объекты (или просто структуры) – это объекты, которые состоят из нескольких компонент.
Эти компоненты, в свою очередь, могут быть структурами. Например, дату можно рассматривать как структуру, состоящую из трех компонент: день, месяц, год. Хотя они и составлены из нескольких компонент, структуры в программе ведут себя как единые объекты. Для того чтобы объединить компоненты в структуру, требуется выбрать функтор.
Каждый функтор определяется двумя параметрами:
именем, синтаксис которого совпадает с синтаксисом атомов;
арностью - т. е. числом аргументов.
Структуры могут быть естественным образом изображены в виде деревьев. Пролог можно рассматривать как язык обработки деревьев.
Сопоставление – это процесс, на вход которого подаются два терма, а он проверяет, соответствуют ли эти термы друг другу. Если термы не сопоставимы, будем говорить, что этот процесс терпит неуспех. Если же они сопоставимы, тогда процесс находит конкретизацию переменных, делающую эти термы тождественными, и завершается успешно.
Общие правила выяснения, сопоставимы ли два терма S и Т, таковы:
Если S и Т - константы, то S и Т сопоставимы, только если они являются одним и тем же объектом.
Если S – переменная, а Т – произвольный объект, то они сопоставимы, и S приписывается значение Т.
Если S и Т – структуры, то они сопоставимы, только если S и Т имеют одинаковый главный функтор и все их соответствующие компоненты сопоставимы.
Синтаксис
Запятая между целями означает их конъюнкцию. Точка с запятой между целями означает их дизъюнкцию.
Not(…) – отрицание какого-то факта или правила.
Вопрос к системе – это всегда последовательность, состоящая из одной или нескольких целей. Для того чтобы ответить на вопрос, система пытается достичь всех целей. Достичь цели – это значит показать, что утверждения, содержащиеся в вопросе, истинны в предположении, что все отношения программы истинны. Достичь цели – это значит показать, что она логически следует из фактов и правил программы. Если вопрос содержит переменные, система должна к тому же найти конкретные объекты, которые (будучи подставленными вместо переменных) обеспечивают достижение цели. Найденные конкретизации сообщаются пользователю. Если для некоторой конкретизации система не в состоянии вывести цель из остальных предложений программы, то ее ответом на вопрос будет «нет».
Правила содержат утверждения, истинность которых зависит от некоторых условий.
имеетребенка( X) :- родитель( X, Y).
Правила имеют голову и (непустое) тело.
В общем виде:H:-P1,P2,…Pn
Н – заголовок правила, Р – тело, «:-» читается «если».
Пример: дед (А,В) :- отец (А,С), отец (С,В)
Prolog очень легко может обрабатывать рекурсивные определения. На самом деле, рекурсия - один из фундаментальных приемом программирования на Prolog. Без рекурсии с его помощью невозможно решать задачи сколько-нибудь ощутимой сложности.
Предок(Х,У):-мать(Х,У).
Предок(Х,У):-мать(Х,Z), предок(Z,Y).
Рекурсия позволяет проверить БД предков до любого уровня.
Рекурсивное определение предиката обязательно должно содержать нерекурсивную часть, иначе оно будет логически некорректным и программа зациклится.
32. Данные, информация, знания. База данных. Система управления базами данных и их функции. Модели данных. Архитектура систем баз данных. Знания и представление знаний. Проектирование баз данных. Администрирование баз данных.Перспективы развития технологий баз данных. Информационное обеспечение процесса управления.
Данные - сведения:
полученные путем измерения, наблюдения, логических или арифметических операций;
представленные в форме, пригодной для постоянного хранения, передачи и (автоматизированной) обработки.
Структура данных - организационная схема записи или массива, в соответствии с которой упорядочены данные, с тем чтобы их можно было интерпретировать и выполнять над ними определенные операции.
База данных - совокупность связанных данных, организованных по определенным правилам, предусматривающим общие принципы описания, хранения и манипулирования, независимая от прикладных программ. База данных является информационной моделью предметной области. Обращение к базам данных осуществляется с помощью системы управления базами данных (СУБД).
Система управления базами данных - комплекс программных и лингвистических средств общего или специального назначения, реализующий поддержку создания баз данных, централизованного управления и организации доступа к ним различных пользователей в условиях принятой технологии обработки данных.
СУБД характеризуется используемой моделью, средствами администрирования и разработки прикладных процессов.
СУБД обеспечивает:
описание и сжатие данных;
манипулирование данными;
физическое размещение и сортировку записей;
защиту от сбоев, поддержку целостности данных и их восстановление;
работу с транзакциями и файлами;
безопасность данных.
СУБД определяет модель представления данных.
Данные — отдельные факты, характеризующие объекты, процессы и явления предметной области, а также их свойства. Информация — наше понимание (смысл) данных.
Каждая БД имеет свой набор типов данных, но можно выделить общие: числовые (целые и дробные, разного размера), строковые (фиксированной и произвольной величины, обычные и юникод), дата и время, бинарные объекты. Специфические: логический тип, GUID, timetamp и др.
Агрегат данных — поименованная совокупность элементов данных внутри записи, рассматриваемая как единое целое. Например, агрегат данных ДАТА может рассматриваться как состоящий из элементов ДЕНЬ, МЕСЯЦ, ГОД. Т.е. агрегат данных — это то же, что и структура данных.
Структура данных: отношение (таблица), кортеж (строки таблицы), кардинальность (количество записей-кортежей), атрибут (столбцы таблицы), степень (количество атрибутов), домен (совокупность значений, из которой берутся значения для определенных атрибутов определенного отношения, то есть-тип данных) и первичный ключ.
БД – набор взаимосвязанных, поименованных данных, хранящихся на физическом носителе
БД — хранилище определенным образом структурированных данных. Были сетевыми, иерархическими. Остались реляционными :).
Состоят из таблиц, связанных между собой. Таблицы состоят из полей. Строка таблицы (точнее, соответствующая комбинация данных) — кортеж. Множество допустимых значений какого-либо поля — домен. Связи между таблицами характеризуются направлением, мощностью и правилами ссылочной целостности.
Количество кортежей в таблице — кардинальное число. Для идентификации кортежа используется первичный ключ — комбинация полей, значения которых являются уникальными в пределах всей таблицы. Также есть альтернативные ключи (тоже уникальные, но не первичные :), внешние ключи (взяты из другой таблицы). Ну и инверсные связи (унаследованные собственные ПК)
Основной принцип БД: однократный ввод и многократное использование.
Цель — отделение программы от данных.
Цель создания — структуризация и нормализация данных, устранение избыточности, ускорение и упрощение работы с данными. Язык SQL.
Средства создания: ERwin, OracleDesigner, EmbarcaderoDBManager и др. на этапе проектирования; их же средства для генерации БД; СУБД для последующей работы. Есть еще reverseengineering — создание модели по существующей БД.
Ядром любой базы данных является модель данных. С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними.
Модель данных - это совокупность структур данных и операций их обработки. Рассмотрим три основных типа моделей данных: иерархическую, сетевую и реляционную.
Иерархическая модель представляет собой совокупность элементов, расположенных в порядке их подчинения от общего к частному и образующих перевернутое по структуре дерево (граф).
К основным понятиям иерархической структуры относятся уровень, узел и связь. Узел - это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину, не подчиненную никакой другой вершине и находящуюся на самом верхнем - первом уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т. д. уровнях. Количество деревьев в базе данных определяется числом корневых записей. К каждой записи базы данных существует только один иерархический путь от корневой записи.
В сетевой структуре при тех же основных понятиях (уровень, узел, связь) каждый элемент может быть связан с любым другим элементом.
Реляционная модель данных объекты и связи между ними представляет в виде таблиц, при этом связи тоже рассматриваются как объекты. Все строки, составляющие таблицу в реляционной базе данных, должны иметь первичный ключ. Все современные средства СУБД поддерживают реляционную модель данных.
Эта модель характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных.
Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
Каждый элемент таблицы соответствует одному элементу данных.
Все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип и длину.
Каждый столбец имеет уникальное имя.
Одинаковые строки в таблице отсутствуют;
Порядок следования строк и столбцов может быть произвольным.
B настоящее время принята четырехуровневая архитектура СУБД, использующая четыре уровня восприятия и отображения информации предметной области в моделях баз данных:
инфологический уровень;
концептуальный уровень;
внешний уровень;
внутренний уровень
На каждом уровне присутствует модель данных информации, которая специфицируется с помощью языка описания данного уровня. Модель каждого уровня, представленную на языке описания, принято называть СХЕМОЙ. Перевод моделей (описаний моделей) из одного уровня в другой осуществляется с помощью трансляции или интерпретации.
B зависимости от вида представления информации различают следующие типы схем:
инфологическая схема, дающая общее информационно-логическое представление об информации предметной области;
концептуальная схема, описывающая информацию о предметной области в терминах конкретной СУБД;
внешняя схема, дающая представление информации о предметной области для прикладных программ и пользователей системы. С помощью концептуальной и внешней схемы СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по описанию внутренней схемы;
внутренняя схема, характеризующая физический уровень представления информации в конкретной СУБД. Как и в любой другой схеме ей соответствует своя модель, которая должна быть описана на языке описания данных этой СУБД.
Концепции многоуровневой информационной архитектуры стали основой современной технологии баз данных. Эти идеи связывают с опубликованным в 1975 г. отчетом рабочей группы по базам данных ANSI/X3/SPARC (Комитета по планированию стандартов Американского национального института стандартов). В данном отчете была предложена обобщенная трехуровневая модель информационной архитектуры системы базы данных, включающая концептуальный, внутренний и внешний уровни. Такая модель описывает архитектуру любой системы базы данных с той лишь оговоркой, что какие-либо ее компоненты или функции в конкретной СУБД могут иметь вырожденный характер.
Концептуальный уровень архитектуры ANSI/X3/SPARC служит для поддержки единого "взгляда" на базу данных, общего для всех ее приложений и в этом смысле независимого от них. Именно в среду концептуального уровня при проектировании базы данных отображается концептуальная модель предметной области. Представление базы данных на концептуальном уровне системы описывается концептуальной схемой базы данных.
Механизмы СУБД, поддерживающие внутренний уровень архитектуры, служат для поддержки представления базы данных в среде хранения. Это - единственный уровень информационной архитектуры, где база данных в действительности представлена полностью в
"материализованном" виде. Описание представления базы данных на внутреннем уровне архитектуры называется внутренней схемой или схемой хранения.
Наконец, пользователи базы данных имеют дело с представлениями базы данных на внешнем уровне. Описания таких представлений называются внешними схемами. В системе базы данных может одновременно поддерживаться несколько внешних схем для различных групп пользователей и/или приложений.
Следует еще раз подчеркнуть, что в отличие от хранимой базы данных, концептуальная и внешние базы данных являются виртуальными. Составляющие их данные материализуются только при обращении к ним.
Очевидно, что в предлагаемой архитектурной модели необходимо поддерживать соответствие между представлениями базы данных на смежных уровнях архитектуры системы базы данных. В модели ANSI/X3/SPARC для этой цели служат механизмы междууровневого отображения данных "внешний - концептуальный" и "концептуальный внутренний". Именно эти механизмы обеспечивают абстракцию данных в системе, определяют достижимую в системе степень независимости данных.
Знания. Представление знаний.
Знание — форма существования и систематизации результатов познавательной деятельности человека. Знание помогает людям рационально организовывать свою деятельность и решать различные проблемы, возникающие в её процессе.
Знание — в
теории искусственного интеллекта и
экспертных систем — совокупность
информации и правил вывода (у индивидуума,
общества или системы ИИ) о мире, свойствах
объектов, закономерностях процессов и
явлений, а также правилах использования
их для принятия решений. Главное отличие
знаний от данных состоит в их структурности
и активности, появление в базе новых
фактов или установление новых связей
может стать источником изменений в
принятии решений.
База знаний— это особого рода база данных, разработанная для оперирования знаниями (метаданными). База знаний содержит структурированную информацию, покрывающую некоторую область знаний, для использования кибернетическим устройством (или человеком) с конкретной целью.
База знаний — важный компонент интеллектуальной системы. Наиболее известный класс таких программ — это экспертные системы. Они предназначены для поиска способов решения проблем из некоторой предметной области, основываясь на записях БЗ и на пользовательском описании ситуации.
Простые базы знаний могут использоваться для создания экспертных систем хранения данных в организации: документации, руководств, статей технического обеспечения. Главная цель создания таких баз — помочь менее опытным людям найти уже существующее описание способа решения какой-либо проблемы.
Базы знаний и интеллектуальные системы
Двумя наиболее важными требованиями к информации, хранящейся в базе знаний интеллектуальной системы, являются:
1. достоверность конкретных и обобщённых сведений, имеющихся в базе данных, и
2. релевантность информации, получаемой с помощью правил вывода базы знаний.
Ниже перечислены некоторые из особенностей, которые могут (но не обязаны) быть у системы, оперирующей базами знаний.
Автоматическое доказательство (вывод). Способность системы выводить новые знания из старых, находить закономерности в БЗ. Часто принимается, что база знаний отличается от базы данных именно наличием механизма вывода.
Доказательство заключения. Способность системы после выдачи ответа «объяснить» ход её рассуждений, причем «по первому требованию».
Интроспекция. Нахождение противоречий, нестыковок в БЗ, контроль правильной организации БЗ.
Машинное обучение. Превращение БЗ в гибкую систему, адаптация к проблемной области. Аналогична человеческой способности «набирать опыт».
В языке Пролог базы знаний описываются в форме конкретных фактов и правил логического вывода над базами данных и процедурами обработки информации, представляющих сведения и знания о людях, предметах, фактах событиях и процессах в логической форме. В ответах на простейшие запросы к базам знаний система логического программирования Пролог выдает значения «истина» и «ложь» в зависимости от наличия соответствующих фактов.
Обобщённые сведения в языке Пролог задаются с помощью правил логического вывода, выполняющих роль определения понятий, а также логических процедур, состоящих из наборов правил логического вывода. Достоверность обобщенных сведений зависит от наличия необходимых фактов и достоверности данных в базах знаний.
Проектирование баз данных.
Проектирование баз данных — процесс создания схемы базы данных и определения необходимых ограничений целостности.
Основные задачи:
Обеспечение хранения в БД всей необходимой информации.
Обеспечение возможности получения данных по всем необходимым запросам.
Сокращение избыточности и дублирования данных.
Обеспечение целостности данных (правильности их содержания): исключение противоречий в содержании данных, исключение их потери и т.д.
Концептуальное (инфологическое) проектирование
Концептуальное (инфологическое) проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.
Логическое (даталогическое) проектирование.
Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.
Физическое проектирование.
Физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.
Администрирование БД.
Основные задачи администратора базы данных
Задачи АБД могут незначительно отличаться в зависимости от вида применяемой СУБД, но в основные задачи входит:
Проектирование базы данных.
Оптимизация производительности базы данных.
Обеспечение и контроль доступа к базе данных.
Обеспечение безопасности в базе данных.
Резервирование и восстановление базы данных.
Обеспечение целостности баз данных.
Обеспечение перехода на новую версию СУБД.
Перспективы БД.
Проблемы включения мультимедийных объектов в базы данных.
Новые парадигмы распределенного хранения информации.
Новые области применения баз данных.
Новые модели транзакций.
Простота использования баз данных и управления ими.
Информационное обеспечение процесса управления:
Процесс управления нуждается в предоставлении своевременной, достоверной и полной информации, т. е. в информационном обеспечении. Информационное обеспечение управленческой деятельности — это осуществление действии по предоставлению своевременной, достоверной и полной информации субъекту управления (руководителю) с заданной периодичностью.
Следует особо отметить, что значительная часть информации, используемой в управленческой деятельности, существуем в форме документов. Документационное обеспечение управленческой деятельности играет важнейшую роль в современных процессах управления, так как подавляющее число управленческих решений в настоящее время в обязательном порядке фиксируются на бумаге. Вместе с тем документационное обеспечение управления представляет собой отдельную и достаточно сложную отрасль современной науки и подробно рассматривается в специальной литературе. В рамках настоящего пособия мы будем рассматривать информационное обеспечение управленческой деятельности в свете использования современных информационных технологий.
Задачи информационного обеспечения процесса управления заключаются в следующем: - удовлетворение информационных потребностей управляющих органов; - определение и отбор источников информации; - правильная интерпретация и систематизация полученных данных: - проверка достоверности, полноты и непротиворечивости данных; - исключение дублирования информации: - представление данных в едином и удобном для восприятия формате; - многократное использование полученной информации; - постоянное обновление данных.
Тут можно про СППР рассказать ещё.
33. Концепция информационного хранилища. Многомерные модели данных. Метаданные. Правила организации хранилищ данных. Технологии сбора и хранения данных в информационно-аналитической системе. Информационное обеспечение поддержки принятия решений.
Концепция DW была предложена в 1990 г. Б.Инмоном. Появление этой концепции было следствием неявного осознания того факта, что существует два основных функционально различных класса систем обработки информации: Первый базируется на обработке текущего потока транзакций Второй основан на сборе и подготовке большого по объему и временному периоду (от 5 лет) массива значимой информации, предназначенного для проведения анализа данных.
Хранилища данных – это предметно-ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные с целью поддержки управления, призванные выступать в роли «единого и единственного источника истины», обеспечивающего менеджеров и аналитиков достоверной информацией, необходимой для оперативного анализа и поддержки принятия решений.
Хранилища данных представляют собой специализированные базы данных, предназначенные для хранения данных, которые редко меняются, но на основе которых часто требуется выполнение сложных запросов. Обычно они ориентированы на выполнение аналитических запросов, которые обеспечивают поддержку принятия решений для руководителей и менеджеров.
Основной принцип действия хранилища данных: Единожды занесенные в ХД данные затем многократно извлекаются из него и используются для анализа.
Многомерные базы данных представляют из себя набор объектов, которые позволяют манипулировать данными необходимым для аналитика образом.
Основными классами этих объектов являются измерения и показатели. К измерениям относятся множества значений (параметров), по которым происходит индексация данных, например, время, регионы, тип учреждения и т. п. Каждое измерение заполняется значениями из соответствующих таблиц измерений хранилища данных. Совокупность измерений определяет пространство исследуемого процесса.
Под показателями понимаются многомерные кубы данных (гиперкубы). В гиперкубе содержатся сами данные, а также агрегатные суммы по измерениям, входящим в состав показателя. Показатели составляют основное содержание МБД и заполняются в соответствии с таблицей фактов. Вдоль каждой оси гиперкуба данные могут быть организованы в виде иерархии, представляющей различные уровни их детализации. Это позволяет создавать иерархические измерения, по которым при последующем анализе данных будут осуществляться агрегирование или детализация представления данных.
Метаданные – данные о данных (упрощ.) .
Метаданные - Структурированные данные, представляющие собой характеристики описываемых сущностей для целей их идентификации, поиска, оценки, управления ими. Набор допустимых структурированных описаний, которые доступны в явном виде и предназначение которых может помочь найти объект. Термин используется в контексте поиска объектов, сущностей, ресурсов (вики.).
Загрузка данных из источников в хранилище осуществляется специальными процедурами. Для разработки, поддержки и выполнения таких процедур рекомендуется использовать специализированный инструментарий, предназначенный для автоматизации процессов извлечения данных их источников, их преобразования и загрузки в целевое хранилище. Такой инструментарий должен обеспечивать автоматическое формирование процедур загрузки на основе декларативной информации об источниках, правилах согласования и преобразования. Вся эта информация вводится администратором перемещения данных и хранится в виде метаданных в репозитории системы.
Правила организации хранилищ данных.
Для каждой таблицы можно задать шесть типов правил манипулирования данными:
обновление (Refresh),
дополнение (Append),
резервное копирование (Backup),
восстановление (Recovery),
архивирование (Archiving),
очистка (Purge).
К проектированию хранилищ данных обычно предъявляются следующие требования:
Структура данных хранилища должна быть понятна пользователям.
Должны быть выделены статические данные, которые регулярно модифицируются: ежедневно, еженедельно, ежеквартально.
Должны быть упрощены требования к запросам, с целью исключения запросов, которые могли бы требовать множественных утверждений SQL в традиционных реляционных СУБД.
Должна быть обеспечена поддержка сложных запросов SQL, которые требуют последовательной обработки тысяч или миллионов записей.
Пространственное моделирование (Dimensional)
Моделирование Dimensional сходно с моделированием связей и сущностей для реляционной модели, но отличается целями. Реляционная модель акцентируется на целостности и эффективности ввода данных. Размерная (Dimensional) модель ориентирована в первую очередь на выполнение сложных запросов к БД.
В размерном моделировании принят стандарт модели, называемый схемой звезда (star schema), которая обеспечивает высокую скорость выполнения запроса посредством денормализации и разделения данных.
Невозможно создать универсальную денормализованную структуру данных, обеспечивающую высокую производительность при выполнении любого аналитического запроса. Поэтому схема звезда строится так, чтобы обеспечить наивысшую производительность при выполнении одного самого важного запроса, либо для группы похожих запросов.
Схема звезда обычно содержит одну большую таблицу, называемую таблицей факта (fact table), помещенную в центр, и окружающие ее меньшие таблицы, называемые таблицами размерности (dimensional table), соединенными c таблицей факта в виде звезды радиальными связями.
В этих связях таблицы размерности являются родительскими, таблица факта- дочерней.
Схема звезда может иметь также консольные таблицы (outrigger table), присоединенные к таблице размерности.
Консольные таблицы являются родительскими, таблицы размерности - дочерними.
Измерение. Измерение предназначено для хранения справочной информации об объектах реального мира.
Факт.
Предназначена для хранения информации о факте, существовавшем в течение промежутка времени.
Предназначена для хранения информации об отношениях между объектами измерений, между объектами измерений и фактов, а также между фактами в течение времени. Используется для создания иерархии.
Предназначен для хранения информации о факте, существовавшем в определенный момент времени (не историзируется).
Консольная таблица предназначена для хранения информации о дополнительных атрибутах. Дополняет факты или измерения, образуя иерархию.
Прежде чем создать базу данных со схемой типа звезда, необходимо проанализировать бизнес-правила предметной области, с целью выяснения центрального вопроса, ответ на который наиболее важен. Все прочие вопросы должны быть объединены вокруг этого основного вопроса и моделирование должно начинаться с этого основного вопроса. Данные, необходимые для ответа на этот вопрос, должны быть помещены в центральную таблицу модели - таблицу факта.
Таблица факта является центральной таблицей в схеме звезда.
Схема «Снежинка»
В размерной модели главной целью является обеспечение высокой эффективности просмотра данных и выполнения сложных запросов. Схема снежинка обычно препятствует эффективности, потому, что требует объединения многих таблиц для построения результирующего набора данных, что увеличивает время выполнения запроса.
Поэтому при проектировании не следует злоупотреблять созданием множества консольных таблиц.
Когда консольные таблицы используются в размерной модели для нормализации каждой таблицы размерности, модель называется снежинка
Каждая таблица размерности может содержать неизменяемые, либо редко изменяемые данные (slowly changing dimensions).
Так как в любом хранилище данных наряду с детальными данными, извлекаемыми из транзакционных систем, хранятся и суммарные (агрегированные) показатели, такие, как, например, суммы объемов продаж по месяцам. Агрегаты хранятся в явном виде с единственной целью - ускорить выполнение запросов. Ведь, с одной стороны, в хранилище накапливается, как правило, очень большой объем данных, а с другой - аналитиков в большинстве случаев интересуют не детальные, а обобщенные показатели. И если каждый раз придется рассчитывать сотни и тысячи данных, то скорость работы хранилища будет неприемлемой.
Формирование многомерного куба
Хранилище данных служит поставщиком информации для многомерной базы данных, представляющей из себя набор объектов, которые позволяют манипулировать данными необходимым для аналитика образом. Основными классами этих объектов являются измерения и показатели.
Каждое измерение заполняется значениями из соответствующих таблиц измерений хранилища данных.
Совокупность измерений определяет пространство исследуемого процесса. Под показателями понимаются многомерные кубы данных (гиперкубы).
В гиперкубе содержатся сами данные, а также агрегатные суммы по измерениям, входящим в состав показателя.
Показатели составляют основное содержание многомерной базы данных и заполняются в соответствии с таблицей фактов.
Вдоль каждой оси гиперкуба данные могут быть организованы в виде иерархии, представляющей различные уровни их детализации. Это позволяет создавать иерархические измерения, по которым при последующем анализе данных будут осуществляться агрегирование или детализация представления данных.
Технологии сбора и хранения данных в информационно-аналитической системе.
На первом этапе данные выгружаются из истояников и помещаются в буферную зону, где устраняется структурная неоднородность данных (унифицируются длины полей, преобразуются форматы и пр.), проверяется их целостность, служебным полям присваиваются соответствующие значения, решаются задачи интеграции данных, возможно производятся какие-то первичные вычисления. На этом этапе производится также очистка информации, т.е. Из всех данных, хранящихся в источниках, выбираются лишь те, которые необходимы для дальнейшего анализа. Сведения, не прошедшие процедуры преобразования, очистки или проверки, попадают в специальную зону, где их в полуавтоматическом режиме можно исправить, дополнить.
После подобных преобразований данные попадают в хранилище. Целью построения корпоративного хранилища данных является интеграция, актуализация и согласование оперативных данных из разнородных источников для формирования единого непротиворечивого взгляда на объект управления в целом. Хранилище данных предназначено для сбора и подготовки большого по объему и временному периоду (от 5 лет) массива значимой информации, предназначенного для проведения анализа данных. Единожды занесенные в ХД данные затем многократно извлекаются из него и используются для анализа, данные в хранилище никогда не изменяются и не удаляются, при изменении каких либо сведений происходит добавление новых данных, привязанных к новому временному периоду.
Далее данные из хранилища могут извлекаться для проведения анализа. Традиционно технологии анализа делят на две категории – это технологии оперативной обработки данных или OLAP-технологии (onlineanalyticalprocessing) и интеллектуальной обработки данных или Data Mining. После чего полученная в резудбьаье анализа информация представляется в виде аналитических отчетов или информационных панелей (Dashboards) и служит для принятия решений.
Наполнение и актуализация хранилища данных происходит по определенному регламенту, как правило, в ночное время суток.
В качестве источников информации для хранилища могут использоваться базы данных внутренних транзакционных систем, информационные системы подчиненных организаций, данные, поступающие из внешних организаций.
С организационной точки зрения, данный слой включает подразделения и структуры организации всех уровней, поддерживающие базы данных оперативного доступа. Он представляет собой низовой уровень генерации информации, уровень внутренних и внешних информационных источников, вырабатывающих “сырую” информацию. Эта информация является рабочей для повседневной деятельности различных подразделений, которые ее вырабатывают и используют.
Хранение данных.
Хранилище реализуется в виде реляционной базы данных, работающей под управлением достаточно мощной реляционной СУБД. Такая СУБД должна поддерживать эффективную работу с терабайтными объемами информации, иметь развитые средства ограничения доступа, обеспечивать повышенный уровень надежности и секретности, соответствовать необходимым требованиям по восстановлению и архивации и т.п.
Обычно для достаточно большой части аналитических приложений оказывается удобной и эффективной технология интерактивного многомерного анализа и в этом случае витрина представляет собой многомерную базу данных, реализованную в архитектуре OLAP, ROLAP или HOLAP.
34. Информационная система, назначение и виды информационных систем, структура, признаки системности. Подходы к декомпозиции систем на подсистемы. Системный анализ и синтез в проектировании информационных систем. Состав функциональных и обеспечивающих систем подсистем информационной системы организации. Архитектура информационной системы. Основные принципы и технологии системной интеграции.
Тут только про декомпозицию, надо дописывать.
Одним из основных свойств ЭИС является ее делимость на подсистемы. Делимость, с точки зрения разработки и эксплуатации ЭИС, имеет ряд достоинств:
упрощение разработки и модернизации ЭИС в результате специализации групп проектировщиков по подсистемам;
упрощение внедрения и поставки готовых подсистем в соответствии с очередностью выполнения работ;
упрощение эксплуатации ЭИС вследствие специализации работников предметной области (группа сопровождения).
Все подсистемы, в зависимости от выполняемых ими действий, разделяют на функциональные и обеспечивающие, т.е. любая ЭИС состоит из 2-х частей: функциональной и обеспечивающей.
Функциональная часть ЭИС
Функциональные подсистемы ЭИС информационно обслуживают определенные виды деятельности свойственные экономической системе предприятия или ее подразделениям. Создание функциональных подсистем, аналогичных функциональным подразделениям предприятия, считается традиционным выделением подсистем.
Сейчас перешли к иному подходу, когда в основу построения п/с положена структура технологического процесса или бизнес - процесса, для каждого из которых создается своя система управления.
В настоящее время говорят о том, что и такая система недостаточно эффективна и есть концепция объединения первого и второго способа.
Интеграция функциональных подсистем в единую систему достигается за счет создания и функционирования обеспечивающих подсистем, таких как:
информационного обеспечения;
технического;
программного;
математического;
организационного;
лингвистического;
правового;
технологического обеспечения.
Функциональная подсистема представляет собой комплекс экономических задач с высокой степенью информационных обменов (связей) между задачами.
Четко сформулированная цель, сроки достижения конечных результатов и необходимые ресурсы для их достижения – все это в совокупности является задачей.
Под задачей понимается некоторый процесс обработки информации с четко определенным множеством входной и выходной информации.
Например, учет прихода материалов, оформление заказа на закупку, расчет сдельной зар.платы и т.д.
(Действия по реализации задачи – это пакет конкретных мероприятий, которые необходимо осуществить персоналу компании, чтобы выполнить задачу, т.е. необходимо конкретизировать: кто, что, сколько и когда должен сделать для достижения цели, т.е. каждому поставить конкретные задачи. Правильно поставленные задачи, позволяющие понять цели в совокупности, и представляют собой способ оптимального решения выявленных проблем.)
Состав функциональных подсистем во многом определяется:
особенностями экономической системы,
ее отраслевой принадлежностью,
формой собственности,
размером,
характером деятельности предприятия.
Функциональные подсистемы могут выделяться из системы по различным принципам:
предметному;
функциональному;
проблемному (СППР по отдельным проблемам);
деления на бизнес – процессы;
деления на технологические процессы;
смешанному (предметно-функциональному) – наиболее распространенный.
Предметный - в соответствии с предметной направленностью (чем управляем) использования ЭИС в хозяйственных процессах, выделяют п/с, соответствующие управлению отдельными видами ресурсов:
управление сбытом готовой продукции;
управление качеством продукции;
управление производством;
управление мат.-тех. Снабжением;
управление финансами;
управление персоналом и т.д.
При этом в подсистемах рассматривается решение задач на всех уровнях управления, обеспечивая интеграцию информационных потоков по вертикали.
Функциональный - для реализации отдельных функций управления выделяют следующие подсистемы:
планирование;
регулирование (оперативное управление);
учет;
анализ и т.д.
При этом в подсистемах также рассматривается решение задач на всех уровнях управления, обеспечивая интеграцию информационных потоков по вертикали.
Примером применения может служить многопользовательский комплекс «Галактика» (АО «Новый Атлант»), который включает 4 контура автоматизации (замкнутая система автоматизированных задач) в соответствии с функциями управления:
контур планирования:
контур оперативного управления;
контур учета и контроля;
контур анализа:
анализ и планирование объемов сбыта;
анализ и планирование производственных программ;
анализ и планирование объемов закупок (маркетинг);
анализ и планирование объемов денежных потоков
Проблемный – выделение п/с по отдельным проблемам в рамках СППР:
решение задач бизнес – планирования;
управления проектами и т.д.
Традиционным считается выделение подсистем по функциональному и смешанному (предметно – функциональному) принципу, т.е. разделение на подсистемы по характеру производственно – хозяйственной деятельности, которое должно соответствовать организационной структуре предприятия. Психологи считают, что коллектив людей, объединенный одной деятельностью, работают лучше.
Смешанный – выделение подсистем по функциональному принципу (управление, планирование и т.д.), а внутри подсистемы деление по предметам (управление ресурсами, планирование кадров, учет финансов и т.д.)
35. Виды проектов, понятие системного проекта. Основные этапы проектирования информационной системы и их содержание. Применяемые международные, национальные и корпоративные стандарты. Состав проектной документации на каждом из этапов.
Под проектом АИС понимается проектно – конструкторская и технологическая документация, в которой представлено описание проектных решений по созданию и эксплуатации АИС в конкретной программно – технической среде. Под проектированием АИС понимается процесс преобразования входной информации об объекте проектирования, о методах проектирования и об опыте проектирования объектов аналогичного назначения в соответствии с ГОСТом в проект АИС.
Создание системного проекта (по-другому - модели требований к будущей системе) является первой фазой разработки собственно системы автоматизации (именно, фазой анализа требований к системе), на которой требования заказчика уточняются, формализуются и документируются. Системный проект строится на основе модели «Как должно быть» и результатов обследования предприятия в части выявления требований к будущей системе.
На этапе создания системного проекта определяются:
архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между аппаратной и программной частями;
интерфейсы и распределение функций между человеком и системой;
требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент системы, их интерфейсы;
состав людей и работ, имеющих отношение к системе;
ограничения в процессе разработки (директивные сроки окончания разработки отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации).
В рамках системного проектирования должно быть осуществлено:
- определение состава, структуры и характеристик функциональных задач в рамках деятельности структурных подразделений;
определение состава и структуры программных средств автоматизации технологии решения задач с учетом существующих средств в структурных подразделениях;
определение структуры и характеристик информационного обеспечения технологии решения задач;
разработка технических решений по построению информационного обеспечения (логических структур баз данных, структур классификаторов);
разработка состава автоматизируемых процедур документооборота и автоматизируемых задач.
Системный проект должен включать:
полную функциональную модель требований к будущей системе;
комментарии к функциональной модели (спецификации процессов нижнего уровня в текстовом виде);
пакет отчетов и документов по функциональной модели, включающей характеристику объектов моделирования, перечень подсистем, требования к способам и средствам связи для информационного обмена между компонентами,
требования к характеристикам взаимосвязей системы со смежными системами, требования к функциям системы;
концептуальную модель интегрированной базы данных (пакет диаграмм);
архитектуру системы с привязкой к концептуальной модели;
предложения по оргштатной структуре для поддержки системы.
Системный проект полностью независим и отделяем от конкретных разработчиков, не требует сопровождения его создателями и может быть безболезненно передан другим лицам.
Применяются стандарты, входящие в Единую систему конструкторской документации (ЕСКД) и в Единую систему программной документации (ЕСПД).
Технический проект описывает стандарт ГОСТ 2.120-73 (ЕСКД),
Техническое задание описывает стандарт ГОСТ 19.201-78(ЕСПД) и ГОСТ 24.201-79
Эскизный проект описывает стандарт ГОСТ 2.119-73 (ЕСКД)
-
Стадии разработки
Этапы работ
Содержание работ
1. Техническое задание
Обоснование необходимости разработки программы
Научно-исследовательские работы
Разработка и утверждение технического задания
Постановка задачи
Сбор исходных материалов
Выбор и обоснование критериев эффективности и качества разрабатываемой программы.
Обоснование необходимости проведения научно-исследовательских работ.
Определение структуры входных и выходных данных.
Предварительный выбор методов решения задач.
Обоснование целесообразности применения ранее разработанных программ.
Определение требований к техническим средствам.
Обоснование принципиальной возможности решения поставленной задачи
Определение требований к программе.
Разработка технико-экономического обоснования разработки программы.
Определение стадий, этапов и сроков разработки программы и документации на неё.
Выбор языков программирования.
Определение необходимости проведения научно-исследовательских работ на последующих стадиях.
Согласование и утверждение технического задания.
2. Эскизный проект
Разработка эскизного проекта
Утверждение эскизного проекта
Предварительная разработка структуры входных и выходных данных.
Уточнение методов решения задачи.
Разработка общего описания алгоритма решения задачи
Разработка технико-экономического обоснования.
Разработка пояснительной записки.
Согласование и утверждение эскизного проекта.
3. Технический проект
Разработка технического проекта
Утверждение технического проекта
Уточнение структуры входных и выходных данных.
Разработка алгоритма решения задачи.
Определение формы представления входных и выходных данных.
Определение семантики и синтаксиса языка.
Разработка структуры программы.
Окончательное определение конфигурации технических средств.
Разработка плана мероприятий по разработке и внедрению программ.
Разработка пояснительной записки.
Согласование и утверждение технического проекта.
36. Анализ предметной области и документооборота. Подходы и модели представления предметной области организации.Традиционные и современные методы проведения предпроектного обследования. Анализ информационных процессов в проектировании информационных систем.
Традиционные медоды проведения обследования
Метод наблюдения (он применим, когда вопрос не является трудным), Метод опроса исполнителей на рабочих местах, Метод анализа материалов (является наиболее точным и обоснованным), Метод личного участия (самый эффективный, но самый долгий), Метод бесед и консультаций с руководителями, Метод анализа операций, Метод анализа представленного материала, Метод фотографии рабочего дня исполнителя работ, Метод выборочного хронометража отдельных работ, Метод документальной инвентаризации управленческих работ, Метод ведения индивидуальных тетрадей – дневников, Метод самофотографии рабочего дня, Расчетный метод, Метод аналогии.
При выборе метода обследования следует учитывать следующие критерии:
степень личного участия проектировщика в сборе материала;
временные, трудовые и стоимостные затраты на получение сведений в подразделениях.
На этапе обследования проводятся:
Тщательное обследование предприятия и составление его характеристик
Системный анализ структуры предприятия
Системный анализ методов учёта и планирования
Анализ материальных и информационных потоков
Наиболее эффективным путем изучения функционирования предприятия является:
для производственных предприятий – анализ движения материальных потоков;
для организационно – административных предприятий – анализ информационных потоков.
Выработка общих рекомендаций по улучшению системы управления на всех уровнях
Рекомендации по выбору состава автоматизируемых функций, выбору технических средств и мероприятий по подготовке объекта к внедрению автоматизированной системы
Технико-экономическое обоснование целесообразности создания автоматизированной системы (бизнес – план).
Изучению управленческих процедур предшествует общее ознакомление с предметной областью в целом, при этом рассматриваются:
Существующие производственно-технологические процессы
Материальные и информационные потоки
Организационная структура предприятия, состав подразделений, их назначение, подчинённость друг другу
Цели, функции, задачи управления.
37. Управление требованиями как часть общего управления проектом. Основные вопросы и проблемы управления требованиями. Измерение проекта. Типичные метрики процесса создания программного проекта. Модель технологической зрелости проекта.
Управление требованиями
Требованиями необходимо управлять. Управление требованиями в действительности представляет собой часть общего управления проектом. Оно связано с тремя основными вопросами.
Идентификация, классификация, организация и документирование требований.
Изменение требований (с помощью процессов, которые устанавливают способы выдвижения, согласования, проверки достоверности и документирования неизбежных изменений к требованиям).
Прослеживаемость требований (с помощью процессов, которые поддерживают отношения взаимозависимости между требованиями и другими системными артефактами, а также, собственно, между требованиями).
Идентификация и классификация требований
Постановка задачи. Телемаркетинг
Требования описываются на естественном языке, например, следующим образом.
"Система должна запланировать следующий телефонный звонок клиенту по запросу телемаркетера".
"Система должна автоматически набирать запланированный телефонный номер и одновременно отображать на экране телемаркетера информацию, включающую телефонный номер, номер клиента, имя клиента".
"В случае успешного соединения система должна отобразить вводный текст, с которым телемаркетер может обратиться к клиенту для того, чтобы завязать разговор".
Типичная система может состоять из сотен или тысяч формулировок требований, наподобие тех, что приведены выше. Для надлежащего управления таким огромным количеством требований их необходимо пронумеровать с помощью некоторой схемы идентификации {identification scheme) Схема может включать классификацию требований в виде групп, которые легче поддаются управлению.
Существует несколько методов идентификации и классификации требований.
Уникальный идентификатор— обычно последовательный номер, присвоенный вручную или сгенерированный с использованием базы данных CASE-средства (т.е. базы данных (или репозитория), в которой CASE-средства хранят артефакты, выработанные в результате анализа или проектирования).
Последовательный номер внутри иерархии документа— присваивается с учетом положения требований в пределах документа описания требований (например, седьмое требование в третьем разделе второй главы может быть пронумеровано как 2.3.7).
Последовательный номер в пределах категории требований— присваивается в дополнение к мнемоническому имени, которое обозначает категорию требований (где под категорией требований подразумевают функциональное требование, требование к данным, требования к производительности, требования к безопасности и т.д.)
Каждый из методов идентификации обладает своими за и против. Наибольшей гибкостью и защищенностью от ошибок отличаются уникальные идентификаторы, генерируемые с помощью базы данных. Базы данных обладают встроенными возможностями генерации уникальных идентификаторов для каждой новой записи данных в условиях одновременного доступа к данным со стороны многих пользователей.
Некоторые базы способны дополнительно поддерживать сопровождение нескольких версий одной и той же записи (за счет расширения значения уникального идентификатора с помощью номера версии). Наконец, базы данных могут обладать возможностями поддержки ссылочной целостности связей между артефактами моделирования, включая требования, и могут, таким образом, обеспечить необходимую поддержку управления и прослеживаемости требований.
Иерархии требований
Требования можно упорядочить в виде иерархически упорядоченной структуры, представляющей отношение родитель-потомок. Отношение родитель-потомок подобно отношению композиции. Родительское требование составлено из дочерних требований. Дочернее требование — это фактически "под-требование" родительского требования.
Иерархические отношения позволяют ввести дополнительный уровень классификации требований. Это может непосредственно отражаться (или не отражаться) в идентификационном номере (с помощью использования точки в записи составного имени). Поэтому требование, пронумерованное как 4.9, может быть девятым "потомком" "родителя" с идентификационным номером, равным 4.
Приведенный ниже набор формулировок представляет собой иерархически упорядоченные требования.
1. "Система должна запланировать следующий телефонный звонок клиенту по запросу телемаркетера".
1.1. "Система должна активизировать клавишу Next Call (Следующий звонок) при открытии формы Telemarketing Control (Управление телемаркетингом) или при завершении предыдущего вызова".
1.2. "Система должна удалить звонок из начала очереди запланированных звонков и придать ему статус текущего звонка".
1.3. Другие требования...
Иерархии требований позволяют определять требования на различных уровнях абстракции. Это согласуется с общим принципом моделирования, в соответствии с которым при переходе к более низкому уровню абстракции модели систематически обогащаются все новыми деталями. В результате для родительских требований можно сконструировать обобщенные требования, а детализированные модели можно связать с дочерними требованиями.
Управление изменениями
Требования изменяются. Требования могут изменяться, они могут быть удалены, а новые требования могут быть добавлены на любом этапе разработки. Изменения нельзя рассматривать как "удар", а вот неуправляемые изменения — это настоящий удар по проекту.
Чем дальше продвинулась разработка, тем дороже обходится внесение изменений. Фактически, минимальные затраты, необходимые для выправления проекта после внесения изменений, всегда растут и зачастую растут экспоненциально. Изменение только что сформулированных требований, которые не связаны с другими требованиями, — это простое упражнение в редактировании. Изменение тех же требований, после того как они реализованы, может обойтись чрезвычайно дорого.
Изменения могут быть связаны с субъективными ошибками, но зачастую они вызваны изменениями внутренней политики или внешними факторами, такими как:
конкурентные силы,
глобальные рынки
технологические достижения.
Вне зависимости от причин, для документирования запросов на изменения {change request) оценки влияния, оказываемого изменениями {change impact), и осуществления изменений необходима сильная стратегия управления изменениями.
Поскольку изменение требований обходится дорого, для каждого запроса на изменение необходимо создавать формальный бизнес-прецедент. Обоснованное изменение, которое не встречалось раньше, оценивается с точки зрения:
его технической осуществимости,
влияния на остальной проект
затрат.
После согласования требование включается в соответствующие модели и реализуется в программном обеспечении.
Управление изменениями, помимо прочего, включает отслеживание больших объемов взаимосвязанной информации в течение длительного периода времени. Без инструментов поддержки управление изменениями обречено. В идеале, изменения требований должны храниться и отслеживаться с помощью средств конфигурационного управления ПО, которое используется разработчиками для контроля версий моделей и программ на протяжении ЖЦ разработки. Подходящие CASE-средства должны либо обладать собственными возможностями конфигурационного управления, либо возможностями взаимодействия с автономными средствами конфигурационного управления.
Существуют следующие инструментальные средства разработки от корпорации Rational Software, поддерживающие технологический процесс управления конфигурацией и изменениями.
ClearCase помогает при управлении конфигурацией.
ClearQuest облегчает управление запросами на внесение изменений и управление состоянием и измерениями.
Кроме этого, для этих средств Rational Unified Process предлагает инструментальные наставники.
Унифицированное управление изменениями
Унифицированное управление изменениями (Unified Change Management — UCM) — это подход корпорации Rational Software к управлению разработкой программной системы (от определения требований до финального выпуска). UCM охватывает весь цикл разработки, определяет, как управлять изменениями требований, моделей проектирования, документации, компонентов, контрольных задач и исходного кода.
Одной из основных особенностей модели UCM является то, что она унифицирует виды деятельности, используемые для планирования и отслеживания прогресса проекта, а также для внесения изменений в артефакты. Модель UCM может реализовываться как с помощью процесса, так и с помощью инструментальных средств. Основоположными технологиями для UCM являются продукты ClearCase и ClearQuest.
Средство ClearCase управляет всеми артефактами, производимыми в программном проекте, включая системные артефакты и артефакты управления проектом.
Средство ClearQuest управляет задачами и дефектами проекта, запросами на улучшение проекта и предлагает инструментальные средства для составления диаграмм и отчетов о прогрессе проекта.
Измерение времени и усилий, затраченных на проект, а также принятие на вооружение других метрик (metrics) для проектных артефактов в действительности является важной частью управления проектом и процессом. Несмотря на важность, в организациях с низким уровнем технологической зрелости этой частью часто пренебрегают. Цена здесь высока. Не "измеряя" прошлого, организация не в состоянии точно планировать будущее.
Метрики обычно рассматриваются в контексте качества и сложности ПО — они применяются в отношении качества и сложности программного продукта. Используются для измерения таких характеристик качества, как корректность, надежность, продуктивность, целостность, практичность, пригодность к сопровождению, гибкость и тестопригодность. Например, надежность ПО можно оценить с помощью измерения частоты и серьезности отказов, среднего времени между отказами, точности выходных результатов, восстанавливаемости после отказов и т.д.
Другим важным применением метрик является измерение моделей разработки (продуктов разработки) на различных этапах ЖЦ ПО. Затем метрики используются для оценки эффективности процесса и повышения качества работы на различных этапах ЖЦ.
К типичным метрикам, которые применяются в отношении процесса создания ПО и могут быть приняты к использованию на различных этапах ЖЦ, относятся следующие метрики.
■ Изменчивость требований (процент требований, которые претерпевают изменения до завершения этапа спецификации требований). Эта метрика может отражать трудность получения требований от заказчиков.
■ Изменчивость требований после этапа спецификации требований. Эта метрика может указывать на низкое качество документального оформления требований.
■ Прогнозирование "мест перегрева" и "узкого горла" в системе (частота, с которой пользователи пытаются выполнить различные функции на прототипе программного продукта).
■ Объем документов, содержащих спецификации, которые генерируются CASE- средствами, и другие более детализированные метрики, взятые из репозитория CASE-системы, например, такие как количество классов в модели классов. Если их применить к нескольким прошлым проектам, затраты и время выполнения которых известны, эти метрики способны обеспечить идеальную плановую "базу данных" до прогнозирования времени и усилий, необходимых для будущих проектов.
■ Фиксирование статистики отказов, времени их появления, обнаружения и устранения. Подобная статистика может отражать доскональности системы обеспечения качеств процессов пересмотра и деятельности по тестированию ПО.
■ Среднее число тестов, после проведения которых, тестируемая компонента считается готовой для интеграции поставки заказчику. Эта метрика может отражать уровень процедур отладки, используемых программистами.
Модель технологической зрелости программного проекта
Свойства программного обеспечения
В своей статье Брукс (BrooksF.P. – автор очерков по системному программированию) определяет, что сущность программной инженерии кроется в собственных свойствах программного обеспечения, которые вызывают трудности при его создании. Эти трудности нельзя ни преодолеть за счет какого-то технологического прорыва, ни сразить «серебрянной пулей» – их можно только осознать. Свойства могут быть постоянными и случайными.
1. Постоянные свойства. Согласно Бруксу сущность программной инженерии проистекает из таких свойств ПО, как сложность, податливость, изменчивость и неосязаемость. Эти свойства ПО определяют инвариант (лат.- неизменяющийся, величину, остающуюся неизменной при любых преобразованиях), который и констатирует то, что ПО является продуктом творческого акта разработки, совершаемого или художником или ремесленником. Т.е. ПО не является результатом повторяющегося акта производства.
2. Случайные свойства. Существует еще понятие случайных свойств программной инженерии. Эти свойства не присущи ПО изначально, а привнесены извне и обусловлены вмешательством «человеческого фактора». Эти свойства порождают определенные трудности, которые можно разделить на 3 категории:
участники проекта;
процесс;
язык и средства моделирования.
Инвариант разработки ПО (неизменная составляющая процесса разработки)
Алгоритмы,
библиотеки программ,
повторно используемые классы,
программные компоненты и т.д.
представляют собой неполные, фрагментарные решения для того, что нам требуется описать при разработке информационных систем. Проблема состоит в том, чтобы собрать воедино небольшие фрагменты проблемы в виде гармоничной корпоративной системы, которая удовлетворяет требованиям сложных бизнес - процессов.
Для всякой системы, разрабатываемой «с чистого листа», необходимо сначала создать концептуальные конструкции (модели) для конечного решения, которые удовлетворяли бы специфические потребности организации. После их создания функциональные возможности программного пакета настраиваются в соответствии с концептуальными конструкциями. Маловероятно, чтобы организация могла найти программный пакет для автоматизации ее ключевых бизнес-процессов. Ключевым бизнес-процессом для телефонной компании выступает телефония, а не управление кадрами или бухгалтерский учет. То, что заставляет компанию работать (и конкурировать), должно разрабатываться «с нуля» (или переделываться из унаследованной системы). Как верно было подмечено Шиперским: «Стандартные (программные) пакеты создают лишь гладкое игровое поле, а умение играть приходит совсем с другой стороны».
Хотя, конечно, в любом случае процесс разработки должен использовать преимущества компонентной технологии. Компонента – это исполняемый программный модуль, реализующий четко определенные функции (сервисы) и коммуникационные протоколы (интерфейсы) взаимодействия с другими компонентами.
В настоящее время наибольшую популярность завоевали следующие компонентные технологии:
CORBA (Common Object Request Broker Architecture) – общаяархитектураброкераобъектныхзапросовот OMG (Object Management Group);
DCOM (Distributed Component Object Model) – Распределеннаямоделькомпонентныхобъектовот Microsoft;
EJB (EnterpriseJavaBeans) – Корпоративная технология для Java – приложений от Sun.
Участники проекта
Участниками проекта называются люди, которые заинтересованы в проекте. Под проектом в широком смысле понимается некая деловая активность, предприятие. Любой человек, интересы которого так или иначе затрагиваются системой либо сам оказывающий влияние на систему, является участником проекта.
Две основные категории участников проекта:
заказчики – пользователи и владельцы систем – уполномоченные пользователи, выбранные для общения с разработчиками, вместо реальных пользователей;
разработчики – аналитики, проектировщики, программисты и т.д.
Информационные системы – системы социальные. Они разрабатываются людьми (разработчиками) для людей (заказчиков). Успех проекта определяется социальными факторами – роль технологии второстепенна. Есть немало технически отсталых систем, которые работают и полезны заказчикам. От системы, не приносящей пользы (ожидаемой или реальной), заказчик рано или поздно откажется независимо от того, насколько блестящей она является в техническом отношении.
Основные причины провала проекта могут быть отнесены на счет участников проекта. Если причины рассматривать со стороны заказчика, то они выглядят следующим образом:
потребности заказчиков не поняты или не полностью зафиксированы;
требования заказчиков изменяются слишком часто;
заказчики не готовы выделить достаточно ресурсов под проект;
заказчики не стремятся к сотрудничеству с разработчиками;
ожидания заказчиков нереалистичны;
система оказывается бесполезной для заказчиков.
Проекты также заканчиваются неудачей потому, что разработчики оказываются не на высоте поставленных задач. По словам того же Брукса: «Великие проекты – удел великих разработчиков». Чтобы гарантировать успешную поставку системы заказчику, что более важно, обеспечить выгоды от ее использования, организация – поставщик должна в отношении разработчиков следовать некоторым простым правилам:
нанимать лучших разработчиков;
обеспечивать непрерывное обучение и повышать уровень образования своих разработчиков;
поощрять обмен информацией и общение между разработчиками так, чтобы они взаимно стимулировали друг друга;
стимулировать разработчиков, устраняя препятствия и направляя их усилия на продуктивную работу;
создавать исключительно благоприятную рабочую атмосферу (зачастую это оказывается намного более важным, чем редкие прибавки к жалованью);
увязывать личные цели разработчиков со стратегией и задачами организации;
придавать особое значение коллективной работе.
Процесс разработки проекта определяет действия и организационные процедуры, направленные на усиление совместной работы разработчиков с целью поставки высококачественного проекта. На модель процесса возлагаются следующие функции:
установление порядка выполнения действий;
определение состава и времени поставки артефактов, создаваемых в процессе разработки;
закрепление действий и артефактов за разработчиками;
введение критериев отслеживания хода проекта, измерение результатов и планирование будущих проектов.
Процесс разработки невозможно стандартизировать или систематизировать таким образом, чтобы любая организация могла его использовать автоматически.Каждая организация должны разработать собственную модель процесса или приспособить некоторый настраиваемый шаблон процесса под свои нужды. К последним относится шаблон, предлагаемый компанией RationalSoftwareCorporation, известный как RationalUnifiedProcess (RUP).
Процесс, который берет на вооружение организация, должен быть увязан с ее развитием, культурой, социальной динамикой, знаниями и опытом разработчиков, практикой руководства, ожиданиями заказчика, масштабами проектов и даже характером проблемных областей.
Поскольку все перечисленные факторы подвержены изменениям, организации могут потребоваться варианты для каждого отдельного проекта. Например, в зависимости от того, насколько разработчики хорошо знакомы с методами и средствами моделирования, в процесс может потребоваться включить специальные курсы обучения.
Но самое большое влияние на процесс оказывает масштаб проекта. Для небольших проектов (порядка десяти, или около того, разработчиков) формальный процесс может вообще не потребоваться. Такая небольшая бригада способна общаться и реагировать на изменения неформально. Для более крупных проектов неформальной коммуникативной сети может оказаться недостаточно.
Итеративный процесс разработки с пошаговым наращиванием возможностей
Современные процессы непременно являются итеративными (iterative) процессами с пошаговым наращиванием возможностей (incremental) системы.
Модели системы уточняются и преобразуются на этапах анализа, проектирования и реализации – в результате успешных итераций добавляются новые детали, при необходимости вводятся изменения и усовершенствования, а выпуски программных модулей с наращенными возможностями поддерживают высокий уровень удовлетворенности пользователей и обеспечивают обратную связь, необходимую для продолжения разработки модулей.
Успех итеративного процесса с наращиванием возможностей основывается на раннем выявлении архитектурных модулей системы. Модули должны быть:
примерно одинаковыми по размерам,
обладать сильной внутренней связью и
иметь минимум взаимных пересечений (внешних связей).
Важен также порядок реализации модулей. Некоторые модули невозможно реализовать в виде исполняемой версии, если они зависят от информации или результатов вычислений, производимых другими модулями, которые еще должны быть разработаны.
Модель технологической зрелости
Одним из наиболее известных методов оценки и усовершенствования процессов разработки является так называемая модель технологической зрелости (CapabilityMaturityModel – CMM)., которая разработана Институтом программной инженерии при Питсбургском университете Карнеги – Меллона в США. Первоначально эта модель использовалась Министерством обороны США для оценки возможностей организации в области ИТ, которые участвовали в конкурсах на получение оборонных заказов, сегодня же она находит широкое применение в ИТ – индустрии как в Америке, так и за ее пределами.
По существу СММ – это анкета, которую заполняет организация, работающая в области ИТ. После анкетирования следует верификация и аттестация процесса, в результате которых организацию относят к одному из пяти уровней модели СММ. Чем выше уровень, тем более зрелым является процесс разработки ПО в организации
Рис. Уровни зрелости процесса по модели СММ
На рисунке определены уровни, даны краткие описания основных особенностей каждого из уровней и приведены основные сферы улучшения процесса, необходимые для достижения организацией более высокого уровня технологической зрелости.
Артур (автор книги “RapidEvolutionaryDevelopment “) называет уровни зрелости «лестницей, ведущей к совершенству в области ПО». Пять ступенек на этой лестнице соответствуют:
хаосу;
управляемому проекту;
применению методов и средств организации проекта;
измерению процесса;
непрерывному повышению качества.
Как показывает опыт, на переход с одного уровня на другой уходит несколько лет.
Большинство организаций находятся на уровне 1, некоторые - на уровне 2, известно очень немного организаций находящихся на 5-ом уровне. Организация, стремящаяся достичь 2-го уровня, должна добиться положительных ответов на все приведенные ниже вопросы (а также и на некоторые другие):
имеется ли в организации канал управления и отчетности по функциям обеспечения качества ПО, отдельный от управления проектами по разработке ПО?
Введена ли для каждого проекта функция конфигурирования управления ПО, которая затрагивает его разработку?
Использует ли руководство формальный процесс для анализа каждой программной разработки прежде, чем взять на себя договорные обязательства?
Используется ли для составления календарного плана разработки ПО формальная процедура?
Собирается ли статистика в отношении программного кода и ошибок, выявленных при тестировании?
Имеется ли в распоряжении высшего руководства механизм для регулярного анализа состояния проектов по разработке ПО?
Используется ли определенный механизм для контроля изменений требований к ПО?
Помимо СММ существуют и другие модели усовершенствования процесса создания ПО. Особый интерес представляет серия стандартов по качеству ISO 9000, разработанный Международной организацией по стандартизации. СтандартыISO применяются для управления качеством и определения процесса производства качественной продукции. Стандарты носят общий характер – они применимы для любой отрасли и всех видов бизнеса, включая разработку ПО.
В основе серии стандартов ISO 9000 лежит предположение о том, что если процесс организован надлежащим образом, то и результат процесса (товар или услуга) также будут обладать надлежащим качеством. Стандарты не навязывают конкретного процесса и не уточняют его характеристики. Стандарты дают модель того, что должно быть достигнуто, однако не говорят о том, как именно должна осуществляться та или иная деятельность.
Своеобразной «лакмусовой бумажкой», позволяющей проверить, насколько организация заслуживает сертификата ISO, может служить ее способность создать качественный товар или обеспечить качественное обслуживание даже в том случае, если заменить весь персонал. С этой целью необходимо оформить документально и зафиксировать (т.е. должна быть определена письменная процедура) все виды своей деятельности, включая действия, которые необходимо выполнить в случае нарушения процесса или жалоб клиента.