Факторы успехов проектов

Классификация ИС по характеру производства

Классификация по степени автоматизации

Классификация информационных систем по архитектуре

Таблица 1

Классификация информационных систем по функциональному признаку

Классификация ИС.

Для определения вида ИС используют соответствующие признаки классификации.

ИС классифицируются по:

1. функциональному признаку;

2. структуризации функциональных задач;

3. уровням управления;

4. архитектуре;

5. степени автоматизации;

5.1. характеру использования информации;

5.2 сфере применения;

6. типу производства.

Начало документа

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

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

Указанные направления деятельности определили типовой набор информа­ционных систем:

- производственные системы;

- системы маркетинга;

- финансовые и учетные системы;

- системы кадров (человеческих ресурсов);

- специализированные ИС, выполняющие вспомогательные функции в зависимости от специфики деятельности ОУ.

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

Система маркетинга Задачи	Производст-венные системы	Финансо-вые и учетные системы	Система кадров	Специализи-рованные ИС (ИС руководства)
функциональные задачи	Исследование рынка и про-гнозирование продаж	Планирова-ние объемов работ и разработка календарных планов	Управление портфелем заказов	Анализ и прогнози-рование потребности в трудовых ресурсах	Контроль за деятельно- стью фирмы
Управление продажами	Оператив-ный контроль и управление производст-вом	Управление кредитной политикой	Ведение архивов записей о персонале	Выявление оперативных проблем
Рекомендации по произ-водству новой продукции	Анализ работы оборудова-ния	Разработка финансо-вого плана	Анализ и планирова-ние подготовки кадров	Анализ управленче- ских и стра- тегических ситуаций
Анализ и установление новой цены	Участие в формировании заказов поставщикам	Финансо-вый анализ и прогнози-рование	Обеспечение процесса вы- работки стратеги-ческих решений
Контроль бюджета
Учет заказов	Управление запасами	Бухгалтер-ский учет и расчет зарплаты

Начало документа

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

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

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

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

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

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

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

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

Рисунок 1.4 - Классификация информационных систем по признаку структуриро­ванности решаемых задач

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

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

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

- оперативная подготовка и корректировка входных параметров и ограниче­ний модели;

- возможность графического отображения динамики модели;

- возможность объяснения пользователю необходимых шагов формирования и работы модели.

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

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

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

Начало документа

3. Классификация ИС по уровням управления

Назначение ИС определяется тем, какие задачи она реализует на соответствующем уровне управления.

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

Рисунок 1.5 – Типы информационных систем в зависимости от функционального признака с учетом уровней управления и уровней управленческого персонала

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

Задачи, цели и источники информации на операционном уровне заранее определены и в высокой степени структурированы. Решение задач запрограммировано в соответствии с заданным алгоритмом.

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

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

1. ИС офисной автоматизации;

2. ИС обработки знаний.

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

Эти системы выполняют следующие функции:

- обработка текстов на компьютерах с помощью различных текстовых про­цессоров;

- производство высококачественной печатной продукции; архивация документов;

- электронные календари и записные книжки для ведения деловой информа­ции;

- электронная и аудио почта; видео- и телеконференции.

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

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

- сравнение текущих показателей с показателями прошлых периодов;

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

На этом уровне можно выделить два типа ИС: управленческие (для менеджмента) и системы поддержки принятия решений.

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

Характеристики управленческих информационных систем:

- используются для поддержки принятия решений структурированных и час­тично структурированных задач на уровне контроля операций;

- ориентированы на контроль, отчетность и принятие решений по оператив­ной обстановке.

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

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

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

− оснащенность сложными инструментальными средствами моделирования и анализа;

− возможность изменения постановок решаемых задач и входных данных;

− гибкость и адаптируемость к изменению условий по несколько раз в день;

− наличие технологии, максимально ориентированной на пользователя.

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

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

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

Начало документа

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

- локальные ИС, в которых все компоненты (БД, СУБД, клиентские приложения) работают на одном компьютере;

- распределённые (distributed) ИС, в которых компоненты распределены по нескольким компьютерам.

Распределённые ИС, в свою очередь, разделяют на

- файл-серверные ИС (ИС с архитектурой «файл-сервер»);

- клиент-серверные ИС (ИС с архитектурой «клиент-сервер»).

В файл-серверных ИС база данных находится на файловом сервере, а СУБД и клиентские приложения находятся на рабочих станциях.

В клиент-серверных ИС база данных и СУБД находятся на сервере, а на рабочих станциях находятся клиентские приложения.

В свою очередь, клиент-серверные ИС разделяют на двухзвенные и многозвенные.

В двухзвенных (two-tier) ИС всего два типа «звеньев»: сервер баз данных, на котором находятся БД и СУБД, и рабочие станции, на которых находятся клиентские приложения. Клиентские приложения обращаются к СУБД напрямую.

В многозвенных (multi-tier) ИС добавляются промежуточные «звенья»: серверы приложений (application servers). Пользовательские клиентские приложения не обращаются к СУБД напрямую, они взаимодействуют с промежуточными звеньями.

Начало документа

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

Рисунок 2 - Классификация информационных систем по разным признакам

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

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

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

Начало документа

а) Классификация по характеру использования информации

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

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

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

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

Начало документа

б) Классификация по сфере применения

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

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

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

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

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

Начало документа

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

Выделяют следующие типы производства:

1) дискретный – мелкосерийный; индивидуальный; серийный; крупносерийный; массовый.

(предприятия машиностроения, приборостроения, радиотехнической, электротехнической промышленности)

2) дискретно-непрерывный (предприятия металлургической, цементной, пищевой промышленности)

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

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

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

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

Начало документа

4. ФОРМИРОВАНИЕ ТРЕБОВАНИЙ К РАЗРАБАТЫВАЕМОЙ ИС

1. Необходимость формирования требований к ИС.

2. Назначение и виды требований к ИС.

3. Методика формирования требований (SSADM и ГОСТ 34.801-90) (МФТ).

4. Формирование каталога требований.

4.1. Необходимость формирования требований к ИС

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

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

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

Таким образом, без относительно стабильных базовых и согласованных требований проект не может быть реализован.

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

Следовательно, требования являются базой для:

- планирования проекта;

- управления рисками;

- приемочного тестирования;

- компромиссов и согласований;

- управления изменениями.

Причины провалов проекта:

- неполнота требований;

- недостаточное привлечение пользователей;

-недостаток в ресурсах;

- нереалистические ожидания;

- недостаток поддержки от руководства;

- изменение требований/спецификаций;

- недостаточное планирование;

- потеря необходимости реализации проекта;

Эти причины связаны с тем, что:

1. Требования плохо написаны, слабо связаны с запросами и потребностями пользователей, быстро изменяются;

2. Недостаточность ресурсов, плохое планирование и управление требованиями.

1. Вовлечение пользователей;

2. Поддержка руководства;

3. Четкая и ясная постановка требований;

4. Хорошее планирование работ;

5. Частые контрольные точки;

6. Компетентная команда.

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

Начало документа

2. Содержание V-модели

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

Начало документа

Требования к V – модели

Эта модель отображает системную разработку в терминах уровней по ЖЦ проекта.

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

- максимально увеличить число ТПР;

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

- использовать программное управление для согласования действий;

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

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

Поэтому необходимо выполнить следующее:

- принять или отклонить изменения;

- согласовать стоимость изменения;

- организовать работы по переделке.

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

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

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

Использование связей позволяет получить следующие преимущества:

- возможность оценить влияние изменений;

- получить большую уверенность в достижении целей;

- возможность вклада субподрядчиков по проекту;

- возможность контролировать ход проекта и оценить объем выполненных работ;

- возможность сопоставлять затраты и выгоду.

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

Существует три метода анализа связей между требованиям и:

1) анализ влияния даёт возможность оценить, на какие другие элементы проекта нижнего уровня повлияет внесение изменения в данный конкретный элемент.

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

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

Рис. 2 – Связи между требованиями

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

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

Начало документа

4.2 Назначение и виды требований к ИС.

Определение требований к ИС является наиболее этапом ее разработки.

Цель установления требований состоит в том, чтобы дать развернутое определение требований, которое участники проекта (З и Р) ожидают реализовать в разрабатываемой системе.

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

Значимость требований определяется их ролью в формировании ФС_ИС и ОК_ИС, процессами выполняемых работ на всех стадиях ЖЦ ИС.

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

Существуют разные технологии определения требований.

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

По сравнению с ГОСТ 34.601-90 методика SSADM является более гибкой, предусматривающей выявление общих требований к системе пользователем и в частности к ее функциональным назначениям. Кроме того она позволяет представлять требования для принятия конкретных решений.

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

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

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

Все требования подразделяются на:

- функциональные,

- нефункциональные.

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

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

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

МФТ – методика «формирования требований»

U, D – управляющие воздействия и документы

Тф - функциональные требования

Тнф – нефункциональные требования

КТ – каталог требований

МП – методы проектирования

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

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

1. требования безопасности, хранения данных;

2. обеспечения мониторинга и контроля данных;

3. обеспечения качества реализации функций;

4. ограничение доступа к данным;

5. прочие требования.

1. Меры безопасности, хранения данных предусматривают каким данным необходима защита, резервирование.

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

3. Качество реализации функций определяется вычислительным комплексом и соответствующими обеспечениями в виде оценок. Естественно на I этапе устанавливаются грубые оценки, которые уточняются на этапе микропроектирования. Например:

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

б) надежность – наработка на отказ,

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

г) длительность функционирования системы.

4. Ограничение доступа – устанавливает какие меры должны быть приняты для ограничения доступа. Кроме того для установления мер безопасности, хранения данных определяется каким данным необходима защита, резервирование.

5. Прочие требования.

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

Начало документа

4.3. Методика формирования требований (МФТ) реализуется двумя этапами:

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

II. На втором (II) этапе оцениваются варианты реализации проектов создаваемой системы исходя из принятых требований.

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

- модели инф. потоков,

- описания функций,

- конкретизированного каталога требований (КТ).

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

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

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

Методика формирования требований реализуется следующими процедурами:

1. Определение функций разработчика и пользователя на каждой стадии ЖЦ ИС;

2. Осуществление сбора первичных данных о ПрО (инф. потоки);

3. Формирование требований (КТ) (ТЗ).

4. Ведение каталога требований.

Эффективность применения такой методики позволяет перейти к формированию проект-х основополагающих документов.

Начало документа

4.3. Формирование каталога требований (КТ)

Формирование и ведение КТ позволяет на этапе макропроектирования уточнить цели разработки системы, определить функции подсистемы, задачи (ФС), предполагаемый ОК, предварительные материальные, финансовые, трудовые и временные затраты с использованием критерия эффективности разрабатываемой ИС.

Э = max F; R_ф ≤ R_з; Т_ф ≤ Т_з

На этапе микропроектирования ТЗ требования практически регламентируют создание всех элементов ОК, в соответствии с разработанной ФС_ИС.

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

Формирование каталога требований №

Название проекта	Разработчик	Дата	Версия	Структура данного N требования	Прим.
Распределенная информационно-аналитическая система (РИАС)	Иванов И.И.	10.10.00	2-я
Важность требования (планируемая (П), ожидаемая (Ж)	Ж
Функциональные требования	Формирование документа по анализу успеваемости студента
Нефункциональные требования	Время реализации запроса, диалоговый режим, надежность
Преимущества реализации требования	Автоматическое формирование документа
Предполагаемое решение	Сформировать документ по аналогу ведомости
Условия ссылки на требования	Ссылки на требования при разработке ИС (ТЗ)
Резолюция по реализации требования	Описать данную функцию при формировании ФС (ОПЗ)

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

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

Начало документа

5. Принципы проектирования ИС

Вопросы:

1. Организационно-методологические принципы.

2. Системный принцип.

3. Экономико-математические принципы.

4. Организационно-правовые и технические принципы.

Начало документа

5.1(а) Принципы проектирования ИС

Сложность ИС, большая стоимость, многоплановость, трудоёмкость и продолжительность работ – это те проблемы, которые требуют регламентации процесса разработки ИС в соответствии с определёнными принципами проектирования.

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

1) организационно-методологические принципы;

2) экономико-математические принципы;

3) системный принцип проектирования;

4) организационно-правовые и технические принципы.

Эти принципы подчёркивают экономическую природу ИС, отличающуюся от разработки технических систем управления, первоочерёдностью экономических проблем, необходимость приспособления математических и инструментальных методов и средств к особенностям и условиям функционирования ОУ.

В отличие от ИС технические системы обладают следующими особенностями:

1) имеется возможность разработки физических моделей на ранней стадии (для ИУС физическая модель не определена до промышленной эксплуатации);

2) применяется классическая теория управления (дляИУСразрабатываются экономико-математические методы);

3) устанавливаются конкретные сроки окончания процесса проектирования (для ИУС определяются 1,2 очередь внедрения) и т.д.

Начало документа

5.1(б). Организационно-методологические принципы

Организационный принцип предусматривает организацию работ множества разработчиков в рамках сложного проекта ИС. Методологический – методологии.

Начало документа

5.2 Принцип системного подхода.

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

Начало документа

Принципы комплексного подхода

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

2. Принцип первого руководителя.

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

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

5. Принцип непрерывного глубокого развития ИУС (модернизация её элементов).

6. Принцип совместимости (техническая, информационная, программная, математическая).

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

Системный подход применяется при разработке видов обеспечения:

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

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

В ТО - применение совместимых ЭВМ и периферийных устройств.

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

Следование системным принципам при формировании управленческих решений предусматривает:

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

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

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

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

4. Непрерывное обновление НСИ. Органический синтез элементов ИУС при реализации функций управления.

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

6. Организацию локальных сетей.

Начало документа

5.3 Экономико-математические принципы

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

Общая модель СУ должна отображать взаимосвязь всех аспектов и методов планирования и регулирования деятельностью ОУ.

Модель системы управления на основе системного описания можно представить в виде:

- общего описания закономерностей деятельности ОУ;

- математических формул и уравнений, отражающих характер закономерностей развития и функционирования ОУ;

- блок-схем взаимосвязи факторов развития и функционирования ОУ. Для минимизации затрат времени, повышения эффективности исследования на первых этапах проектирования целесообразна разработка экономико-организационной модели в базе общего описания или системного представления.

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

3. Реализация замкнутого контура управления ИС. Реализация функциональных задач должна охватывать все фазы управления (планирование-регулирование). Объединение всех фаз управления в рамках всех задач обеспечивает повышение степени резервирования производства материальных и иных ресурсов, что в конечном итоге позволяет обеспечить эффективность ОУ.

Начало документа

5.4 Организационно-правовые и технические принципы

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

2. Приведение организационной структуры аппарата управления в соответствии с характером модели СУ-

Реализация этого принципа требует:

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

- определить основные функции и задачи подразделения ОУ;

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

- регламентировать схему взаимодействий подразделений;

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

3. Подготовка персонала аппарата управления к работе в условиях ИС, в условиях использования новых методов и средств для решения задач управления.

В процессе проектирования ИС должны осуществляться:

- совместная разработка функциональных задач разработчиками и пользователями; совместное решение задач (регулирование и пользование). Процесс подготовки персонала на всех этапах создания ИУС позволяет снизить психологические конфликты при внедрении современных методов и средств управления;

- обучение работников аппарата управления новыми методами решения задач (сети, ЭВМ).

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

Начало документа

6. Управление требованиями к ИС с использованием DOORS

1. Актуальность управления требованиями.

2. Назначение и архитектура DOORS.

3. Структура модуля.

4. Применение DOORS для моделирования.

6.1. Актуальность управления требованиями.

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

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

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

Начало документа

6.2 Архитектура DOORS

Для поддержки процесса управления требованиями аналитикам и руководителям необходим хороший инструментарий. В настоящее время на рынке нет недостатка в продуктах, предназначенных для управления требованиями. Один из них – Telelogic DOORS (версия 8.09). DOORS (Dynamic Object Oriented Requirements System – динамическая объектно-ориентированная система для работы с требованиями) является на сегодняшний день лидирующим на рынке продуктом, который используется десятками тысяч специалистов во всем мире.

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

Архитектура DOORS состоит из папок, проектов и модулей.

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

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

Рисунок 1 - Структура базы данных DOORS.

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

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

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

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

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

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

• link (связи) – модуль связи, содержащий взаимосвязи и информацию о них между элементами данных.

Пользовательский интерфейс DOORS во многом аналогичен интерфейсу Windows Explorer (проводник) и позволяет легко и удобно просматривать данные в системе.

В DOORS предусмотрена возможность изменять названия и описания существующих папок и проектов. При необходимости изменить или реорганизовать структуру базы данных папки и проекты можно перемещать. Кроме того, предусмотрена возможность копировать, вырезать и вставлять проекты и папки, используя команды Copy, Cut и Paste.

Начало документа