Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Proektirovanie_IS-0832.doc
Скачиваний:
3
Добавлен:
13.11.2019
Размер:
384.51 Кб
Скачать

Список ответов по дисциплине «Проектирование ИС»

1. Определение ИС. Состав подсистем ИС.

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

2. Классификация ИС по характеру обработки данных. Характерные отличия и задачи систем.

По характеру обработки данных ИС делятся на:

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

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

3. Понятие «жизненный цикл» ИС. Модели ЖЦ и их этапы. Методики разработки ИС, соответствующие моделям ЖЦ.

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации[1]. Этот цикл — процесс построения и развития ПО.

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

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

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

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

Рис. 1.1. Каскадная схема разработки ПО

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

Рис. 1.2. Реальный процесс разработки ПО по каскадной схеме

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (рис. 1.3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

Рис 1.3. Спиральная модель ЖЦ

4. Состав команды разработчиков ИС.

Руководитель, аналитик, программист

5. Работы, выполняемые на стадии технического проектирования ИС.

6. Причины, обуславливающие сложность проектирования ИС.

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

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

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

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

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

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

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

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

•масштабы разработки ЭИС;

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

•различные факторы старения указанных элементов;

•разный временной цикл существования и темпов обновления элементов;

•длительность процесса проектирования системы;

•индивидуальность проекта, обусловленную спецификой объекта проектирования;

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

7. Классификация технологий проектирования ис и их отличия.

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

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

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

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

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

По характеру адаптации проектные решения технологии типового проектирования можно разделить на 2 группы: параметрически – ориентированные и модельно – ориентированные.

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

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

8. Процедуры, осуществляемые с помощью пакетов прикладных программ в типовых проектных решениях.

9. Инструменты быстрой разработки приложений. Преимущество применения RAD-технологий.

RAD (от англ. rapid application development — быстрая разработка приложений) — концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. С конца XX века RAD получила широкое распространение и одобрение. Концепцию RAD также часто связывают с концепцией визуального программирования.

Основные принципы RAD

Инструментарий должен быть нацелен на минимизацию времени разработки.

Создание прототипа для уточнения требований заказчика.

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

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

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

Управление проектом должно минимизировать длительность цикла разработки.

Среды разработки, использующие принципы RAD

Borland Delphi

Borland C++ Builder

Microsoft Visual Studio

Macromedia Flash

Macromedia Authorware

Macromedia Director

Omnis Studio

Visual DataFlex

IntraWeb

Быстрая разработка приложений

Rapid Application Development (RAD) – это жизненный цикл процесса проектирования, созданный для достижения более высоких скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.

Что обеспечивает RAD технология

Технология RAD обеспечивает:

быстроту продвижения программного продукта на рынок;

интерфейс, устраивающий пользователя;

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

простоту развития функциональности системы.

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

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

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

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

Отличие архитектуры "клиент-сервер" от архитектуры "файл-сервер"

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

Сетевое многопользовательское приложение строится по принципу файл-серверной архитектуры. Данные в виде одного или нескольких файлов размещаются на файловом сервере. Файловый сервер принимает запросы, поступающие по сети от компьютеров-клиентов, и передает им требуемые данные. Однако обработка этих данных выполняется на компьютерах-клиентах. На каждом из компьютеров запускается полная копия процессора обработки данных Jet Engine. Любая копия Jet независимо управляет файлами MDB, содержащими данные. Единственная связь между этими независимыми действиями – файл блокировок (файл, который имеет имя, совпадающее с именем файла приложения, но с расширением .Idb), который обязательно создается для каждого файла базы данных с расширением .mdb. При этом каждая копия Jet выполняет изменения индексов, работу с системными таблицами и другие функции, входящие в компетенцию СУБД.

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

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

Архитектура "клиент-сервер" позволяет устранить все указанные недостатки. Кроме того, она позволяет оптимальным образом распределить вычислительную нагрузку между клиентом и сервером, что также влияет на многие характеристики системы: стоимость, производительность, поддержку.

11. Методы организации проведения обследования предметной области ИС и сбора материалов.

5) В зависимости от категории участников предпроектного обследования:

              5.1) Методы сбора информации, выполняемого проектировщиком АИС.

              5.2) Методы сбора информации, выполняемого специалистами предметной области.

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

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]