Вопрос № 1

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

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

В н. в. единого определения ИС нет и нет единой их классификации.

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

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

Разнообразие проблем, решаемых с помощью ИС привело к появлению разнотипных систем, различающихся принципами построения и заложенными в них правилами обработки информации. ИС можно классифицировать по различным признакам:

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

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

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

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

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

В зависимости от сферы применения различают различные класс АИС:

1. Системы организационного управления предназначены для автоматизации функций управленческого персонала.

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

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

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

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

Вопрос № 2.

Обеспечение автоматизированных информационных систем

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

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

2. Лингвистическое обеспечение – совокупность средств и правил, для формализации естественного языка, используемого при общении пользователя и эксплуатационного персонала ИС, причем они делятся на 2 группы: традиционные и языки для диалога с ЭВМ.

3. Математическое обеспечение – совокупность математических методов и алгоритмов, применяемых ИС.

4. Методическое обеспечение – совокупность документов, устанавливающих организационную структуру, права и обязанности пользователей.

5. Правовое обеспечение – совокупность правовых норм, регламентирующих правовое отношение при функционировании ИС.

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

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

Архитектура АИС – это организационная структура автоматизированной системы.

Выделяют 2 уровня архитектуры ИС:

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

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

Вопрос № 3

Жизненный цикл АИС. Процессы жизненного цикла.

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

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

Процесс проектирования ИС регламентирован определенной документацией (стандартами, методологиями, моделями).

Среди основных процессов жизненного цикла самыми важными являются:

Разработка, эксплуатация и сопровождение.

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

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

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

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

Вопрос № 4

Модели жизненного цикла АИС (каскадная, спиральная, итерационная).

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

Модели ЖЦ ИС отражают состояние системы с момента создания необходимости данной ИС до полной ее утилизации. Выбранной модели ЖЦ зависит от специфики, масштаба, сложности проекта и набора условий в которых ИС создается и функционирует.

Модель ЖЦ включает:

1. Стратегии;

2. результаты выполнения работ на каждой стадии;

3. ключевые события или точки завершения работ и принятие решений.

В соответствии с моделями ЖЦ ПО определяют – каскадная, итерационная, спиральная.

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

Выделяют 5 устойчивых этапов разработки:

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

• Проектирование (здесь разрабатываются те или иные проектные решения, в результате появляются проекты комплексной документации).

• Реализация (здесь разрабатывается ПО в соответствии с проектными решениями предыдущего этапа).

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

• Ввод в действие (здесь происходит сдача готового проекта).

Недостатки:

1. Существенная задержка в получении результатов.

2. Ошибки и недоработки на любом из этапов появляются на последующих этапах работ, что приводит к необходимости возврата.

3. Сложность параллельного ведения работ по проекту.

4. чрезмерная информационная перенасыщенность каждого из этапов.

5. сложность управления проектом.

6. Высокий уровень риска и ненадежность инвестиций.

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

Преимущество в том, что межэтапные кодировки обеспечивают меньшую трудоемкость разработки.

Недостатки:

1. Время жизни каждого этапа растягивается на весь период разработки.

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

3. Трудоемкость использования документации на стадии внедрения и эксплуатации.

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

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

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

Преимущества – итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика.

Недостатки:

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

Вопрос № 5

Технология проектирования АИС. Их классификация

Технология проектирования АИС — это совокупность методов и средств проектирования АИС, а также методов и средств организации проектирования (управление процессом создания и модернизации проекта АИС). В основе технологии проектирования лежит технологический процесс (ТП), который определяет действия, их последовательность, состав исполнителей, средства и ресурсы, требуемые для выполнения этих действий.  Согласно технологическому процессу проектирования АИС представляет собой совокупность последовательно-параллельных, связанных и со- подчиненных цепочек действий, каждое из которых может иметь свой предмет.

АИС. Выделяются два основных класса технологии проектирования: каноническая и индустриальная.

Индустриальная технология проектирования в свою очередь разбивается на два подкласса: автоматизированное (использование CASE – технологий) и типовое(параметрических - ориентированное или модельно-ориентированное) проектирование. Использование индустриальных технологий проектирования не исключает использования в отдельных случаях канонической технологии. 

Каноническое проектирование АПС ориентировано на использование главным образом каскадной модели жизненного цикла АИС. 

Проектирование включает в себя фазы:

1. Базовые проектные работы

2. Разработка частных технических заданий

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

4. Составление технических спецификаций и инструкций

5. Представление проектной разработки

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

• Выполнение работ по разработке ПО

• Подготовка к внедрению системы

• Контроль и регулирование основных показателей проекта

Ввод системы в эксплуатацию.

Основные виды работ:

• Комплексные испытания

• Подготовка кадров для эксплуатации создаваемой системы

• Подготовка рабочей документации

• Сдача системы заказчику

• Сопровождение, поддержка, сервисное обслуживание

• Оценка результатов проекта и подготовка итоговых документов

• Разрешение конфликтных ситуаций и закрытие работ по проекту

• Накопление опытных данных для последующих проектов, анализ опытов, состояние и определение навыков развития.

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

Наиболее часто на начальных фазах допускаются следующие ошибки:

1. Ошибки в определении интересов заказчика

2. Концентрация на маловажных интересах

3. Неправильная интерпретация исходной задачи

4. Непрерывное и недостаточное понимание деталей

5. Неполнота системных требований

6. Ошибки в определении требуемых ресурсов и сроков

7. Резкая проверка на согласование этапов и отсутствие контроля со стороны заказчика

Вопрос № 6

Методы проектирования АИС. Их классификация

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

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

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

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

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

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

Методы проектирования  АИС можно классифицировать:

1. По степени использования средств автоматизации, типовых проектных решений, адаптивности к предполагаемым изменениям. 

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

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

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

2.  По степени использования типовых проектных решений различают: 

• оригинальное (индивидуальное) проектирование, когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к АИС; 

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

Оригинальное проектирование АИС предполагает максимальный учет особенностей автоматизированного объекта. 

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

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

• реконструкция — адаптация проектных решений выполняется путем переработки соответствующих компонентов (перепрограммирования программных модулей); 

• параметризация — проектные решения настраиваются в соответствии с заданными и изменяемыми параметрами; 

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

Вопрос № 7

Каноническое проектирование АИС. Стадии и этапы создания АИС

В основе канонического проектирования лежит каскадная модель жизненного цикла ИС.

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

1) исследование и обоснование создания системы;

2) разработка технического задания;

3) создание эскизного проекта;

4) техническое проектирование;

5) рабочее проектирование;

6) ввод в действие;

7) функционирование, сопровождение, модернизация.

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

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

Стадия 1. Формирование требований к ИС. На начальной стадии проектирования выделяют следующие этапы работ:

обследование объекта и обоснование необходимости создания ИС;

формирование требований пользователей к ИС;

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

Стадия 2. Разработка концепции ИС.

изучение объекта автоматизации;

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

оформление отчета и утверждение концепции.

Стадия 3. Техническое задание.

разработка и утверждение технического задания на создание ИС.

Стадия 4. Эскизный проект.

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

разработка эскизной документации на ИС и ее части.

Стадия 5. Технический проект.

разработка проектных решений по системе и ее частям;

разработка и оформление документации на ИС и ее части;

разработка заданий на проектирование в смежных частях проекта.

Стадия 6. Рабочая документация.

разработка рабочей документации на ИС и ее части;

разработка и адаптация программ.

Стадия 7. Ввод в действие.

подготовка объекта автоматизации;

подготовка персонала;

комплектация ИС поставляемыми изделиями

строительно-монтажные работы;

пусконаладочные работы;

проведение предварительных испытаний;

проведение опытной эксплуатации;

проведение приемочных испытаний.

Стадия 8. Сопровождение ИС.

выполнение работ в соответствии с гарантийными обязательствами;

послегарантийное обслуживание.

Вопрос № 8

Что такое техническое задание

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

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

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

Частные технические задания

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

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

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

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

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

Необходимость тз

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

Задание может быть чётко определено, например, когда всю работу ведет один человек, либо оно выдано авторитетным специалистом, либо не может быть подвергнуто сомнению (госзаказ). Но чаще оно формулируется в общих чертах на языке потребителя-неспециалиста, далёким от языка разработчика и терминов предметной области. Неопределенные требования вызывают неуверенность у всех участников работ, так как допускают различное толкование требований и не позволят объективно оценить качество разработанного изделия. Также, разработчик должен понимать, что заказчик может не знать (или знает частично) специальных требований, что не снимает с разработчика ответственности и обязательности выполнения требований надзорных органов независимо от их наличия в задании. Таким образом, не только заказчик, но и разработчик (исполнитель) являются ответственными за постановку целей разработки и полезность ее результата.

Составление ТЗ — сложная и ответственная задача: многие данные ещё не известны, но то, как задание будет поставлено, способно облегчить или затруднить последующее проектирование (образно говоря, «как корабль назовешь, так он и поплывет»).

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

Как инструмент коммуникации в связке общения заказчик-исполнитель, ТЗ позволяет:

Обеим сторонам:

представить (вообразить) готовый продукт,

выполнить попунктную проверку готового продукта (приёмочное тестирование — проведение испытаний),

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

Заказчику:

осознать, что именно ему нужно,

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

требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ.

Исполнителю:

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

спланировать выполнение проекта и работать по намеченному плану,

отказаться от выполнения работ, не указанных в ТЗ.

Вопрос № 9

Методология разработки информационных систем, ее задачи

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

1. Соответствие создаваемой ИС целями и задачами предприятия

2. Гарантирование создания систем с заданными параметрами

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

4. Соответствие создаваемой ИС требованиям открытости, переменчивости

5. Возможности использования в системе разработанных заранее информационных технологий

Методологии, технологии, инструментальные средства проектирования CASE – средства составляют основу проекта.

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

1. Заданная последовательность выполнения технических операций

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

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

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

1. Данные, полученные из проделанной операции

2. Методические материалы, инструкции, нормативы, стандарты

3. Программные и технические средства

4. Исполнители

Требования, которым должна удовлетворять технология проектирования:

1. Поддерживать ЖЦ ИС

2. Гарантированное достижение цели разработки ИС с заданным качеством

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

4. Обеспечить возможность ведения работ по проектированию отдельных подсистем

5. Обеспечивать минимальное время работоспособности системы

Вопрос № 10

Методология быстрой разработки приложений RAD? Ее сущность

Основные особенности методологии RAD Методология разработки информационных систем, основанная на использовании средств быстрой разработки приложений, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки прило­жений — RAD (Rapid Application Development). Данная методология охватывает все этапы жизненного цикла современных информационных систем. RAD — это комплекс специальных инструментальных средств быстрой разработки прикладных информационных систем, позволяющих оперировать с определенным набором графических объектов, функционально отображающих отдельные информационные компоненты приложений. Под методологией быстрой разработки приложений обычно понимается процесс разработки информационных систем, основанный на трех основных элементах:  1. небольшой команде программистов (обычно от 2 до 10 человек); 

2. тщательно проработанный производственный график работ, рассчитанный на сравнительно короткий срок разработки (от 2 до 6 мес.);

3. итерационная модель разработки, основанная на тесном взаимодействии с за­казчиком — по мере выполнения проекта разработчики уточняют и реализуют в продукте требования, выдвигаемые заказчиком. Основные принципы методологии RAD можно свести к следующему:  1. используется итерационная (спиральная) модель разработки;

2. полное завершение работ на каждом из этапов жизненного цикла не обяза­тельно;

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

4. необходимо применение CASE-средств и средств быстрой разработки приложений;

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

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

7. тестирование и развитие проекта осуществляются одновременно с разработкой;

8. разработка ведется немногочисленной и хорошо управляемой командой про­фессионалов;

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

При разработке приложений с помощью инструментов RAD используется множе­ство готовых объектов, сохраняемых в общедоступном хранилище. Однако обес­печивается и возможность разработки новых объектов. При этом новые объекты могут разрабатываться как на основе существующих, так и «с нуля». Инструментальные средства RAD обладают удобным графическим интерфейсом пользователя и позволяют на основе стандартных объектов формировать простые приложения без написания кода программы. Это является большим преимуще­ством RAD, так как в значительной степени сокращает рутинную работу по разра­ботке интерфейсов пользователя (при использовании обычных средств разработ­ка интерфейсов представляет собой достаточно трудоемкую задачу, отнимающую много времени). Высокая скорость разработки интерфейсной части приложений позволяет быстро создавать прототипы и упрощает взаимодействие с конечными пользователями. Таким образом, инструменты RAD позволяют разработчикам сконцентрировать усилия на сущности реальных деловых процессов предприятия, для которого со­здается информационная система. В итоге это приводит к повышению качества разрабатываемой системы. Методология RAD неприменима не только для создания типовых информацион­ных систем, но и для построения сложных расчетных программ, операционных систем или программ управления сложными инженерно-техническими объекта­ми — программ, требующих написания большого объема уникального кода. Методология RAD не может быть использована для разработки приложений, в ко­торых интерфейс пользователя является вторичным, то есть отсутствует нагляд­ное определение логики работы системы. Примерами таких приложений могут служить приложения реального времени, драйверы или службы. Совершенно неприемлема методология RAD для разработки систем, от которых зависит безопасность людей, — например, систем управления транспортом или атомных электростанций. Это обусловлено тем, что итеративный подход, являю­щийся одной из основ RAD, предполагает, что первые версии системы не будут полностью работоспособны, что в данном случае может привести к серьезнейшим катастрофам.

Вопрос № 11

Сущность предметной области информационных систем и этапы анализа

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

1. Разработать стратегию комплексной автоматизации.

2. Провести анализ деятельности предложения.

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

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

1. Цели

2. Способ автоматизации (по участкам, направлениям, комплексной автоматизации)

3. Долгосрочная техническая политика

4. Ограничения

5. Процедура управления изменениями плана

Стратегия автоматизации в первую очередь должна соответствовать приоритетам и задачам бизнеса и определять пути достижения этого соответственно.

Важной особенностью автоматизации являются:

1. Снижение стоимости продукции

2. Увеличение количества или ассортимента

3. Разработка новых товаров и услуг

4. Переход от производства «на склад» к производству «под конкретного заказчика»

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

Под анализом деятельности предприятия понимается сбор и предоставление информации о деятельности предприятия в формализованном виде, пригодном для принятия решения о разработке определенного класса АИС.

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

Вопрос № 12

Модель сущность – связь

Модель “сущность - связь” (МСС) (entity - relation diagram - ERD) является неформальной моделью предметной области (ПО) и используется на этапе инфологического проектирования БД. Моделируются объекты ПО и их взаимоотношения.

Достоинства МСС:

относительная простота;

однозначность;

применение естественного языка;

доступность для понимания.

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

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

“Время” в составе конструктивных элементов отсутствует, но может быть представлено в модели посредством атрибутов (напр.: ГОД-РОЖДЕНИЯ-ПОЛУЧЕНО-В-ИЮНЕ,...).

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

Примеры сущностей:

материальные:	нематериальные:
-предприятие;	-описание явления;
-изделие;	-рефераты научных статей;
-сотрудники;	-описание структур данных;

В моделях МСС каждая рассматриваемая сущность является основным местом сбора информации об этой сущности.

“Тип сущности” определяет множество однородных объектов, а “экземпляр сущности” - конкретный объект из множества.

Каждая сущность должна иметь имя. Например, сущность "СТУДЕНТ".

“Атрибут” (А) - поименованнная характеристика сущности. При помощи атрибутов моделируются свойства сущностей: (сущность: КНИГА, атрибуты: НАЗВАНИЕ, АВТОР, ГОД-ИЗДАНИЯ).

Основная роль атрибутов - описание свойств сущности. Другая роль - идентификация экземпляра сущности. То есть каждый экземпляр сущности должен иметь уникальное имя. В качестве имени выступает один или несколько атрибутов. Например, "НОМЕР ЗАЧЕТНОЙ КНИЖКИ" или "НОМЕР" и "СЕРИЯ ПАСПОРТА".

“Связь” - средство представления отношений между сущностями в модели ПО. Тип связи рассматривается между типами сущностей, например, между сущностями СТУДЕНТ и ГРУППА может быть связь УЧИТЬСЯ. То есть введение связи между двумя сущностями отражает семантику некоторого предложения. В данном случае, это СТУДЕНТ УЧИТСЯ В ГРУППЕ. Конкретный экземпляр связи данного типа существует между конкретными экземплярами данных типов сущностей. Например, ИВАНОВ УЧИТСЯ КМ-31.

В модели "сущность-связь" поддерживаются бинарные связи. В общем случае в ПО могут быть n - арные связи между сущностями.

Вопрос № 13

Общая характеристика CASE – средств

CASE-средства (Computer Aided Software Engineering) - это программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.

До сих пор не существовало устойчивой классификации CASE - средств.