Информационные технологии. Ответы

 

№11 Реинженеринг систем и ИС

После анализа  модели «как есть (AS-IS)» необходимо построить модель «как должно быть (TO-BE)», которая объединяет перспективные предложения по совершенствованию деятельности предприятия.

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

1. Неудовлетворительное функционирование организации (системы, подсистемы).
2. Перегрузка высшего руководства.
3. Отсутствие ориентации на перспективу.
4. Разногласия по организационным вопросам.
5. Рост масштаба деятельности.
6. Увеличение разнообразия.
7. Объединение хозяйственных субъектов (систем, подсистем).
8. Изменение технологии управления.
9. Изменение внешней экономической обстановки.

При этом можно руководствоваться основными принципами реинженеринга:

1. Работа не должна быть самоцелью, то есть надо организовать не выполнение работы, а достижение результата.
2. Исполнение процесса надо поручать тому, кто использует его результат. Тогда практически пропадает необходимость руководить процессом.
3. Надо включать обработку информации в реальную работу, которая генерирует эту информацию.
4. Надо считать географически распределенные ресурсы централизованными, при этом использовать базы данных, сети и т.п.
5. Надо связывать параллельные работы и координировать соответствующие действия в процессе их совершения вместо интеграции результатов.
6. Надо помещать точку принятия решения туда, где выполняется работа, и встраивать контроль в процесс. По мере того, как исполнители начинают обходиться без контроля и руководства, исчезает иерархия.

Надо фиксировать  информацию один раз – у источника. 

№12 Критерии качества ПС ИС

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

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

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

Эффективность - это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов.

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

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

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

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

Альтернативой правильного ПС является надежное ПС. 
 
 
 
 
 
 
 
 
 

№13 Определение требований (целей, задач) ИС. Спецификация качества.

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

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

Известны три  способа разработки определения  требований к ПС:

• управляемая пользователем разработка,
• контролируемая пользователем разработка,
• независимая от пользователя разработка.

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

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

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

Функциональность: завершенность.

Надежность: завершенность, точность, автономность, устойчивость, защищенность.

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

Эффективность: временнáя эффективность, эффективность по ресурсам (по памяти), эффективность по устройствам. 

№14 Функциональная модель IDEF0

Метод SADT реализован в одном из стандартов этого семейства  — IDEF0. Метод SADT (Structured Analysis and Design Technique) считается классическим методом  процессного подхода к управлению. Основной принцип процессного подхода  заключается в структурировании деятельности организации в соответствии с ее бизнес-процессами, а не организационно-штатной структурой. Именно бизнес-процессы, формирующие значимый для потребителя результат, представляют ценность, и именно их улучшением предстоит в дальнейшем заниматься.

Состав  функциональной модели

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

Рисунок 1. Функциональный блок и интерфейсные дуги

Преимущества SADT заключаются в следующем :

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

В то же время  метод SADT обладает рядом недостатков:

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

 

№15 Декомпозиция функциональных моделей

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

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

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

Стратегии декомпозиции

При построении иерархии диаграмм используются следующие  стратегии декомпозиции:

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

 
 

№16 Функциональная модель IDEF3

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

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

Все связи в IDEF3 являются однонаправленными.

Соединения "и"   Соединения "или" 

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

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

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