Литература Основная литература:

1. Информационные технологии управления: учеб. пособие для вузов / под. ред. Г.А. Титоренко. – 2 е изд.,доп. - М.: ЮНИТИ - ДАНА, 2003. – 439 с.

2. Бугорский В.Н., Соколов Р.В. Сетевая экономика и проектирование информационных систем. – СПб.: Питер, 2007. – 320с.

3. Смирнова Г.Н. и др. Проектирование экономических информационных систем: учебник / Г.Н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов; под ред. Ю.Ф. Тельнова. – М.: Финансы и статистика, 2005. – 512 с.

Дополнительная литература

4. Романов А.Н., Одинцов Б.Е. Информационные системы в экономике (лекции, упражнения, задачи): Учеб. пособие. – М.: Вузовский учебник, 2006. – 300 с.

5. ГОСТ 34.003-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Термины и определения.

Тема 2. Технологии проектирования ис

Цель:

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

• изучить методы и средства проектирования ИС;

• изучить основные технологии проектирования ИС;

Результат обучения. После обучения студент должен:

• знать основные компоненты технологии ИС, назначение;

• знать и разбираться в методах и средствах проектирования ИС;

• различать технологии проектирования ИС.

План:

2.1 Основные компоненты технологии проектирования ИС.

2.2 Методы и средства проектирования ИС.

2.3 Характеристика применяемых технологий проектирования.

2.4 Требования, предъявляемые к технологии проектирования ИС. Выбор технологии проектирования ИС.

2.1 Основные компоненты технологии проектирования ис.

Информационная система создается для управления, поэтому этот процесс должен рассматриваться с двух точек зрения: точки зрения топ менеджеров компании и точки зрения IT-специалистов.

С точки зрения руководства компании информационная система может представлять собой ERP – систему, то есть систему управления ресурсами предприятия или CRM-систему – систему управления взаимоотношениями с клиентами.

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

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

• перенос его с минимальными изменениями в широком диапазоне систем, использующих продукты от разных производителей;

• взаимодействие с другими приложениями, расположенными на локальных или удаленных системах;

• взаимодействие с людьми в стиле, облегчающем переносимость пользователя (ISO/IES 14252:1995).

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

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

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

• требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;

• требуемой пропускной способности системы;

• требуемого времени реакции системы на запрос;

• безотказной работы системы;

• необходимого уровня безопасности;

• простоты эксплуатации и поддержки системы.

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

Основу проекта любой ИС составляют следующие компоненты:

• методология проектирования;

• технологии проектирования;

• стандарты и методики проектирования;

• инструментальные средства проектирования (CASE-средства).

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

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

Технология проектирования ИС – совокупность методологии и средств проектирования ИС, а также методов и средств организации проектирования.

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

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

Индустрия разработки автоматизированных информационных систем управления зародилась в 1950-х - 1960-х годах и к концу века приобрела вполне законченные формы.

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

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

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

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

Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

В числе причин возможных неудач, по мнению разработчиков, фигурируют:

• нечеткая и неполная формулировка требований к ПО;

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

• отсутствие необходимых ресурсов;

• неудовлетворительное планирование и отсутствие грамотного управления проектом;

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

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

• недостаточная поддержка со стороны высшего руководства;

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

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

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

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

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

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

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

1. тесно связанные, предписанные конкретные последовательности шагов;

2. перечень данных, подлежащих накоплению на каждой стадии;

3. критерии завершения работ в контрольных точках;

4. решения, принимаемые при выборе между альтернативными методами проектирования;

5. конкретные стандарты построения информационных систем.

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

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

1. Методологии необходимы для создания больших систем, и АЭИС в частности.

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

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

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

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

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

• поддерживать удобную дисциплину сопровождения, модификации и наращивания системы;

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

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

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

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

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

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

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

• обучаемости путем изменения структуры системы в соответствии с изменением целей системы.

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

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

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

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

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

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

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

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

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

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

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

Принцип первого руководителя предполагает закрепление ответственности при создании системы за заказчиком – руководителем предприятия, который отвечает за ввод в действие и функционирование АЭИС.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• быстрая автоматизация;

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

• обозримость разработки и внедрения системы;

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

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

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

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

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

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