«система»
Вид материала | Лекция |
- Лекция 2 Экономическая система, как объект кибернетики, 70.17kb.
- 1. Назва модуля: Конструкція та динаміка двигунів внутрішнього згорання Код модуля, 20.12kb.
- Воспитательная система образовательного учреждения. Концепция всш, 120.08kb.
- Налоговая система, 798.68kb.
- Тема Правовые системы современности, 23.96kb.
- Солнечная система автор: Самиев Махмуд, 6 «Б» класс, 547.98kb.
- Темы рефератов икурсовых работ общие. Система государственного управления: основные, 90.41kb.
- Лекция Система национальных счетов, 238.7kb.
- Школа как педагогическая система и объект научного управления, 71.64kb.
- В. А. Геодакян Окружающий нас мир состоит из разных систем: наша галактика система,, 284.73kb.
Требования к эффективности и надежности проектных решений.
Проектирование информационных систем всегда начинается с определения цели проекта. Основная задача любого успешного проекта заключается в том, чтобы на момент запуска системы и в течение всего времени ее эксплуатации можно было обеспечить:
- требуемую функциональность системы и степень адаптации к изменяющимся условиям ее функционирования;
- требуемую пропускную способность системы;
- требуемое время реакции системы на запрос;
- безотказную работу системы в требуемом режиме, иными словами - готовность и доступность системы для обработки запросов пользователей;
- простоту эксплуатации и поддержки системы;
- необходимую безопасность.
Производительность является главным фактором, определяющим эффективность системы. Хорошее проектное решение служит основой высокопроизводительной системы.
Эти требования могут быть выполнены при условии использования современных информационных технологий проектирования.
^
Понятие проектирования ИС. Состав проекта ИС.
В реальных условиях проектирование - это поиск способа создания системы, который удовлетворяет требованиям функциональности системы средствами имеющихся технологий с учетом заданных ограничений.
Проектирование информационных систем охватывает три основные области:
- проектирование объектов данных, которые будут реализованы в базе данных;
- проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
- проектирование конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.
Таким образом, цель проектирования – обеспечение эффективного функционирования АЭИС, а также взаимодействия пользователей и разработчиков АЭИС. Именно качественное проектирование обеспечивает создание такой системы, которая способна функционировать при постоянном совершенствовании ее технических, программных, информационных составляющих и расширять спектр реализуемых управленческих функций. В процессе проектирования совершенствуется как организация основной деятельности предприятия, так и организация управленческих процедур.
Основу проекта любой ИС составляют следующие компоненты:
- методология проектирования;
- технологии проектирования;
- стандарты и методики проектирования;
- инструментальные средства проектирования (CASE-средства).
При этом взаимосвязь этих компонентов следующая: методология реализуется через конкретные технологии, каждая технология поддерживается соответствующими стандартами и методиками, а инструментальные средства обеспечивают выполнение процессов проектирования, описанных в методиках и стандартах.
Каждый из этих компонентов будет рассматриваться подробно.
^
Понятие методологии проектирования АЭИС.
Хорошо известно, что небольшое число чрезвычайно талантливых программистов, работающих по всему миру, обладают невероятным творческим потенциалом и способны создавать сложные программные средства очень быстро и фактически без внешнего руководства ими. Эти программисты несут ответственность за многие открытия, которые поддерживают программную индустрию в состоянии постоянного совершенствования. Большинство же из миллионов профессиональных разработчиков, разбросанных по всему миру, являются профессиональными ремесленниками, которые применяют проверенные способы построения своих программных средств.
В конце 60-х годов прошлого века в США было отмечено явление под названием "software crisis" (кризис ПО). Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.
Аналитические исследования и обзоры, выполняемые в течение ряда последних лет ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Так, например, результаты исследований, выполненных в 1995 году компанией Standish Group, которая проанализировала работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой ПО, выглядели следующим образом:
- только 16,2% завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности;
- 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме;
- 31,1% проектов были аннулированы до завершения;
- для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%.
В 1998 году процентное соотношение трех перечисленных категорий проектов лишь немного изменилось в лучшую сторону (26%, 46% и 28% соответственно).
В последние годы процентное соотношение трех перечисленных категорий проектов также незначительно изменяется в лучшую сторону, однако, это происходит в основном за счет снижения масштаба выполняемых проектов, а не за счет повышения управляемости и качества проектирования.
В числе причин возможных неудач, по мнению разработчиков, фигурируют:
- нечеткая и неполная формулировка требований к ПО;
- недостаточное вовлечение пользователей в работу над проектом;
- отсутствие необходимых ресурсов;
- неудовлетворительное планирование и отсутствие грамотного управления проектом;
- частое изменение требований и спецификаций;
- новизна и несовершенство используемой технологии;
- недостаточная поддержка со стороны высшего руководства;
- недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта.
Объективная потребность контролировать процесс разработки сложных систем ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце 60-х годов прошлого века к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием "программная инженерия" (software engineering). В основе программной инженерии лежит одна фундаментальная идея: проектирование ПО является формальным процессом, который можно изучать и совершенствовать. Освоение и правильное применение методов и средств создания ПО позволяет повысить его качество, обеспечить управляемость процесса проектирования ПО и увеличить срок его жизни.
В то же время, попытки чрезмерной формализации процесса, а также прямого заимствования идей и методов из других областей инженерной деятельности (строительства, производства) привели к ряду серьезных проблем. После двух десятилетий напрасных ожиданий повышения продуктивности процессов создания ПО, возлагаемых на новые методы и технологии, специалисты в индустрии ПО пришли к пониманию, что фундаментальная проблема в этой области - неспособность эффективного управления проектами создания ПО. Невозможно достичь удовлетворительных результатов от применения даже самых совершенных технологий и инструментальных средств, если они применяются бессистемно, разработчики не обладают необходимой квалификацией для работы с ними, и сам проект выполняется и управляется хаотически, в режиме "тушения пожара". Если в таких условиях отдельные проекты завершаются успешно, то этот успех достигается за счет героических усилий фанатично настроенного коллектива разработчиков.
Это привело к пониманию того, что необходимо обратить внимание на методологические основы проектирования информационных систем.
^ Методология - это предписанная основа для проектирования и построения информационных систем. Она описывает серию шагов, моделей и подходов, которые, если им тщательно следовать, вероятнее всего приведут к хорошо работающим приложениям. Хотя методологии не гарантируют того, что программные средства будут замечательными, они, благодаря ясному общему представлению, помогают охватить все важные шаги или элементы, которые надлежащим образом учитываются.
Методологии о6еспечивают организационную структуру, позволяющую коллективам разработчиков функционировать скоординированным способом. Тщательно проработанные методологии обеспечивают лиц, работающих над проектом, общим словарем, общими методами и основой для контроля. Все это позволяет оценить продвижение вперед.
^ Более всего методологии обеспечивают предсказуемость результатов, контроль и согласованность действий. Пользуясь тем или иным методом разработки приложений, члены коллектива разработчиков обеспечены общим пониманием направленности работы. Разработчики, объединенные проектом в одном городе или другой стране, могут непосредственно сообщить, в какой стадии находится их проект, ссылаясь на конкретные шаги, определенные в данной методологии. Поэтому методология представляет собой:
- тесно связанные, предписанные конкретные последовательности шагов;
- перечень данных, подлежащих накоплению на каждой стадии;
- критерии завершения работ в контрольных точках;
- решения, принимаемые при выборе между альтернативными методами проектирования;
- конкретные стандарты построения информационных систем.
Поэтому неудивительно, что организации, занимающиеся разработкой, по достоинству оценивают методологии. Методологии обладают широкими преимуществами. Простые предписывают некоторое количество контрольных точек, некоторые практические правила и, возможно, указывают некоторые стандарты кодирования и именования элементов проекта. С другой стороны, сложные методологии, заполняющие книжные полки, требуют нескольких месяцев обучения, зато расписывают каждый аспект деятельности разработчика.
Методология - это не панацея. Многие организации верят, что еще найдется методология, имеющая ответы на все проблемы разработки. Прежде всего, необходимо понять, что методология не является "заменителем" размышлений и хорошего проектирования. Из всего сказанного следует сделать два вывода:
1. Методологии необходимы для создания больших систем, и АЭИС в частности.
2. Современные методологии должны изменяться в соответствии с потребностями нового поколения разработчиков и пользователей, обеспечивая тем самым разработку дружественных, гибких, легко сопровождаемых систем.
^
Принципы создания АЭИС
Массовое проектирование АЭИС потребовало разработки единых теоретических положений, методологических подходов к их созданию. К ним относятся и основополагающие принципы создания АЭИС: системности, развития (открытости), совместимости, стандартизации (унификации), эффективности.
^ Принцип системности является важнейшим при создании, функционировании и развитии АЭИС. Он позволяет подойти к исследуемому объекту как единому целому, выявить многообразные типы связей между структурными элементами, установить направления деятельности системы и реализуемые ею функции.
Системный подход предполагает проведение микро- и макроанализа исследуемого объекта. При макроанализе система или ее элемент рассматривается как часть системы более высокого порядка. Особое внимание уделяется информационным связям: устанавливается их число, влияние отдельных связей на выполнение целевой функции системы. При микроанализе изучается структура объекта, анализируются составляющие ее элементы с точки зрения их характеристик.
Системный подход позволяет использовать математическое описание функционирования отдельных элементов и систем в целом, моделировать изучаемые процессы для анализа работы проектируемых систем.
Практическое значение системного подхода и моделирования состоит в том, что они позволяют в доступной для анализа форме отразить существенные моменты функционирования объекта, но и использовать вычислительную технику для имитационного моделирования поведения будущей системы. Поэтому в основе создания АЭИС в настоящее время лежит метод моделирования на базе системного подхода, позволяющий находить оптимальный вариант структуры системы и тем самым обеспечивать наибольшую эффективность ее функционирования.
^ Принцип развития заключается в том, что АЭИС создается с учетом возможности постоянного пополнения и обновления функций системы. Предусматривается, что автоматизированная система должна наращивать свои вычислительные мощности, оснащаться новыми программными и техническими средствами, быть способной постоянно расширять и обновлять круг задач и информационную базу.
^ Принцип совместимости заключается в обеспечении способности взаимодействия АЭИС различных видов, уровней в процессе их совместного функционирования.
^ Принцип стандартизации заключается в необходимости применения типовых, унифицированных и стандартизованных элементов. На практике применение этого принципа позволяет сократить временные, финансовые и трудовые затраты на создание АЭИС за счет применения разработанных ранее проектных решений (программных модулей, комплексов, компонентов).
^ Принцип эффективности заключается в достижении рационального соотношения между затратами на создание АЭИС и целевым эффектом, получаемым в результате автоматизации.
Кроме основополагающих принципов для осуществления эффективного управления выделяют ряд частных принципов, детализирующих общие. Соблюдение частных принципов позволяет получить определенный экономический эффект.
Принцип декомпозиции – основан на разделении системы на части, выделении отдельных комплексов работ, создает условия для более эффективного анализа и проектирования.
Принцип первого руководителя предполагает закрепление ответственности при создании системы за заказчиком – руководителем предприятия, который отвечает за ввод в действие и функционирование АЭИС.
Принцип новых задач – поиск постоянного расширения возможностей системы, получение дополнительного эффекта за счет оптимизации управленческих решений.
Принцип автоматизации документооборота предусматривает комплексное использование технических средств на всех стадиях прохождения информации от сбора до формирования управленческих решений.
Принцип автоматизации проектирования повышает эффективность самого процесса проектирования АЭИС за счет применения типовых проектных решений, методов и средств подготовки проектных материалов, стандартизации подходов при проектировании отдельных элементов и подсистем.
Проблемы проектирования АЭИС связаны, с одной стороны, с особенностями экономического объекта, для которого проектируется АЭИС, с другой стороны, с особенностями технологии компьютерной обработки данных. Поэтому рассмотренные базовые принципы создания АЭИС необходимо дополнить организационно-технологическими принципами.
Принцип абстрагирования заключается в выделении существенных аспектов системы и отвлечения от несущественных для представления проблемы в более простом общем виде, удобном для анализа и проектирования.
Принцип формализации заключается в применении формализованных методов описания и моделирования изучаемых и проектируемых процессов.
Принцип концептуальной общности заключается в неукоснительном следовании единой методологии на всех этапах проектирования АЭИС.
Принцип непротиворечивости и полноты заключается в наличии всех необходимых элементов в проектируемой системе и согласованном их взаимодействии.
Принцип независимости данных предполагает, что модели данных должны быть спроектированы независимо от процессов их обработки, а также от их физической структуры и распределения в технической среде.
Принцип структурирования данных предусматривает необходимость иерархической организации элементов информационной базы.
Принцип доступа конечного пользователя заключается в том, что пользователь должен иметь средства доступа к базе данных, которые он может использовать непосредственно (без программирования).
Соблюдение приведенных принципов необходимо при выполнении работ на всех стадиях создания и функционирования АЭИС, т.е. в течение всего жизненного цикла.
^
АЭИС как открытые системы.
АЭИС обладают еще одним важным свойством – они относятся к классу открытых систем. Реализация АЭИС в классе открытых систем определяется современным уровнем развития мировой экономики, в частности созданием единого информационного пространства.
Единое информационное пространство складывается из следующих главных компонентов:
- информационных ресурсов, содержащих данные и знания, зафиксированные на соответствующих носителях;
- организационных структур, обеспечивающих функционирование и развитие единого информационного пространства – сбор, обработку, хранение, поиск, распространение информации;
- средств информационного взаимодействия граждан и организаций, в том числе программно-технических средств и организационно-нормативных документов, обеспечивающих доступ к информационным ресурсам.
В едином информационном пространстве могут взаимодействовать только открытые системы.
Открытая система – это система, реализующая открытые стандарты на интерфейсы, службы и форматы данных, достаточные для обеспечения:
- возможности переноса (мобильности) прикладных систем с минимальными изменениями на широкий диапазон систем;
- совместной работы (интероперабельности) с другими прикладными системами на локальных и удаленных платформах;
- взаимодействия с пользователями в стиле, облегчающем им переход от системы к системе (мобильность пользователей).
Согласно этому определению, открытый стандарт (спецификация) не зависит от конкретных технических и программных средств отдельных производителей. Открытый стандарт одинаково доступен любой заинтересованной стороне.