shpory_IS

1.Основные понятия предметной области "информационные системы". Жизненный цикл программного продукта.

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

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

Информация – изменение объема и структуры знаний о некоторой предметной области, воспринимающееся системой независимо от формы и способа представления знаний

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

Метаданные (знания) –это и сами данные и методы их обработки (интерпретации), хранящиеся в одной базе.

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

Факторы оценки качества ИС:

+ Цена и экономическая эффективность (стоимость владения)

+ Технологичность в эксплуатации (настраиваемость, адаптивность, возможности)

+ Легкость освоения и качество технической документации.

Главная задача ИС: своевременное обеспечение пользователей информационными ресурсами, представленными в максимально адекватном формате.

ЖЦ ПО — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.

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

Процессы жизненного цикла ПО

Основные:

Приобретение, Поставка, Разработка, Эксплуатация, Сопровождение

Вспомогательные:

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

Организационные:

Управление, Создание инфраструктуры, Усовершенствование, Обучение.

Модели жизненного цикла ПО

Каскадная модель

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

Этапы:

Формирование требований; Проектирование; Реализация; Тестирование; Внедрение; Эксплуатация и сопровождение.

Спиральная модель-основана на классическом цикле Деминга PDCA (plan – планируй, do – исполняй, check – проверяй, act – активно участвуй в исполнении). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.

На каждой итерации оцениваются:

риск превышения сроков и стоимости проекта; необходимость выполнения ещё одной итерации; степень полноты и точности понимания требований к системе; целесообразность прекращения проекта.

Итерационная модель

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

2.Идеи и примеры использования ER-моделей.

Модель "сущность-связь" (ER-модель) (англ. Entity-relationship model или entity-relationship diagram) - модель данных, которая позволяет описывать концептуальные схемы с помощью обобщенных конструкций блоков. ER-модель - это мета-модель данных, то есть средство описания моделей данных. ER-модель удобна при проектировании информационных систем, баз данных, архитектур компьютерных приложений и других систем (моделей). С помощью такой модели выделяют существенные элементы (узлы, блоки) модели и устанавливают связи между ними. Модель "сущность-связь" основывается на некой важной семантической информации о реальном мире и предназначена для логического представления данных. Она определяет значение данных в контексте их взаимосвязи с другими данными. Важным для нас является тот факт, что из модели "сущность-связь" могут быть порождены все существующие модели данных (иерархическая, сетевая, реляционная, объектная), поэтому она является наиболее общей.

Типичные примеры использования ER-модели данных: IDEF1x (ICAM DEFinition Language) и dimensional modelling.

Сущность - это класс однотипных объектов, информация о которых должна быть учтена в модели. Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. 

Экземпляр сущности - это конкретный представитель данной сущности.

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

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

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

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

Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней.

3.Информационные системы в современном бизнесе: классификация, области применения, решаемые задачи

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

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

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

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

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

в) по характеру обработки данных ИС: информационно-поисковые и информационно-решающие.

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

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

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

г) В зависимости от сферы применения различают следующие классы ИС.

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

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

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

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

д) В зависимости от уровня управления, на котором система используется, ИС делятся на:

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

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

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

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

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

4.Идеи и примеры использования SADT-моделей.

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

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

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

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

в) уникальность меток и наименований;

г) разделение входов и операций управления;

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

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

Результат применения метода SADT - модель, которая состоит из диаграмм, фрагментов текстов и глоссария со ссылками друг на друга. Все функции и интерфейсы представляются диаграммами в виде блоков и дуг. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, указывается с левой стороны блока, а результаты выхода - с правой стороны. Механизм, осуществляющий операцию (человек или автоматизированная система), задается дугой, входящей в блок снизу.

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

5.Основная функциональность и технологические особенности проектирования OLTP-систем

OLTP (Online Transaction Processing) — обработка транзакций в реальном времени. Способ организации БД, при котором система работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа.

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

Использование

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

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

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

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

Требования

Сильно нормализованные модели данных;

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

Обработка данных в реальном времени.

Недостатки

OLTP-системы оптимизированы для небольших дискретных транзакций. А вот запросы на некую комплексную информацию (к примеру поквартальная динамика объемов продаж по определённой модели товара в определённом филиале), характерные для аналитических приложений (OLAP), породят сложные соединения таблиц и просмотр таблиц целиком. На один такой запрос уйдет масса времени и компьютерных ресурсов, что затормозит обработку текущих транзакций

6.Идеи и примеры использования DFD-моделей.

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

Основу методологии DFD составляет графический язык описания процессов. Авторами одной из первых графических нотаций DFD (1979 г.) стали Эд Йордан (Yourdon) и Том де Марко (DeMarko).

В настоящее время наиболее распространенной является нотация Гейна-Сарсона (Gane-Sarson).

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

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

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

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

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

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

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

7.Основная функциональность и технологические особенности проектирования OLAP-систем

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

Действие OLAP

Причина использования OLAP для обработки запросов — это скорость. Реляционные БД хранят сущности в отдельных таблицах, которые обычно хорошо нормализованы. Эта структура удобна для операционных БД (системы OLTP), но сложные многотабличные запросы в ней выполняются относительно медленно.

OLAP делает мгновенный снимок реляционной БД и структурирует её в пространственную модель для запросов. Заявленное время обработки запросов в OLAP составляет около 0,1 % от аналогичных запросов в реляционную БД.

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

OLAP-куб содержит в себе базовые данные и информацию об измерениях (агрегатах). Куб потенциально содержит всю информацию, которая может потребоваться для ответов на любые запросы.

Вместе с базовой концепцией существуют три типа OLAP:

+ OLAP со многими измерениями (Multidimensional OLAP — MOLAP),

+ реляционный OLAP (Relational OLAP — ROLAP)

+ гибридный OLAP (Hybrid OLAP — HOLAP).

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

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

хранения агрегатов создаются дополнительные реляционные таблицы. HOLAP использует реляционные таблицы для хранения базовых данных и многомерные таблицы для агрегатов.

Особым случаем ROLAP является ROLAP реального времени (Real-time ROLAP — R-ROLAP). В отличие от ROLAP в R-ROLAP для хранения агрегатов не создаются дополнительные реляционные таблицы, а агрегаты рассчитываются в момент запроса. При этом многомерный запрос к OLAP-системе автоматически преобразуется в SQL-запрос к реляционным данным.

Каждый тип хранения имеет определённые преимущества, хотя есть разногласия в их оценке у разных производителей. MOLAP лучше всего подходит для небольших наборов данных, он быстро рассчитывает агрегаты и возвращает ответы, но при этом генерируются огромные объёмы данных. ROLAP оценивается как более масштабируемое решение, использующее к тому же наименьшее возможное пространство. При этом скорость обработки значительно снижается. HOLAP находится посреди этих двух подходов, он достаточно хорошо масштабируется и быстро обрабатывается. Архитектура R-ROLAP позволяет производить многомерный анализ OLTP-данных в режиме реального времени.

Сложность в применении OLAP состоит в создании запросов, выборе базовых данных и разработке схемы, в результате чего большинство современных продуктов OLAP поставляются вместе с огромным количеством предварительно настроенных запросов. Другая проблема — в базовых данных. Они должны быть полными и непротиворечивыми.

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

8.Идеи и примеры использования SwimLine-моделей.

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

1. "Дорожка"может представлять собой однородные объекты: (сотрудника, отдел, службу, внешнего контрагента и т.д.

2. Каждая функция обязательно размещается на "дорожке".

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

4. "Дорожки'определяются из множества IDEF-дуг "Механизмы".

5. IDEF-дуга "Механизм"заменяется на дополнительную исходящую дугу функции.

6. Группировка функций в фазы процесса производится по основным функциям менеджмента, и являются отражением уровней вложения IDEF-схемы.

7. На схему обязательно переносятся "Внешние источники данных".

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

9.База данных как ядро современной информационной системы. Типы СУБД. Средства моделирования и проектирования баз данных в реляционной модели.

База данных — совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных.

База данных — некоторый набор перманентных (постоянно хранимых) данных, используемых прикладными программными системами какого-либо предприятия.

База данных предназначена для хранения и накопления данных и их обработки.

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

Модели организации информационного содержимого базы данных

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

+ Иерархическая модель данных-строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии, – подчиненными. Между главным и подчиненными объектами устанавливается взаимосвязь «один ко многим». Для каждого экземпляра главного объекта может быть несколько экземпляров подчиненных типов объектов. Узлы и ветви образуют иерархическую древовидную структуру. Узел - совокупность атрибутов, описывающих объект.

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

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

+ Сетевая модель данных

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

Достоинства: эффективное использование затрат памяти (ресурсы) при манипулировании данными; использовать для решения многих задач из–за различных связей.

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

+ Реляционная модель данных

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

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

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

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

Недостатки: отсутствие стандартных средств идентификации каждой отдельной записи.

+ Постреляционная модель данных

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

В этой модели не требуется выполнять операции соединения двух таблиц.

Достоинства: обеспечивает высокую наглядность представления информации и повышенную эффективность ее обработки.

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

+ Многомерная модель данных

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

Недостатки: громоздкость (что делает ее не пригодной для организации БД небольших объемов)

Объектно–ориентированная модель. База данных в объектно–ориентированной модели представляет хранилище объектов, которые можно использовать совместно различными пользователями и приложениями.

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

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

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

По модели данных (Иерархические, Сетевые, Реляционные, Объектно-ориентированные)

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

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

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

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

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

Примеры: Microsoft Access, Visual FoxPro.

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

Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно. Недостаток - повышенные требования к серверу. Достоинства: более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность.

Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР.

10.Идеи и примеры использования IDEF3-моделей.

IDEF3 — методология моделирования и стандарт документирования процессов, происходящих в системе. IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие. IDEF3 состоит из двух методов. Process Flow Description (PFD) - Описание технологических процессов, с указанием того, что происходит на каждом этапе технологического процесса. Object State Transition Description (OSTD) - Описание переходов состояний объектов, с указанием того, какие существуют промежуточные состояния у объектов в моделируемой системе.

Модель, выполненная в IDEF3, может содержать следующие элементы:

+ Единицы работы (Unit of Work) — основной компонент диаграммы IDEF3 близкий по смыслу к работе IDEF0.

+ Связи (Links) — Связи, изображаемые стрелками, показывают взаимоотношения работ. В IDEF3 различают три типа связей:

- Связь предшествования (Precedence) — показывает, что прежде чем начнется работа-приемник, должна завершиться работа-источник. Обозначается сплошной линией.

-Связь отношения (Relational) — показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией.

+ Поток объектов (Object Flow) — показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками.

+ Перекрестки (Junctions) — перекрестки используются в диаграммах IDEF3, чтобы показать ветвления логической схемы моделируемого процесса и альтернативные пути развития процесса могущие возникнуть во время его выполнения. Различают два типа перекрестков:

- Перекресток слияния (Fan-in Junction) — узел, собирающий множество стрелок в одну, указывая на необходимость условия завершенности работ-источников стрелок для продолжения процесса.

o Перекресток ветвления (Fan-out Junction) — узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно.

11.Методы проектирования информационной системы: современные подходы, основные этапы. Методологические стратегии.

Все эти методы условно можно разделить на три больших класса:

+ Структурно-функциональные;

+ Виртуальные (универсальные);

+ Функционально-технологические;

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

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

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

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

Функционально-технологические методы характеризуются:

+ Целостным подходом к анализу и синтезу системной архитектуры ИС и реализуемых в этой архитектуре организационных и управленческих функций;

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

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

+ Учетом физических и информационных связей между элементами ИС;

+Учетом взаимосвязей создаваемой ИС с внешней средой.

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

+ I этап — предпроектный (обследование, составление отчета, технико-экономического обоснования и технического задания);

+ II этап — проектный (составление технического и рабочего проектов);

+ III этап — внедрение (подготовка к внедрению, проведение опытных испытаний и сдача в программную эксплуатацию);

+ IV этап — анализ функционирования (выявление проблем, внесение изменений в проектные решения и существующие АИС и АИТ).

12.Идеи и примеры использования диаграмм классов.

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

Класс

Класс определяет атрибуты и методы набора объектов. Все объекты класса имеют одинаковое поведение и одинаковый набор атрибутов.

В UML классы представлены прямоугольниками с именем класса, которые могут отображать атрибуты и операции класса, помещённые внутри прямоугольника.

Атрибуты

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

Методы

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

13.Выявление и анализ требований. Методы описания бизнес-процессов.

В процессе проведения интервью предлагается выделить три подчиненных процесса: подготовку, проведение интервью (опроса) и завершение.

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

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

Анкетирование

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

Наблюдение

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

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

Самостоятельное описание требований

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

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

Анализ требований

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

МЕТОДЫ ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ:

Текстовый.

Последовательное описание бизнес-процесса. Пример: «Отдел продаж составляет договор и согласует его с юридическим отделом».

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

Табличный.

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

Графический.

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

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

14.Основные контуры (разделы) стандарта PM BOK Guide

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

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

Группа процессов инициации

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

Группа процессов планирования

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

Группа процессов исполнения

Объединяет человеческие и другие ресурсы для выполнения плана управления проектом данного проекта.

Группа процессов мониторинга и управления

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

Группа завершающих процессов

Формализует приемку продукта, услуги или результата и подводит проект или фазу проекта к правильному завершению.

Области знаний

Рассматривает области знаний по управлению проектами.

15.Формирование бизнес-логики. Классификация бизнес-правил.

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

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

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

Уровень сервера позволяет реализовывать бизнес-правила за счет адекватного физического проектирования структуры таблиц (сущностей) БД и посредствам создания хранимых процедур

MoSCoW

+ M - MUST have this.

+ S - SHOULD have this if at all possible.

+ C - COULD have this if it does not affect anything else.

+ W - WON'T have this time but WOULD like in the future. Alternatively WANT.

FURPS — классификация требований к программным системам.

Образована от первых букв слов:

+ Functionality — Функциональные требования. Являются основными, по этим требованиям строятся диаграммы вариантов использования (Use case diagram).

+ Usability — Требования к удобству использования.

+ Reliability — Требования к надежности.

+ Performance — Требования к производительности.

+ Supportability — Требования к поддержке.

+ проектные ограничения

Требования выполнениния

Требования к интерфейсу

Физич. требования

Логические правила, сценарные модели, интерфейсы.

Классификация бизнес-правил.

Все бизнес-правила можно разделить на 3 основных категории: условия, факты и правила. Условия и факты - основа для логической модели данных и физической базы данных. Третья категория (правила) представляет наибольший интерес, их можно разделить на 5 категорий.

16.Основные конструктивы языка SQL-94

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

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

INSERT – вставка новых строк в таблицу.

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

Оператор выбора SELECT

Первый пример находит в таблице kadry строку, в которой столбец tabnum=345 . Из этой строки берутся только три указаных столбца. Второй пример выбирает ВСЕ строки из таблицы ceh, и все столбцы.

SELECT fio, dolvn, zarplata FROM kadry WHERE tabnom=345

SELECT * FROM ceh

SELECT kadry.fio, ceh.nameceh WHERE kadry.nomerceh=ceh.nomerceh

Третий пример выбирает фамилии работников из таблицы кадры, а названия цехов, в которых они работают, из таблицы ceh.

UPDATE ceh SET kod_ceha[1,4]=nameceh[5,8] WHERE nomerceh BETWEEN 3 AND 5 OR nameceh IN ("токарный","литейный").

В таблице ceh в цехах номер 3,4,5 а так же в токарном и литейном первые четыре символа в коде цеха будут заменены на подстроку поля nameceh из той же строки.

Оператор INSERT.

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

INSERT INTO kadry VALUES (4, 0, "Грицко", num, "10/25/1939", NULL).

Оператор DELETE.

Уничтожает строки в таблице

DELETE FROM kadry WHERE ceh=4 AND fio MATCHES "*ов"

Уничтожить в таблице kadry все строки, в которых номер цеха равен 4, а фамилия кончается на буквы "ов".

17.Проектирование экранных форм. Особенности проектирования и программирования в разных операционных средах.

Проектирование экранных форм

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

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

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

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

Полезно разбить всех пользователей на группы. Вот один из вариантов такого разбиения:

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

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

• пользователи, задающие нерегламентированные запросы, иногда выполняющие поиск и (еще реже) обновление;

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

• операторы, планирующие и контролирующие отчеты и пакетные задания.

Вот общие принципы проектирования экранных форм:

• Все экранные формы должны иметь уникальные и информативные заголовки.

• Все поля необходимо снабдить надписями; при вызове справочной с системы должны быть доступны подробные описания полей.

• Курсор по умолчанию, как правило, должен перемещаться слева направо, а затем сверху вниз.

• Обязательные элементы должны находиться в верхней части экрана. Элементы на экране необходимо упорядочить по степени важности.

• Экранная форма должна обнаруживать ошибочно введенные данные и сообщать о них как можно раньше, а не откладывать проверку.

• Экранная форма не должна состоять из множества страниц .

• Пользователи должны вводить код только один раз и не должны ничего запоминать или записывать при переходе от одной экранной формы к другой.

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

• Размещение на экранной форме дополнительных элементов за счет уменьшения размера символов допустимо только в ограниченной степени.

• Большинство пользователей гораздо лучше справляются с вертикальной, а не с горизонтальной прокруткой, особенно если при прокрутке вправо из левой части экрана исчезают важные данные и условные обозначения.

18.Технологические и организационные особенности этапа отладки и тестирования программной системы.

Отла́дка — этап разработки компьютерной программы, на котором обнаруживают, локализуют и устраняют ошибки. Чтобы понять, где возникла ошибка, приходится :

+ узнавать текущие значения переменных;

+ выяснять, по какому пути выполнялась программа.

Существуют две взаимодополняющие технологии отладки.

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

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

Процесс отладки выполняется примерно по такому алгоритму: после того как написан рабочий код производятся тестовые запуски программы на различных наборах тестовых данных. При этом тестер или программист заранее должны получить контрольный результат, с которым будет идти сверка работы проверяемого кода. Например, заранее произвести вычисления. В случае обнаружения расхождений между контрольным и фактическим результатами, начинается поиск проблемного участка кода и выявление ошибок вышеуказанными способами. Сейчас получают довольно мощное распространение средства автоматического тестирования исходного кода программ. Основной прием здесь это создание тестов исходного текста, которые будут применены к тестируемому участку кода, система тестирования сообщит об их результатах. Примерами таких систем могут быть: встроенный модуль doctest в Python и мультиязыковая библиотека тестирования xUnit, распространяемая на условиях GNU/GPL и LGPL. Основа применения всех этих средств и техник это разбиение одной большой задачи на ряд четких и более маленьких задач.

19.Модели управления командой разработчиков информационной системы. Основные роли и функции проекта. Планирование команды проекта.

Нет проектного менеджера

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

В проектную группу входят такие ролевые кластеры:

*управление программой

*управление продуктом

*разработка

*тестирование

*управление релизом

*удовлетворение потребителя

Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же — построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта.

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

управление программой (program manager) — разработку архитектуры решения, административные службы;

разработку (developer) — разработку приложений и инфраструктуры, технологические консультации;

тестирование (QAE) — планирование, разработку тестов и отчетность по тестам;

управление выпуском (release manager) — инфраструктуру, сопровождение, бизнес-процессы, выпуск готового продукта;

удовлетворение заказчика (user experience) — обучение, эргономику, графический дизайн, техническую поддержку;

управление продуктом (product manager) — бизнес-приоритеты, маркетинг, представительство интересов заказчика.

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

Минимальный коллектив по MSF может состоять всего из трех человек. Модель не требует назначения отдельного сотрудника на каждый ролевой кластер. Смысл состоит в том, что в команде должны быть представлены все шесть качественных целей. Обычно, выделение как минимум одного человека на каждый ролевой кластер обеспечивает полноценное внимание к интересам каждой из ролей, но это экономически оправданно не для всех проектов. Зачастую члены проектной группы могут объединять роли.

В малых проектных группах объединение ролей является необходимым. При этом должны соблюдаться два принципа:

Роль команды разработчиков не может быть объединена ни с какой другой ролью.

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

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

Ролевая структура проекта, предложенная Центром объектно-ориентированной технологии компании IBM.

20.Типовой сценарий и правила опроса эксперта с целью выявления требований к проекту.

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

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

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

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

-Заранее заготовить вопросы

-Непродолжительный опрос

-Не умничать

-Слушать

-Не перебивать

-Не давать уходить в сторону от проблемы

21. Проект-ая док-я, тех зад, ЕСПД

Обычно в состав проектной документации входят: Устав пр-та, Цели пр-та Краткое изложение обстоятельств, Анализ заинтересованных лиц, Док-я по масштабу проекта, Док-я по требованиям пр-та, Матрица ответственности, План пр-та, План коммуникации, План рисков, Протоколы совещаний,Отчёты о состоянии

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

позволяет: обеим сторонам: представить готовый продукт; выполнить попунктную проверку готового продукта (приёмочное тестирование — проведение испытаний); уменьшить число ошибок, связанных с изменением требований. Заказчику:

осознать, что именно ему нужно в т.ч. опираясь на существующие на данный момент технические возможности и свои ресурсы; требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ; исполнителю: понять суть задачи, показать заказчику «технический облик» будущего изделия, программного изделия или автоматизированной системы; спланировать выполнение проекта и работать по намеченному плану; отказаться от выполнения работ, не указанных в ТЗ (ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению; ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

Единая система программной документации (ЕСПД) — комплекс государственных стандартов Российской Федерации, устанавливающих взаимосвязанные правила разработки, оформления и обращения программ и программной документации. (ГОСТ 19.102-77. ЕСПД. Стадии разработки).

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

22.Идеи и примеры использования диаграмм прецедентов (Use Case).

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

Диаграммы прецедентов обычно включают в себя:

+ Прецеденты(функция, связанная с эктором);

+ Эктеры(субъект или сущность процесса);

+ отношения включения, обобщения и ассоциации.

Обобщение-отношение, в кот. Объекты специализированного элемента м.б. подставлены вместо объектов обобщенного элемента

Включение-в некоторой точке базового прецедента содержится поведение другого дочернего прецедента. Родительский прецедент разбивается на несколько более детальных прецедентов.(И)

В кач-ве доп средств используются соединительные линии и стрелки, кот. Позволяют конкретизировать отдельные прецеденты.

Типичные примеры применения

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

При моделировании статического вида системы с точки зрения прецедентов диаграммы использования обычно применяются двумя способами:

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

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

23.Идеи и примеры использования диаграмм последовательностей и коопераций.

Диаграммы последовательностей

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

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

Во-первых, на них показана линия жизни объекта. Это вертикальная пунктирная линия, отражающая существование объекта во времени.

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

Диаграммы кооперации

Диаграмма кооперации акцентирует внимание на организации объектов, принимающие участие во взаимодействии.

У диаграмм кооперации есть два свойства, которые отличают их от диаграмм последовательностей.

Первое - это путь. Для описания связи одного объекта с другим к дальней концевой точке этой связи можно присоединить стереотип пути (например, local, показывающий, что помеченный объект является локальным по отношению к отправителю сообщения). Имеет смысл явным образом изображать путь связи только в отношении путей типа local, parameter, global и self(но не associations).

Второе свойство - это порядковый номер сообщения. Для обозначения временной последовательности перед сообщением можно поставить номер (нумерация начинается с единицы), который должен постепенно возрастать для каждого нового сообщения ( 2, 3и. т.д.).

Типичные примеры применения

При моделировании динамических аспектов системы диаграммы взаимодействий обычно используются двояко:

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

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

24. Объектный подход в проектировании и разработке ИС. Понятие о методологии UML. Идеи и примеры использования диаграмм активности.

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

 UML (Unified Modeling Language) –стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) в 1997г.

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

В языке UML для этапов анализа предназначены следующие виды диаграмм:

+ use case diagram (диаграммы прецедентов);

+ activity diagram (диаграммы описаний технологий, процессов, функций);

+ sequence diagram (диаграммы последовательностей действий);

+ collaboration diagram (диаграммы взаимодействий).

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

Activity diagram – представляют собой схемы потоков управления в системе от действия к действию, а также параллельные и альтернативные потоки, с является неким аналогом нотаций IDEF0 и IDEF3. Диаграмма не очень приспособлена для отображения сложной логики, но возможно ее использование в качестве доступного для понимания аналога заказчику.

Sequence diagram – иллюстрирует события, инициирован­ные в системе исполнителями. Является удобной диаграммой при переходе на физический уровень, как при

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

Типичные приемы применения

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

При моделировании динамических аспектов системы диаграммы деятельности применяются в основном двумя способами:

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

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

25. Понятие о паттернах (шаблонах) проектирования.

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

Проектирование в категориях паттернов – это предельная формализация структуры системы с точки зрения объектно-ориентированного подхода. Основные принципы такого подхода:

+ Разделение осн функций системы

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

+ Взаимодействие через объекты – через интерфейсы

+ Принцип «персональной ответственности»

Шаблоны используются при:

+ Реализации сложных проектов

+ Работе больших проектных коллективов

+ Использовании повторяемого кода

+ Необходимости оптимизации кода

+ Экстремальном проектировании

Классификация

+ Архитектурные п.

+ Проектирования

+ Анализа

+ Тестирования

+ Реализации

Применимость.

Когда:

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

+ Входящие в семейтсво взаимосвязанные объекты должны использоваться вместе и вам необходимо обеспечить выполнение этого ограничения

+ Система должна конфигурироваться одним из семейств составления ее объектов

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

Примеры:

+ GoF

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

Предназначены для спецификации фундаментальных схем структуризации программных систем.

26. Идеи и примеры использования диаграмм состояний

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

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

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

• entry - действие, которое выполняется в момент входа в данное состояние (входное действие);

• exit - действие, которое выполняется в момент выхода из данного состояния (выходное действие);

• do - выполняющаяся деятельность ("do activity") в течение всего времени, пока объект находится в данном состоянии

• defer - событие, обработка которого предписывается в другом состоянии, но после того, как все операции в текущем будут завершены.

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

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

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

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

27.Технологии оценки стоимости разработки информационной системы. Квалиметрическая оценка систем.

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

По функциональной модели строится:

Стоимостная оценка процесса

Временная оценка

Экспертным путем определяются «идеальные» параметры

показатели стоимости

Квалиметрия:

По операциям и процессу в целом определяются все значимые характеристики и их эталон

Оценивается общее качество процесса путем сравнения с эталонным:

i - номер свойства;  j - номер оцениваемого объекта;  q_i^эт и q_i^бр - соответственно эталонное и браковочное значения показателей свойства.

Если браковочное значение неизвестно, формула принимает вид:

28. Понятие о диаграмме развертывания и диаграмме компонентов.

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

Главными элементами диаграммы являются узлы, связанные информационными путями. Узел (node) – это то, что может содержать программное обеспечение. Узлы бывают двух типов. Устройство (device) – это физическое оборудование: компьютер или устройство, связанное с системой. Среда выполнения (execution environment) – это программное обеспечение, которое само может включать другое программное обеспечение, например операционную систему или процесс-контейнер.

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

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

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

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

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

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

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

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

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

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

29. Технологии оценки эффективности использования проектируемой информационной системы. Методология BSC, KPI.

Для решения высокоуровневых бизнес – задач, таких как, построение (создание, разработка) методологии BSC и системы KPI и др., недостаточно только инструментария. Первоначально в компании должна быть поставлена и внедрена методология.

BSC - Balanced Score Card  (Перевод: Система сбалансированных показателей (ССП)) – система стратегического управления, позволяющая переводить стратегические цели компании в операционные (функциональные) цели подразделений и сотрудников и оценивать результаты их деятельности в контексте реализации стратегии при помощи KPI.

KPI - Key Performance Indicator (Перевод: Ключевой показатель эффективности) – показатель, позволяющий определить насколько эффективно Компания и ее сотрудники осуществляют свою деятельность в достижении стратегической цели. Каждый KPI измерим, и у каждого KPI существует ответственный (сотрудник, подразделение), который в силе повлиять на изменение KPI.

Система KPI является составной частью методологии BSC 

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

BSC:

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

Определит прозрачные механизмы ответственности

Позволит руководителю более четко увидеть и понять тенденции бизнеса

 Система KPI – это: 

1.      Возможность предупредительного информирования: 

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

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

2.      Текущий анализ доли рынка в сегментах  и себестоимости в сравнении с конкурентами 

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

Постановка методологии BSC

Требует некоторого уровня готовности компании.

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

В результате жизнедеятельности компании компоненты методологии могут меняются - изменяются цели, показатели, ответственные за выполнение KPI, и как следствие за достижение целей. В этом случае компоненты (цели, показатели) пересматриваются в соответствии с методологией.

Постановка системы KPI

В случае, когда организационный уровень и уровень руководства компании находится на стадии, при которой компания не готова к внедрению и использованию BSC – отсутствует система качества, внутренние регламенты и т.д. - можно и нужно внедрять систему KPI, которая предоставит компании ряд преимуществ, в т.ч.:

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

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

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

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