- •«Проектирование ис» 2011
- •1. Понятие информационной системы. Типовые функциональные компоненты ис
- •2. Схема развития ис
- •3. Этапы проектирования ис
- •4. Понятие жизненного цикла ис, модели жизненного цикла информационной системы
- •5. Основные принципы создания ис
- •6. Требования к методологии и технологии разработки ис
- •7. Методология rad
- •8. Методы проектирования ис
- •9. Функционально-ориентированные методологии проектирования. Основные принципы функциональной методики idef0
- •10. Методология idef0. Виды стрелок на диаграммах idef0
- •11. Методология idef0. Нумерация работ и диаграмм. Каркас диаграммы
- •12. Методология idef0. Виды диаграммы idef0
- •13. Диаграммы потоков данных. Назначение. Нотации dfd. Рекомендации по построению
- •14. Основные элементы диаграмм dfd
- •15. Диаграммы dfd. Элементы для декомпозиции данных
- •16. Диаграммы dfd. Управляющие элементы диаграмм
- •17. Методология idef3. Назначение диаграмм. Основные элементы
- •18. Виды перекрестков на диаграммах idef3
- •19. SwimLane диаграммы и построение сценариев SwimLaneDiagrams (диаграмма плавательных дорожек).
- •20. Стоимостной анализ. Принципы связи abc анализа и idef0
- •21. Количественный и качественный анализ диаграмм модели idef
- •22. Моделирование данных. Архитектура ansi-sparc
- •24. Er-диаграммы. Определение сущности, атрибута, связи
- •25. Методология idef1x. Виды и мощности связей. Понятие зависимых и независимых сущностей
- •26. Методология idef1x. Виды зависимых сущностей
- •27. Нормальные формы er-диаграмм. Получение реляционной схемы из er-диаграмм
- •28. Реляционная модель данных. Структурная часть. Управляющая связь. Виды ключей
- •29. Реляционная модель данных. Набор ограничений целостности. Операции, нарушающие целостность
- •Ограничения кортежа.Ограничения целостности кортежапредставляют собой ограничения, накладываемые на допустимые значенияотдельногокортежа отношения, ине являющиесяограничением целостности атрибута.
- •30. Реляционная алгебра. Теоретико-множественные операции
- •31. Реляционная алгебра. Специальные операции
- •32. Реляционная модель данных. 1нф, 2нф, 3нф, нфбк
- •33. Реляционная модель данных. Нормальные формы более высоких порядков
- •36. Язык моделирования uml. Назначение. Характеристики. Перечень диаграмм
7. Методология rad
Rapid Application DevelopmentНа фазе построения осущ и тестирован системы. RAD явл пригодн для достаточн небольш проектов, в котор присутств ярко выраж интерфейсн часть. Оценка размера прилож производ на основе функций элементов(экран, сообщ, отчеты, файлы). На этапе проектир испол CASE средства. В настоящее время широко распространена, реализует подход в рамках разработки ИС. Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:
небольшую команду программистов (от 2 до 10 человек);
короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Каждый прототиппостепенно развивается в частьбудущей системы. Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, определяется следующим образом: < 1000 функциональных элементов один человек 1000-4000 функциональных элементов одна команда разработчиков > 4000 функциональных элементов 4000 функциональных элементов на одну команду разработчиков В качестве итога перечислим основные принципы методологии RAD:
разработка приложений итерациями;
необязательность полного завершения работ на каждом из этапов жизненного цикла;
обязательное вовлечение пользователей в процесс разработки ИС;
необходимое применение CASE-средств, обеспечивающих целостность проекта;
применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
необходимое использование генераторов кода;
использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;
тестирование и развитие проекта, осуществляемые одновременно с разработкой;
ведение разработки немногочисленной хорошо управляемой командой профессионалов;
грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
8. Методы проектирования ис
Методологии, технологии и инструментальные средства проектирования (CASE (Computer Aided Software Engineering – Автоматизированная разработка ПО)-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ. Любая технология представляет собой организованную и оформленную в нормативно – технических и организационно – правовых документов систему методов, стандартов, правил и приемов выполнения работ, а также инструментальных средств их автоматизации, обеспечивающую эффективную и управляемую процедуру получения продукции с заданными свойствами для заданных или заранее оговоренных условий. Методология, опираясь на теорию, вырабатывает и рекомендует обоснованные приемы и рецепты для технологии и также частично пересекается и сливается с технологией. Технология проектирования определяется как совокупность трех составляющих:
пошаговой процедуры, определяющей последовательность технологических операций проектирования (рис. 1.4);
критериев и правил, используемых для оценки результатов выполнения технологических операций;
нотаций (графических и текстовых средств), используемых для описания проектируемой системы.
Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций.КлассификацияПо степени автоматизации
Ручного проектирования
Компьютерные программы
По степени использования типовых решений
Оригинального проектирования (канонич-е)-разработка с нуля
Типового проектирования-предпол.конфигурацию ИС из готовых типовых проектных решений
По степени аадаптивности проектных решений
Реконструкции (переработка отдельных компонентов)
Параметризация (настройка параметров)
Структуризация (изменение модели)
Выделяют два класса:
Каноническое проектирование (оригинальное, ручное, реконструкция)
Типовое (типовое, компьютерное, реструктуризация)
Необходимость использ-я типового пр-я (ТПР) обусловливается тем, что при таком подходе существенно снижены затраты на разработку, а также тем, что при оригинальном проектировании очень трудно обеспечить должный научно-технический уровень. ТПР – комплект тех.документации, сод-й пр.решение, предн-е для многократ.испол-я в процессе разработки, внедрения и функц-я ИС с целью понижения трудоемкости и затрат на ее создание. Основой типового проектирования является декомпозиция функциональных элементов системы:
использует элементный метод (по отдельному виду задачи):
Сущность заключается в комплектации ИС из множества ТПР по отдел.задачам. Недостаток -большие затраты времени на сопряжение элементов и ввиду этого - плохая адаптивность.
Подсистемный:
В качестве элементов типизации выступают отдельные подсистемы.
Объектный:
Использование ТПР, включ.в себя полный набор, необходимый для функц-я ИС.