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




Скачать 173.06 Kb.
НазваниеПроектирование информационных систем. Лекция №1. Классификация информационных систем
Дата публикации24.04.2013
Размер173.06 Kb.
ТипЛекция
odtdocs.ru > Информатика > Лекция
Проектирование информационных систем. Справочная информация.
I семестр, лекции (8 часов), 2 лабораторных.

II семестр, лекции (8 часов), 8 лабораторных, 4 практики, 1 курсовой проект.

Проектирование информационных систем. Лекция №1.
Классификация информационных систем
а) по типу хранимых данных

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

  • документальные (документы: текстовые, графические; индексация).


б) по степени автоматизации

  • ручные;

  • автоматизированные (совместное использование компьютера и человека);

  • автоматические (самостоятельная работа без участия человека).


в) по сфере применения

  • интегрированные (охватывают все сферы деятельности предприятия или организации: аккумулируют функции САПР, управления ТП и организационного управления);

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

  • организационного управления (поддержка функций управленческого персонала по объектам — менеджмент систем)

  • управления ТП (система управления технологическими процессами);

  • САПР (система автоматизированного проектирования).


г) по характеру обработки

  • Информационно-поисковые (минимальная обработка информации);

  • Информационно-решающие (системы, включающие в себя функции по выработке решений);

    • Управляющие (управляющая и создающая воздействие на систему);

    • Советующие (уведомляют человека о ситуациях и способах решения проблем).


д) по уровню управления

  • Стратегические (системы, осуществляющие управление на высшем уровне);

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

  • Операционные (системы, поддерживающие работу специалиста на рабочем месте).


^ Функциональное назначение модулей корпоративной ИС


Подсистема маркетинга


























































































^ Классификация рынка информационных систем
Локальные системы;

Малые интегрированные системы (1C: Предприятие);

Средние интегрированные системы (Microsoft Dynamics AX);

Крупные интегрированные системы IC (SAP/R3, OEBS: Oracle E-Business Suite).
^ Основные задачи, решению которы должна способствовать методология проектирования ИС


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



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



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



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


См. лоскутная разработка.
Примечание: в 1994 г. в США были собраны статистические данные о внедрении проектов ИС. Проваленными оказалось более 30% проектов, так и не оказавшихся внедрёнными. Их стоимость превышала 80 млрд. долларов. Выполнены в срок — 16%.
^ Проектирование ИС охватывает три основные области


  1. Проектирование объектов данных, которые будут реализованы в базе данных;



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



  3. Учёт конкретной среды или технологии: топологии сети, аппаратные средства, архитектура, параллельная разработка, распределённая разрабокта данных и.т.п.


Разрабатываемой ИС должны обеспечиваться


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

  2. Требуемая пропускная способность системы;

  3. Требуемое время реакции системы на запрос;

  4. Безотказная работа системы;

  5. Необходимый уровень безопасности;

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


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


  1. Формирование требований к ИС;

  2. Проектирование;

  3. Реализация;

  4. Тестирование;

  5. Ввод в действие;

  6. Эксплуатация и сопровождение.


Жизненный цикл программного обеспечения ИС
Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе её создания и использования.
^ Модель жизненного цикла — структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукат в течение все жизни системы, от определения требований до завершения её использования.
^ Классические технологии программирования
А) Каскадный технологический подход

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

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


Причины сохранения популярности каскадных моделей

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

  2. Иллюзия снижения рисков участников проекта заказчика и исполнителя;

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


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


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





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

  • нехватка специалистов

  • нарушение сроков и бюджет разработки

  • создание ПО с нессответствующей функциональностью

  • разработка неправильного интерфейса

  • выполнение доработок и улучшений




Спиральная модель использует итерационный процесс разработки. При этом основное внимание уделяется стадиям анализа и проектирования. На этих стадиях создаются прототипы ПО (ПП), предназначенные для проверки решений. Итерация – законченный цикл разработки, заканчивающийся выпуском внутренней или внешней версии ПП, который дорабатывается на последующих итерациях. В этом случае разработка приобретает спиралевидный характер.
Каждый виток спирали соответствует созданию фрагмента или версии программного продукта. На нём уточняются цели и характеристики проекта, определяется его качество, планируется работа на следующем витке спирали. Анализ риска – «следует ли выполнять следующий процесс». Если риски слишком велики, то цикл прекращается. Использование спиральной модели позволяет осуществлять переход на следующую стадию выполнения проекта не дожидаясь полного завершения текущей. Основная задача: быстро создать продукт, который можно показать заказчику или пользователю. Таким образом упрощается процесс внесения изменений (дополнений) в проект.

Б) Каскадный технологический подход
Рациональный унифицированный процесс


  • IBM (Rational Software)

  • Rational Unified Process (RUP)

  • Computer Associates

  • Erwin Data Modeler, Process Modeler



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

  • итерационный подход

  • использование моделей вместо бумажных документов. (UML – Unified Modeller Language)

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

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

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


^ Разработка проекта при РУП предполагает прохождение четырёх фаз:


  1. Начало (inseption)

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

  2. Исследование (elaboration)

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

  3. ^ Построение (construction)

    Создание программного продукта.

  4. Внедрение (transition)

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



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

Предполагает синтез программы по её спецификации.

  1. Ручное (написание программного кода на языке программирования)

  2. Автоматическое (генерация программы на основе спецификации, составленной на формальном языке). Например, UML, IBM Rational Rose, IBM Rational XDE


^ Сборочное программирование

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




  1. Модульное

    Основано на методологиях модульного императивного программирования.

  2. ^ Объектно-ориентированное сборочное программирование

    Основано на методологии объектно-ориентированного программирования, предполагает распределение библиотек классов в виде исходных текстов, либо в бинарном (DLL – Dynamic Link Library)

  3. ^ Компонентное сборочное программирование

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

  4. ^ Аспектно-ориентированное программирование

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





^ Конкретизирующее программирование

Конкретизирующее программирование основано на системном использовании при построении программы созданных ранее параметрических заготовок и рациональных проектных решений с использованием паттернов. Наиболее известной разновидностью является подход с использованием паттернов программирования.
Паттерн-проектирование – (англ. Design Pattern) формальное оаписание задач проектирования, успешное решение данной задачи, рекомендации по применению различных решений. Например, паттерн «введение объекта параметров», который облегчает повторное использование проектных и архитектурных решений. Конкретной программой может трактоваться как адаптация некой универсальной программы к конкретному слою применения.
^ Г) Технологии на основе формальных преобразований
Технология стерильного цеха (cleanroom process model) предназначен для надёжного создания приложений, не содержащих ошибок, их недопущение. Технология основана на модульном принципе организации разработки.


Модули:

  1. Чёрный ящик (black box)

  2. Модуль описатель (state box)

  3. Прозрачный ящик (white box, clear box)


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

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

  • логический (дедуктивный)

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

  • аналитический

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


^ Формальное сборочное программирование

Это объединение ранее созданных фрагментов спецификации.
Г) Гибкие технологии программирования
Ранние технологические подходы быстрой разработки

Все эти подходы объединяют итеративный характер разработки (прототипы) и тесно взаимодействуют с заказчиком.
^ Эволюционное прототипирование (Evolution prototyping)

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






^ Итеративная разработка (Iterative development)

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

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

Возникли как поддерживающие изменения.
Экстремальное программирование

Не придерживается традиционных подходов, в особенности к отношению к каскадным. Вместо одномоментного планирования и проектирования, эти операции выполняются постепенно в ходе разработки, что позволяет максимально сократить стоимость изменений в проекте. (см. модульное тестирование, парное программирование, рефакторинг, режим труда и отдыха).
Цикл разработки. Разработка проекта начинается с того, что заказчик предлагает разработчикам часть функциональности (истории пользователя, user story). «История» представляет собой описание некоторых подзадач с точки зрения заказчика, которые описываются на естественном языке. После выполнения задания получаем ещё один кусок функциональности. Для каждой истории оцениваются ресурсы для реализации и необходимое время. Это позволяет точно выдерживать срок разработки.





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

  • программисты сами составляют тесты

  • это делается до начала разработки


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


  • Доверие

  • Коллективное владение кодом. Любой программист может в любой момент изменить код.

  • Парное программирование (pair programming). В случае возникновения вопросов, проводится короткое собрание.





Адаптивная разработка (Adaptive software development)
Фазы:

  • планирование

  • общение

  • обучение

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

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

  2. Отсутствует возможность заранее спланировать необходимые ресурсы.

  3. Процесс разработки максимально ориентирован на особенности личности разработчика.


^ Компьютерный дарвинизм

Представляет собой метод проб и ошибок с интенсивным тестированием. Основа разработки – ряд программ или компонентов, которые дорабатываются и совершенствуются. Более крупные блоки программ строятся из более мелких. То есть считается, что программное обеспечение «эволюционирует».
Стандарты в области разработки ИС
ГОСТ 34.601-90 — распространяется на автоматизированные системы и устанавливает стадии и этапы их создания;

ГОСТ 34.602-90 — структура технического задания;

ГОСТ 34.X-90 — ГОСТ в рамках каскадной модели разработки


ISO/IEC 12207:1995 — стандарт на процессы и организацию жизненного цикла ПО.

Custom Development Method (Oracle)

Ration Unified Process (RUP, язык UML)

Microsoft Solution Framework (MSF)

Extreme Programming (XP)
Процессы ЖЦ ПО
Процесс ЖЦ — совокупность взаимосвязанных действий, преобразующих входные данные в выходные. Процессы делятся на три группы:
^ Основные процессы

Приобретение

Поставка

Разработка

Эксплуатация

Сопровождение

Вспомогательные процессы

Документирование

Управление конфигурацией

Обеспечение качества;

Разрешение проблем;

Аудит;

Аттестация

Совместная оценка;

Верификация

Административные процессы

Хозяйственные процессы (Интернет, отопление)

Организационные процессы

Создание инфраструктуры

Управление

Обучнеие

Усовершенствование

Каноническое проектирование ИС


ГОСТ 304.601 «Стадии и этапы создания автоматизированной системы»

  1. Формирование требований к ИС (подготовка, анализ требований);

  2. Разработка концепции информационной системы (изучение объекта, научно-технические работы, );

Добавить документ в свой блог или на сайт

Похожие:

Проектирование информационных систем. Лекция №1. Классификация информационных систем
Информационно-решающие (системы, включающие в себя функции по выработке решений)

Проектирование информационных систем
Создание сайта подразумевает собой учитывание требований заказчика (бизнес-процессы) и целей проекта (бизнес-целей), информационных...

Лабораторная работа №3 по дисциплине «Проектирование информационных систем»
Провести проектирование состава и интерфейса страниц каталога. Разработать для этого сле­дующие элементы

Лабораторная работа №1 по дисциплине «Проектирование информационных систем»
Провести проектирование для интернет-магазина следующих элементов: личного кабинета, форм авторизации, регистрации и восстановления...

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

Вопросы к экзамену по «Основам построения аис»
Понятия «система», «информационная система». Отличие систем друг от друга. Этапы развития информационных систем. 2

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

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

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

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

Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
odtdocs.ru
Главная страница