«система». Лекция автоматизированные экономические информационные системы

• Название: Лекция автоматизированные экономические информационные системы
• Дата: 11.10.2019
• Размер: 0.87 Mb.
• Имя файла: «система».doc
• Тип: Лекция; #89613
• страница: 12 из 18

ЛЕКЦИЯ 8.

ТИПОВОЕ АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ. СТАДИЯ РАЗРАБОТКИ ПРОЕКТОВ.

Состав работ проектной стадии создания АЭИС.

Этап проектирования дает ответ на вопрос: "Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?". Задачей этого этапа является исследование структуры системы и логических взаимосвязей ее элементов, причем здесь не рассматриваются вопросы, связанные с реализацией на конкретной платформе. Проектирование определяется как "итерационный процесс получения логической модели системы вместе со строго сформулированными целями, поставленными перед нею, а также написания спецификаций физической системы, удовлетворяющей этим требованиям".

Обычно этот этап разделяют на три подэтапа, в соответствие с ГОСТ 34-601-90 они трактуются как эскизный проект, технический проект и рабочий проект:

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

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

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

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

Технический проект оформляется в соответствии с ГОСТ 34.201.

ТП включает в себя разделы:

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

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

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

3. 
   рабочее проектирование – детальное проектирование, включающее разработку программ ИС, выбор, адаптацию и (или) привязку приобретаемых программных средств, разработку спецификаций каждого компонента, интерфейсов между компонентами, разработку требований к тестам и плана интеграции компонентов. Рабочий проект должен содержать все необходимые и достаточные сведения для обеспечения выполнения работ по вводу АЭИС в действие и её эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями, её оформление, согласование и утверждение. В комплекс рабочего проекта входит также программная документация в соответствии с ГОСТ 19.101.
   

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

Планирование этапа проектирования

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

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

• 
  ожидаемые результаты и документы;
  
• 
  персональные функции руководителя;
  
• 
  решения, принимаемые руководителем;
  
• 
  функции заказчика и разработчика АЭИС.
  

Планирование на основе методологии управления проектами позволяет:

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

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

Журнал проектирования

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

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

Эскизное проектирование – 1 этап. Основные задачи и особенности.

Рассмотрение результатов анализа

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

Если проект небольшой, то в качестве аналитиков, проектировщиков и разработчиков могут выступать одни и те же люди. Возникает вопрос: насколько вообще актуальна передача результатов самому себе? Думаем, что актуальна. Представьте себе, что вы передаете данные кому-либо, кто мало знает о системе. Зачастую это помогает, например, найти не описанные вообще, нечетко описанные, противоречиво описанные компоненты системы.

Семинары

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

Моделирование бизнес-процессов с использованием сетей Петри.

Критические участки.

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

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

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

Оценка ограничений

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

Решения относительно выбора аппаратной платформы, как правило, необратимы, поскольку тесно связаны со сметой затрат и наличием обслуживающего персонала. Например, решения на платформе RS/6000 и Intel с точки зрения сметы затрат выглядят одинаково, но персонала, способного квалифицированно обслуживать RS/6000, нет, и руководство не согласно оплатить обучение сотрудников, хотя решение на основе RS/6000 обладает более высокой масштабируемостью. Это может послужить причиной выбора платформы Intel. Аналогичные причины могут влиять и на выбор операционной системы.

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

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

Определение целевой архитектуры

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

Кроме определения платформы следует выяснить следующее:

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

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

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

Выделение потенциальных узких мест в информационной системе

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

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



Рисунок 1 Пример диаграммы активности системы

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

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

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

Использование продуктов третьих фирм

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