Главная страница
Культура
Искусство
Языки
Языкознание
Вычислительная техника
Информатика
Финансы
Экономика
Биология
Сельское хозяйство
Психология
Ветеринария
Медицина
Юриспруденция
Право
Физика
История
Экология
Промышленность
Энергетика
Этика
Связь
Автоматика
Математика
Электротехника
Философия
Религия
Логика
Химия
Социология
Политология
Геология

Информационные технологии Часть 2



Скачать 0.75 Mb.
НазваниеИнформационные технологии Часть 2
Анкорconsp2.doc
Дата28.04.2017
Размер0.75 Mb.
Формат файлаdoc
Имя файлаconsp2.doc
ТипДокументы
#4749
страница1 из 7
  1   2   3   4   5   6   7

Информационные технологии

Часть 2

Содержание

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

Общие требования к методологии и технологии проектирования 2

Жизненный цикл ИС 4

Стандарт ISO/IEC 12207 5

Комплекс стандартов ГОСТ 34 8

Концептуальное проектирование 10

Модели ИС и методики проектирования 11

Диаграммы потоков данных (DFD). 14

Структурный анализ и проектирование (SADT) 18

Диаграммы сущность-связь (ERD) 20

Диаграммы переходов состояний (STD) 24

Методики проектирования IDEF 26

Объектно-ориентированное моделирование 33

CASE- системы 35

ARIS (Architecture of Integrated information Systems) 37

ИТ как научно-техническая дисциплина 40

Открытые информационные системы 41



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


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

Традиционно процесс проектирования баз данных и основанных на них АИС делится на три этапа, называемых концептуальным, логическим и физическим проектированием Начальной стадией проектирования системы является разработка модели предметной области, которая базируется на изучении описания предметной области, представленного в соответствующих документах и анализе информационных потребностей будущих пользователей разрабатываемой системы. Эту стадию принято называть концептуальным проектированием системы, а её результат – концептуальной моделью предметной области.1 Отечественные специалисты использовали в 70-80-е годы для обозначения этой стадии термины «инфологическое проектирование», «инфологическая модель», отдавая дань шведской школе проектирования информационных систем2.

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

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

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

Общие требования к методологии и технологии проектирования


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

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

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

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

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




Рис 10

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

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

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

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

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

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

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

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

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

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

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

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

  • стандарт оформления проектной документации;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



  1   2   3   4   5   6   7
написать администратору сайта