Must have — Жизненно необходимые
Требования отмеченные как MUST have должны быть включены в текущую поставку. Если хоть одно из требований не сделано, поставка считается провальной.
Should have — Обязательные
Требования SHOULD have также критичны для успеха проекта, но не необходимы в ближайших поставках. Такие требования имеют workarounds, то есть имеются обходные пути для выполнения требований, и могут быть отложены на будущие поставки продукта.
Could have — Пожалуй можно реализовать
Требования COULD have менее критичные требования, обычно относящиеся к «nice to have». Чаще всего менее трудоёмки чем первые 2 категории.
Won’t have (but Would like) — Можно и не делать, но хотелось бы
Наименее критичные или не самые подходящие в данные момент времени. И как результат данные требования не планируются в ближайшие поставки. Также эти требования часто первыми исключаются из последующих поставок, при реприоритизации. Однако это не делает их менее важными, и эти требования относят к отряду улучшений на будущее. Вот этот тонкий момент иногда сбивает пользователей с толку, так как данные требования стоят в одном ряду с остальными.
13. Принципы структурного анализа системы.
Анализ требований разрабатываемой системы является важнейшим среди всех этапов ЖЦ. Он оказывает существенное влияние на все последующие этапы, являясь в то же время наименее изученным и понятным процессом. На этом этапе, во-первых, необходимо понять, что предполагается сделать, а во-вторых, задокументировать это, т.к. если требования не зафиксированы и не сделаны доступными для участников проекта, то они вроде бы и не существуют. При этом язык, на котором формулируются требования, должен быть достаточно прост и понятен заказчику.
Структурным анализом принято называть метод исследования системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней. Для таких методов характерно разбиение на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 6-7); ограниченный контекст, включающий лишь существенные на каждом уровне детали; дуальность данных и операций над ними; использование строгих формальных правил записи; последовательное приближение к конечному результату.
Все методологии структурного анализа базируются на ряде общих принципов, часть из которых регламентирует организацию работ на начальных этапах ЖЦ, а часть используется при выработке рекомендаций по организации работ. В качестве двух базовых принципов используются следующие: принцип "разделяй и властвуй" и принцип иерархического упорядочивания. Первый является принципом решения трудных проблем путем разбиения их на множество меньших независимых задач, легких для понимания и решения. Второй принцип в дополнение к тому, что легче понимать проблему если она разбита на части, декларирует, что устройство этих частей также существенно для понимания. Понимание проблемы резко облегчается при организации ее частей в древовидные иерархические структуры, т.е. система может быть понята и построена по уровням, каждый из которых добавляет новые детали.
Выделение двух базовых принципов инженерии программного обеспечения вовсе не означает, что остальные принципы являются второстепенными, игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к неуспеху всего проекта). Отметим основные из таких принципов.
1. Принцип абстрагирования - заключается в выделении существенных с некоторых позиций аспектов системы и отвлечение от несущественных с целью представления проблемы в простом общем виде.
2. Принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы.
3. Принцип упрятывания - заключается в упрятывании несущественной на конкретном этапе информации: каждая часть "знает" только необходимую ей информацию.
4. Принцип концептуальной общности - заключается в следовании единой философии на всех этапах ЖЦ (структурный анализ - структурное проектирование - структурное программирование - структурное тестирование).
5. Принцип полноты - заключается в контроле на присутствие лишних элементов.
6. Принцип непротиворечивости - заключается в обоснованности и согласованности элементов.
7. Принцип логической независимости - заключается в концентрации внимания на логическом проектировании для обеспечения независимости от физического проектирования.
8. Принцип независимости данных - заключается в том, что модели данных должны быть проанализированы и спроектированы независимо от процессов их логической обработки, а также от их физической структуры и распределения.
9. Принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
10. Принцип доступа конечного пользователя - заключается в том, что пользователь должен иметь средства доступа к базе данных, которые он может использовать непосредственно (без программирования).
Соблюдение указанных принципов необходимо при организации работ на начальных этапах ЖЦ независимо от типа разрабатываемого ПО и используемых при этом методологий. Руководствуясь всеми принципами в комплексе, можно понять на более ранних стадиях разработки, что будет представлять из себя создаваемая система, обнаружить промахи и недоработки, что, в свою очередь, облегчит работы на последующих этапах ЖЦ и понизит стоимость разработки.
14. Последовательность этапов проведения реинжиниринга бизнес-процессов. В каких подходах к проектированию ИС поддерживается моделирование бизнес-процессов?
Общая схема реинжиниринга, включающая 4 основных этапа:
1. Визуализация - разработка образа будущей компании.
2. Обратный инжиниринг - создание модели существующей компании.
3. Прямой инжиниринг - разработка нового бизнеса.
4. Внедрение - внедрение перепроектированных процессов.
В основном регламент проведения реинжиниринга соответствует последовательности принятия решений.
Этап "визуализация" BPR соответствует этапу "целевыявление" системной последовательности. Спецификацию целей компании предлагается осуществлять на основе анализа окружения - потребителей, клиентов, отрасли, к которой принадлежит компания, ведущих фирм смежных отраслей. По результатам анализа определяется новая стратегия компании, строятся прототипы - сценарии будущего, формируется высокоуровневое описание будущих процессов, определяется список факторов успеха и риска.
Этап "обратный инжиниринг" BPR соответствует этапу "анализ" системной последовательности. Если 1-й этап BPR включал в себя в основном анализ внешней среды компании, то на 2-м этапе осуществляется детальное описание существующего состояния самой компании. Результатом работ является модель существующего бизнеса. I и II этапы BPR выполняются параллельно: работа по визуализации новой компании начинается до и кончается после работы по обратному инжинирингу, поскольку модель существующего бизнеса оказывает влияние на формирование целей новой компании.
Этап BPR "прямой инжиниринг" соответствует этапу "проектирование" системной последовательности. На основе модели существующего бизнеса в соответствии с образом будущей компании на основе эвристических правил и рекомендаций (принципов реинжиниринга) формируется модель нового бизнеса. Выделяются подэтапы, соответствующие разработке подсистемы организационного взаимодействия и подсистемы информационной поддержки.
Этап BPR "внедрение" соответствует этапам "реализация" и "оценка" системной последовательности. Кроме собственно внедрения новых бизнес-процессов, происходит их оценка и тестирование, по результатам которого может быть принято решение о проведении следующей итерации реинжиниринга.
В каких подходах к проектированию ИС поддерживается моделирование бизнес-процессов? В процессном подходе. Этот подход ориентирован не на организационную структуру, а на бизнес-процессы. С точки зрения авторов, он наиболее перспективен. Бизнес-процессы, в отличие от организационной структуры, меняются реже. Как правило, основных бизнес-процессов на предприятии немного, обычно не более десяти.
15. Диаграммы, используемые в функционально-ориентированном проектировании ИС. Состав элементов диаграмм и правила их построения. Назначение каждого из типов диаграмм.
Основными идеями функционально-ориентированной CASE технологии являются идеи структурного анализа и проектирования информационных систем. Они заключаются в следующем:
· декомпозиция всей системы на некоторое множество иерархически подчиненных функций;
· представление всей информации в виде графической нотации. Систему всегда легче понять, если она изображена графически.
В качестве инструментальных средств структурного анализа и проектирования выступают следующие диаграммы:
· BFD (Bussiness Function Diagram) - диаграмма бизнес - функций (функциональные спецификации);
· DFD (Data Flow Diagram) - диаграмма потоков данных;
· STD (State Transition Diagram) - диаграмма переходов состояний (матрицы перекрестных ссылок);
· ERD (Entity Relationship Diagram) - ER-модель данных предметной области (информационно-логические модели "сущность-связь");
· SSD (System Structure Diagram) - диаграмма структуры программного приложения.
_________________________________________________________________________
Business Function Diagram (BFD) – диаграммы функциональных спецификаций. Позволяют представить общую структуру исследуемого объекта, отражающую взаимосвязь различных задач в процессе получения требуемых результатов. Основные элементы BFD – это функции (некоторые действия, необходимые для решения поставленных задач) и декомпозиции функций (разбиение функции на множество подфункций). На практике диаграмма функционал. спецификаций, используется, например, для верификации диаграмм сущность-связь при проектировании базы данных ИС.
________________________________________________________________________
Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Состав диаграмм потоков данных. Основные компоненты диаграмм потоков данных:
• внешние сущности - представляет собой предмет или лицо, является источником или приемником информации. Внешняя сущность находится за пределами границы анализир. области;
• системы и подсистемы - отражаются только на контекстной диаграмме при наличии нескольких подсистем;
• процессы - функция аналогичная диаграмме IDEF0. В имени функции указ. глагол в неопределенной форме;
• накопители данных - представляет собой абстрактное устройство для хранения данных (например, инфа о клиентах). Детализация до таблиц БД не производится;
• потоки данных - имеет наименование и направление. Опред. и. передаваемую от источника к приемнику..
Правила и рекомендации построения модели DFD в основном совпадают с принятыми в IDEF0. По аналогии с IDEF0 у каждого процесса (подсистемы) на диаграмме потоков данных должен быть как минимум один входящий и один выходящий поток. Процесс должен запускаться на выполнение либо через обрабатываемый, либо через управляющий поток данных. Работа каждого процесса должна завершаться конкретным результатом.
Каждый накопитель данных также должен иметь как минимум один входящий и один выходящий поток. Наличие только входящих потоков в накопитель означает, что информация накапливается, но не используется.
Наличие только выходящих потоков из накопителя также является ошибкой. Прежде чем использовать данные из накопителя, они должны там появиться в результате работы какого-либо процесса (подсистемы, внешней сущности). Исключением из правил считается случай, когда накопитель является внешней сущностью. Тогда допускается наличие либо только входящих стрелок, либо только выходящих стрелок.
ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь" - способ определения данных и отношений между ними, обеспечивающий детализацию хранилищ данных проектируемой системы включая идентификацию объектов (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей). Предназначена для разработки концептуальной схемы БД.
ERD состоит из:
1. Сущность - реальный или воображаемый объект имеющий существенные значения для рассматриваемой области, информация о котором подлежит хранению. Каждый экземпляр сущности должен однозначно идентифицироваться.
2. Связь - ассоциация между 2-мя сущностями, при которой каждый экземпляр одной сущности (родительской/главной) ассоциирован с произвольным количеством второй сущности. Связь один ко многим.
3. Атрибут - любая характеристика сущности просматриваемая в предметной области. Может быть обязательным или необязательным. Обязательный атрибут не может принимать неопределенные значения.
4. Уникальный идентификатор - атрибут или совокупность атрибутов предназначенные для уникальной идентификации каждого экземпляра данного типа сущности.
Диаграммы изменения состояний STD.
Жизненный цикл сущности относится к классу STD-диаграмм (рис. 14).
Рис. 14. Пример диаграммы жизненного цикла
Эта диаграмма отражает изменение состояния объекта с течением времени. Например, рассмотрим состояние товара на складе: товар может быть заказан у поставщика, поступить на склад, храниться на складе, проходить контроль качества, может быть продан, забракован, возвращен поставщику. Стрелки на диаграмме показывают допустимые изменения состояний.
16. Соответствие между понятиями (названиями элементов) инфологической и даталогической моделей.
Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных (рис. 1.3).
Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. В конце концов этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.
Остальные модели (рис. 1.3), являются компьютеро-ориентированными. С их помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.
Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое АБД по инфологической модели данных, называют даталогической моделью данных.
17. Состав архитектуры CASE-средств. Классификация CASE-средств. Примеры CASE-средств с указанием поддерживаемых нотации.
Полный комплекс CASE-средств, обеспечивающий поддержку жизненного цикла ПО, содержит следующие компоненты:
· репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
· графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (потоков данных, "сущность-связь" и др.), образующих модели ИС;
· средства разработки приложений, включая языки 4GL и генераторы кодов;
· средства конфигурационного управления;
· средства документирования;
· средства тестирования;
· средства управления проектом;
· средства реинжиниринга.
Современные CASE-системы классифицируются по следующим признакам:
1) По поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования);
2) По поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;
3) По степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных - репозиторием);
4) По типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ориентированные на локальную вычислительную сеть (ЛВС), ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа;
5) По режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов;
6) По типу операционной системы (ОС): работающие под управлением WINDOWS 3.11 и выше; работающие под управлением UNIX и работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.).
Рассмотрим классификацию Case-средств по типам и категориям.
Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ и включает следующие типы:
1) АНАЛИЗ И ПРОЕКТИРОВАНИЕ. Средства данной группы используются для создания спецификаций системы и ее проектирования; они поддерживают широко известные методологии проектирования. (CASE.Аналитик (Эйтэкс) и т.д.).
2) ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ И ФАЙЛОВ. Средства данной группы обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в Третью Нормальную Форму, автоматическую генерацию схем БД и описаний форматов файлов на уровне программного кода: ERWin (Logic Works), S-Designor (SDP).
3) ПРОГРАММИРОВАНИЕ. Средства этой группы поддерживают этапы программирования и тестирования, а также автоматическую кодогенерацию из спецификаций, получая полностью документированную выполняемую программу: APS (Sage Software).
4) СОПРОВОЖДЕНИЕ И РЕИНЖИНИРИНГ. К таким средствам относятся документаторы, анализаторы программ, средства реструктурирования и реинжениринга. Их целью является корректировка, изменение, анализ, преобразование и реинжениринг существующей системы.
5) ОКРУЖЕНИЕ. Средства поддержки платформ для интеграции, создания и придания товарного вида CASE-средствам: Multi/Cam (AGS Management Systems) и т.д.
6) УПРАВЛЕНИЕ ПРОЕКТОМ. Средства, поддерживающие планирование, контроль, руководство, взаимодействие, т.е. функции, необходимые в процессе разработки и сопровождения проектов: Project Workbench (Applied Business Technology).
CASE-средство Silverrun американской фирмы Сomputer Systems Advisers, Inc. (CSA) используется для анализа и проектирования ИС бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").
Vantage Team Builder представляет собой интегрированный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ПО и поддержку полного ЖЦ ПО.
· проектирование диаграмм потоков данных, "сущность-связь", структур данных, структурных схем программ и последовательностей экранных форм;
· проектирование диаграмм архитектуры системы - SAD (проектирование состава и связи вычислительных средств, распределения задач системы между вычислительными средствами, моделирование отношений типа "клиент-сервер", анализ использования менеджеров транзакций и особенностей функционирования систем в реальном времени)
18. Где содержится метаинформация в процессе проектирования ЭИС?
Метаинформация - это информация о свойствах документа (страницы сайта), предназначенная для поисковых систем и используемая ими при индексации данной страницы. Использование метаинформации позволяет поисковым системам правильно и более качественно проиндексировать ваш сайт.
19. Элементы логической и физической ER-диаграммы в CASE-средстве ERwin Data Modeler.
ERwin - средство концептуального моделирования БД, использующее методологию IDEF1X (ERD). ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД.
ERwin имеет два уровня представления модели - логический и физический. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например "Постоянный клиент", "Отдел" или "Фамилия сотрудника". Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д. Разделение модели данных на логические и физические позволяет решить несколько важных задач.
20. Виды систем классификации. Параметры систем классификации. Цель разработки классификаторов.
Классификатор – это документ, с помощью которого осуществляется формализованное описание экономической информации в ЭИС, содержащий наименования объектов, наименования классификационных группировок и их кодовые обозначения.
Основные способы классификации (возможны и другие критерии классификации систем).
1) По отношению системы к окружающей среде:
· открытые (есть обмен ресурсами с окружающей средой);
· закрытые (нет обмена ресурсами с окружающей средой).
2) По происхождению системы (элементов, связей, подсистем):
· искусственные (орудия, механизмы, машины, автоматы, роботы и т.д.);
· естественные (живые, неживые, экологические, социальные и т.д.);
· виртуальные (воображаемые и, хотя реально не существующие, но функционирующие так же, как и в случае, если бы они существовали);
· смешанные (экономические, биотехнические, организационные и т.д.).
3) По описанию переменных системы:
· с качественными переменными (имеющие лишь содержательное описание);
· с количественными переменными (имеющие дискретно или непрерывно описываемые количественным образом переменные);
· смешанного (количественно-качественное) описания.
4) По типу описания закона (законов) функционирования системы:
· типа "Черный ящик" (неизвестен полностью закон функционирования системы; известны только входные и выходные сообщения);
· не параметризованные (закон не описан; описываем с помощью хотя бы неизвестных параметров; известны лишь некоторые априорные свойства закона);
· параметризованные (закон известен с точностью до параметров и его возможно отнести к некоторому классу зависимостей);
· типа "Белый (прозрачный) ящик" (полностью известен закон).
5) По способу управления системой (в системе):
· управляемые извне системы (без обратной связи, регулируемые, управляемые структурно, информационно или функционально);
· управляемые изнутри (самоуправляемые или саморегулируемые - программно управляемые, регулируемые автоматически, адаптируемые - приспосабливаемые с помощью управляемых изменений состояний, и самоорганизующиеся - изменяющие во времени и в пространстве свою структуру наиболее оптимально, упорядочивающие свою структуру под воздействием внутренних и внешних факторов);
· с комбинированным управлением (автоматические, полуавтоматические, автоматизированные, организационные).
Формально два ключевых параметра классификации можно определить следующим образом:
1. параметр локализации указывает на область пространства относительно некоторого ориентира, в которой находится (в которую или из которой перемещается) участник ситуации.
2. параметр ориентации характеризует взаимодействие между описываемым объектом и ориентиром в терминах приближения, удаления или покоя (отсутствия движения) объекта относительно ориентира.
Целью разработки классификаторов является установление соответствия между значениями справочных и описательных признаков какого–либо элемента или процесса и значениями группировочных признаков (например, между значением реквизита Фамилия и значением Табельный номер).
21. Структура классификаторов технико-экономической информации. (?)
Все классификаторы, разрабатываемые и используемые в ЭИС, имеют эталонную и рабочую формы. Эталонная форма классификатора – это официальное издание классификатора на бумажном носителе, удобное для осуществления его ведения. Рабочая форма классификатора – это весь классификатор или его раздел, занесённый на машинный носитель и удобный для обработки информации.
В составе автоматизированной системы ведения общесистемных классификаторов (АСВОК) можно выделить три типа подсистем:
- объектные подсистемы,
- функциональные подсистемы,
- обеспечивающие подсистемы.
Объектные подсистемы, объединяют предприятия, отрасли, отраслевые институты, которые отвечают за передачу информации об изменениях, происходящих в заданной номенклатуре, число которых может быть равно числу общесистемных классификаторов.
Функциональные подсистемы объединяют однотипные технологические процессы по ведению общесистемных классификаторов и включают в свой состав след. подсистемы:
- сбора, хранения, внесение корректив;
- регулярного обслуживания абонентов;
- обслуживания по разовым запросам;
- развития АСВОК, включая оптимизацию структуры классификаторов, устранение недействительных ветвей классификаторов, стандартизацию терминологии.
Обеспечивающие подсистемы, состоят из типового набора подсистем, к которым относят программное, техническое, информационное и лингвистическое обеспечение. В состав информационного обеспечения АСВОК входит тезаурус, сводные эталонные файлы классификаторов, дополнительные эталонные файлы дополнений и исключаемых позиций, файлы поисковых образов позиций классификаторов, файлы незанятых позиций, таблицы сопряжений классификаторов, вспомогательный файл организаций, ответственных за ведение классификаторов, таблицы периодичности оповещения организаций, вспомогательные файлы интересов абонентов.
22. Структура экономического показателя.
Экономический показатель — показывает, характеризует состояние экономики, ее объектов, протекающих в ней процессов в прошлом, настоящем и в будущем. Экономические показатели представляют один из самых распространенных и эффективных инструментариев описания экономики, используемых в экономической науке и в управлении экономическими процессами.
В структуре экономических показателей различают абсолютные, называемые также количественными, объемными, и относительные, называемые также качественными. Абсолютные, объемные показатели (в экономике в отличие от физики объемными называют любые показатели, характеризующие количество товаров, продукции, денег) выражены в натуральных или денежных единицах, таких, как штуки, вес, длина, объем, рубли, доллары. Относительные показатели представляют отношение двух показателей одинаковой или разной размерности. В первом случае это безразмерные показатели, характеризующие обычно темп изменения экономической величины или соотношения, пропорции однородных экономических величин, получаемые в результате их сравнения, измеряемые в долевом исчислении либо в процентах. Во втором случае это размерные показатели, характеризующие скорость изменения величины во времени, эффективность использования ресурсов, чувствительность величины по отношению к фактору, обусловившему ее изменение. Например, показатель эффективности автомобильного двигателя может быть измерен массой расходуемого бензина на один километр пути, а показатель отдачи капиталовложений — количеством выпускаемой продукции, приходящимся на один рубль вложений капитала.
В совокупности относительных экономических показателей, характеризующих динамику экономических процессов, изменение объемных показателей, различают показатели роста (скорости роста) и прироста (приростные).
23. Параметры кода информации.
24. Признаки классификации экономической документации.
Понятием экономические документы объединяются документы, создаваемые в сфере экономики: бизнеса, производства, торговли, транспорта, строительства и т. п. Здесь можно выделить такие типологические разновидности, как коммерческий (связанный с отношениями товарообмена, купли-продажи) и технологический (связанный с производством, практической деятельностью) документы.
К важнейшим признакам, по которым обычно осуществляется классификация циркулирующей экономической инф-ции в ИС, относятся:
1. Отношение к данной управляющей системе. Этот признак позволяет разделить сообщения на входные, выходные и внутренние.
2. Признак времени. Относительно времени сообщения делятся на перспективные, т. е. о будущих событиях, и ретроспективные (учетные данные и т. д.). К перспективным относится плановая или прогнозная инф-я.
3. По времени поступления разделяются периодические и непериодические сообщения.
4. Функциональный признак. Здесь формируется классификация по функциональным подсистемам экономического объекта (инф-я о трудовых ресурсах, финансовая инф-я и т. п.)
25. Какие формы документов выделяют при проектировании унифицированной системы документации?
Унифицированная система документации (УСД) - это рационально организованный комплекс взаимосвязанных документов, который отвечает единым правилам и требованиям и содержит информацию, необходимую для оптимального управления некоторым экон. объектом.
Унификации подлежат:
· стандарты и технические условия;
· проектно-конструкторская и технологическая документация;
· проектная документация по капитальному строительству;
· плановая документация;
· статистическая отчетность;
· первичная учетная документация;
· финансовая первичная и отчетная документация;
· бухгалтерская документация бюджетных организаций и объединений;
· организационно-распорядительная документация;
· документация по материально-техническому снабжению;
· документация по ценообразованию и торговле
26. Требования к документам результатной информации.
Так как результатный документ используется для осуществления процессов управления, то он должен отвечать следующим требованиям:
· полнота информации, т.е. результатные документы должны содержать в себе первичные (исходные) и результатные показатели;
· количество результатных показателей должно соответствовать количеству группировочных признаков (количество итогов должно быть равно количеству ключей сортировки);
· своевременность предоставления информации управленческому персоналу;
· достоверность предоставляемой информации;
· хорошая читаемость (логичность построения форм и наличие хорошо отредактированного текста шапок документов);
· отсутствие показателей, рассчитываемых вручную.
27. Классификация диалогов информационных систем.
Диалог - это процесс обмена информацией между пользователем и программной системой, осуществляемый через интерактивный терминал и по определенным правилам.
Различают тип диалога и его форму.
Типы диалога. Тип диалога определяет, кто из «собеседников» управляет процессом обмена информацией. Соответственно различают два типа диалога: управляемые программой и управляемые пользователем.
Диалог, управляемый программой, предусматривает наличие жесткого, линейного или древовидного, т.е. включающего возможные альтернативные варианты, сценария диалога, заложенного в программное обеспечение. Такой диалог обычно сопровождают большим количеством подсказок, которые уточняют, какую инфу необходимо вводить на каждом шаге.
Диалог, управляемый пользователем, подразумевает, что сценарий диалога зависит от пользователя, который применяет систему для выполнения необходимых ему операций. При этом система обеспечивает возможность реализации различных пользовательских сценариев.
Формы диалога. Никакой диалог невозможен, если не существует языка, понятного «собеседникам». Описание языка, на котором ведется диалог, включает определение его синтаксиса - правил, определяющих допустимые конструкции (слова, предложения) языка или его форму, и семантики - правил, определяющих смысл синтаксически корректных конструкций языка или его содержание. В зависимости от вида используемых в конкретном случае синтаксиса и семантики различают три формы диалога:
1. фразовую;
2. директивную;
3. табличную.
Фразовая форма предполагает «общение» с пользователем на естественном языке или его подмножестве. Содержание диалога в данной форме оставляют повелительные, повествовательные и вопросительные предложения и ответы на вопросы. Общение может осуществляться в свободном формате, но возможна и фиксация отдельных фраз.
Директивная форма предполагает использование команд (директив) специально разработанного формального языка. Командой в этом случае называют предложение этого языка, описывающее комбинированные данные, которые включают идентификатор инициируемого процесса и, при необходимости, данные для него.
Табличная форма предполагает, что пользователь выбирает ответ из предложенных программой. Язык диалога для табличной формы имеет простейший синтаксис и однозначную семантику, что достаточно легко реализовать. Удобна эта форма и для пользователя, так как выбрать всегда проще, чем вспомнить, что особен