Студопедия

Главная страница Случайная страница

КАТЕГОРИИ:

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Проектирование информационных систем.






План

1. Принципы проектирования информационных систем.

2. Этапы разработки автоматизированных информационных систем.

3. Модели жизненного цикла программного обеспечения.

4. Методология и технологии проектирования информационных систем.

5. Структурный подход к проектированию информационных систем.

Вопрос №1. Принципы проектирования информационных систем.

 

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

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

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

2. Принцип «Сверху-вниз». Быстрый рост числа акционерных и частных предприятий и банков позволил некоторым компаниям увидеть будущий рынок и инвестировать средства в создание программного аппарата для этого растущего рынка. Из всего спектра проблем разработчики выделили наиболее заметные:

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

• автоматизацию технологических процессов.

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

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

• управление трудовыми ресурсами;

• управление сбытом;

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

• управление запасами;

• бухучет;

• анализ хозяйственной деятельности;

• управление производством и т.п.

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

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

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

4. Принцип «пласта». Метод «пласта» заключается в автоматизации функционирования этой информационной системы всего предприятия в целом. Метод также применим для иерархических структур нижних уровней (для автоматизации работы отделов или служб). Для построения автоматизированной системы требуется:

• описать информационную систему (определить потоки данных);

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

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

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

При этом автоматизированная информационная система должна обладать следующими свойствами:

ü подсистемы должны быть совместимыми друг с другом и использовать общие информационные массивы;

ü сбором информации должна заниматься специальная подсистема, а не каждая подсистема самостоятельно и только для себя;

ü информационные массивы подсистем должны быть связаны для обмена данными между собой.

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

 

Вопрос №2. Этапы разработки автоматизированных информационных систем.

 

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

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

• получение информации;

• переработка информации;

• анализ, подготовка и принятие решения.

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

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

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

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

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

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

• обеспечения средств коммуникации, например: электронной факса, печати документов;

• сохранения целостности данных в общей базе данных;

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

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

Вопрос №3. Модели жизненного цикла программного обеспечения.

 

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

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

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

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

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

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

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

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

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

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

 

Вопрос №4. Методология и технологии проектирования информационных систем.

 

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

Технология проектирования определяется как совокупность трех составляющих:

1. пошаговой процедуры, определяющей последовательность технологических операций проектирования;

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

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

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:

• поддерживать полный ЖЦ ПО;

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

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

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

• обеспечивать минимальное время получения работоспособной ИС;

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

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

• быть поддержанной комплексом согласованных САST-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.

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

Стандарт проектирования должен устанавливать:

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

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

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

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

Стандарт оформления проектной документации должен устанавливать:

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

• требования к оформлению документации (включая требования к содержанию разделов, подразделов, пунктов, таблиц и т.д.);

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

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

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

Стандарт интерфейса пользователя должен устанавливать:

• правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

• правила использования клавиатуры и мыши;

• правила оформления текстов помощи;

• перечень стандартных сообщений;

• правила обработки реакции пользователя.

Вопрос №5. Структурный подход к проектированию информационных систем.

 

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

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

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

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

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

• принцип абстрагирования предлагает выделение существенных аспектов системы и отвлечение от несущественных;

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

• принцип непротиворечивости предусматривает обоснованность и согласованность элементов;

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

 

ЛЕКЦИЯ №7:


Поделиться с друзьями:

mylektsii.su - Мои Лекции - 2015-2024 год. (0.013 сек.)Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав Пожаловаться на материал