Автор работы: Пользователь скрыл имя, 03 Ноября 2012 в 11:23, шпаргалка
Работа содержит ответы на 40 вопросов по дисциплине "Менеджмент".
невозможна по целому ряду причин, например, психологических:
хотя и возможно полностью автоматизировать
процесс предоставления ссуды, люди не могут примириться
с тем, что их прошения беспристрастно отклонены
машиной.
Безусловно, ручные системы имеют массу недостатков: например,
люди устают, болеют, увольняются, требуют повышения заработной
платы. Однако наиболее важно то, что размер и сложность
ручной системы будут возрастать с увеличением числа запросов,
поскольку человек может обрабатывать лишь небольшое
количество данных.
После определения границ ручной реализации необходимо
решить, какая часть системы будет пакетной, а какая диалоговой.
Для большинства современных приложений вся автоматизированная
система должна быть диалоговой, если только не
доказано противное. Соответствующее заключение может быть
сделано на основе собранных статистических данных, например
скорости поступления запросов и частоты изменения данных. В
качестве примеров причин для пакетной реализации можно привести
следующие:
• некоторые запросы требуют длительной работы со срезом базы
данных за определенный период (годовой отчет, пересылка
накопленной информации и т.п.);
• некоторые отклики (например, отчеты о продажах) содержат
большое количество статичных данных, актуальность которых
не изменяется в течение дней или даже недель.
Следующий шаг — выделение частей, реализуемых как подсистемы
реального времени. Существует два принципиальных отличия
системы реального времени от просто диалоговой системы.
Первое из них связано с концептуальным уровнем: в системе
реального времени время поступления события в систему само
по себе несет определенную информацию, которая не может быть
закодирована. Второе связано с уровнем реализации: время от
клика системы реального времени является критичным и сопоставимым
со скоростью выполнения технологических операций.
В целом рекомендуется реализовать как подсистемы реального
времени те части системы, из которых должен быть исключен
человек, т.е. те части, где приоритетны следующие факторы:
скорость (например, противоракетная оборона), опасность (например,
контроль радиоактивности), утомляемость (работа авиадиспетчера).
2) Выбор подходящих
технических средств.
проект и определив границы реализации, можно начинать
выбор аппаратной платформы, на которой будет функционировать
система (или по крайней мере сужать область для
такого выбора).
3) Анализ и выбор
существующей системы. Зная
и потенциальную аппаратную платформу, можно приступать
к поиску коммерческих пакетов, удовлетворяющих требованиям,
выявленным и зафиксированным на этапе системного проектирования,
и которые могут справиться с размерами и мощностью,
определяемыми собранной статистикой. Следует отметить, что к
такому выбору необходимо подходить сверхосторожно: стоимость
интегрированной системы (включая ее внедрение на предприятии),
в комплексе решающей стоящие перед предприятием задачи,
может составлять сотни тысяч и миллионы долларов, а ключевые
слова, характеризующие различные системы, практически
одни и те же:
• единая информационная среда предприятия;
• режим реального времени;
• независимость от законодательства;
• интеграция с другими приложениями (в том числе с уже работающими
на предприятии системами);
• поэтапное внедрение и т.п.
И здесь неоценимую помощь оказывает системный проект,
позволяющий выбрать систему, наиболее полно подходящую
конкретному предприятию, либо отвергнуть данный путь и приступить
к разработке и реализации собственной системы.
Ниже перечислены некоторые из критериев выбора готовой
системы:
• поддержка большинства функций, выявленных при анализе
требований;
• поддержка концептуальной модели данных;
• наличие высокоуровневых механизмов разработки для компенсации
отсутствующих данных и функций;
• функционирование на различных аппаратных платформах;
• достаточные размеры внутренних таблиц;
• локализация.
Помимо чисто технических критериев выбора, важную роль
играют также деловые критерии, например опыт внедрения и надежность
продавца.
4) Разработка собственной
системы. Отметим недостатки
подхода по сравнению с покупкой готовой системы:
• трудозатраты на создание
собственной интегрированной
огромны и составляют сотни и тысячи человеко-лет,
стоимость разработки соизмерима со стоимостью готовой
системы (а часто значительно превышает ее): такие продукты
должны реализовываться большими коллективами программистов;
• использование готовой системы менее рискованно, чем разработка
собственной;
• готовая система внедряется поэтапно и поэтому частично может
быть доступна в рабочем режиме гораздо быстрее, чем
собственная.
Техническое проектирование. На данном этапе на основе системного
проекта и принятых решений по автоматизации осуществляется
проектирование системы. Фактически здесь дается ответ
на вопрос: «Как (каким образом) мы будем строить систему,
чтобы она удовлетворяла предъявленным к ней требованиям?».
Этот этап разделяется на два подэтапа:
• проектирование архитектуры системы, включающее разработку
структуры и интерфейсов ее компонент (автоматизированных
рабочих мест), согласование функций и технических
требований к компонентам, определение информационных
потоков между основными компонентами, связей
между ними и внешними объектами;
• детальное проектирование, включающее разработку спецификаций
каждой компоненты, разработку требований к тестам
и плана интеграции компонент, а также построение моделей
иерархии программных модулей и межмодульных взаимодействий
и проектирование внутренней структуры модулей.
При этом происходит расширение системного проекта:
• за счет его уточнения;
• за счет построения моделей автоматизированных рабочих
мест, включающих подсхемы информационной модели и
функциональные модели, ориентированные на эти подсхемы
вплоть до идентификации конкретных сущностей информационной
модели;
• за счет построения моделей межмодульных и внутримодуль
ных взаимодействий с использованием техники структурных
карт. Центральное место среди перечисленных видов
работ занимает построение моделей автоматизированных
рабочих мест.
17. Инструментальные средства проектирования и разработки информационных систем
В современных информационных технологиях важное место
отводится инструментальным средствам и средам разработки АИС,
в частности системам разработки и сопровождения их программного
обеспечения. Эти технологии и среды образуют системы,
называемые CASE-системами [36].
Используется двоякое толкование аббревиатуры CASE, соответствующее
двум направлениям использования CASE-систем.
Первое из них — Computer Aided Software Engineering — переводится
как автоматизированное проектирование программного обеспечения,
соответствующие CASE-системы часто называют инструментальными
средами разработки ПО (RAD — Rapid ApplicationDevelopment). Второе — Computer Aided System Engineering — подчеркивает
направленность на поддержку концептуального проектирования
сложных систем, преимущественно слабоструктурированных.
Такие CASE-системы часто называют системами BPR
(Business Process Reengineering).
Обзор технологий и рынка CASE-средств, наиболее распространенных
в странах СНГ, приведен в приложении 2.
Среди систем RAD различают интегрированные комплексы
инструментальных средств для автоматизации всех этапов жизненного
цикла ПО (такие системы называют Workbench) и специализированные
инструментальные средства для выполнения отдельных
функций (Tools). Средства CASE по своему функциональному
назначению принадлежат к одной из следующих групп:
1) средства программирования;
2) средства управления программным проектом;
3) средства верификации (анализа) программ;
4) средства документирования.
Проектирование ПО с помощью CASE-систем. Оно включает несколько
этапов. Начальный этап — предварительное изучение проблемы.
Результат представляется в виде исходной диаграммы потоков
данных и согласуется с заказчиком. На следующем этапе выполняется
детализация ограничений и функций программной системы, и по
лученная логическая
модель вновь согласуется с
разрабатывается физическая модель, т.е. определяется модульная
структура программы, выполняется инфологическое проектирование
базы данных, детализируются граф-схемы программной системы
и ее модулей, проектируется пользовательский интерфейс.
Примерами широко известных инструментальных сред RAD
служат VB (Visual Basic), Delphi, PowerBuilder соответственно фирм
Microsoft, Borland, PowerSoft. Применение инструментальных сред
существенно сокращает объем ручной работы программистов (особенно
при разработке интерфейсных частей программ)..
В средах быстрой разработки приложений обычно реализуется
способ программирования, называемый управлением событиями. При
этом достигается
сокращается объем ручного кодирования, особенно при
разработке интефейсных частей программ. В этих средах пользователь
может работать одновременно с несколькими экранами (окнами).
Типичными являются окна из следующего списка.
I. Окно меню с пунктами
«file», «edit», «window» и т.
функции, очевидные из названия пунктов.
П. Окно формы, на котором, собственно, и создается прототип
экрана будущей прикладной программы.
III. Палитра инструментов — набор изображений объектов пользовательского
интерфейса, из них можно компоновать окно формы.
IV. Окно свойств и событий, с помощью которого ставятся в
соответствие друг другу объекты окна формы, события и
обработчики событий. Событием в прикладной программе
является нажатие клавиши или установка курсора мыши в
объект формы. Каждому событию должна соответствовать
событийная процедура (обработчик события), проверяющая
код клавиши и вызывающая нужную реакцию.
V Окно редактора кода,
на котором пользователь
создаваемую вручную часть кода.
VI. Окно проекта — список модулей и форм в создаваемой программе.
Для написания событийных процедур в Visual Basic используется
язык и текстовый редактор языка Basic, в Delphi — язык и
редактор языка Object Pascal. В CASE-системе фирмы IBM. включающей
части VisualAge (для клиентских приложений) и VisualGen
(для серверных приложений), базовым языком выбран SmallTalk.
В среде разработки приложений «клиент-сервер» SQLWindows
оригинальные фрагменты программ пишутся на специальном языке
SAL. Нужно заметить, что для реализации вычислительных процедур,
в частности для написания мини-спецификаций, используется
обычная для 3GL технология программирования.
Обычно после написания ПП на базовом языке компилятор системы
переводит программу на промежуточный р-код. Вместе с интерпретатором
р-кода эта программа рассматривается, как ЕХЕ-файл.
В некоторых развитых
средах компилируется обычный ЕХЕ-
не требующий интерпретации для своего исполнения.
Помимо упрощения написания пользовательского интерфейса,
в средах RAD предусматриваются средства для реализации и
ряда других функций. Так, в наиболее развитой версии Visual Basic
к ним относятся средства выполнения следующих функций:
• поддержка ODBC, что дает возможность работы с различными
СУБД;
• разработка баз данных;
• разработка трехзвенных систем распределенных вычислений;
• интерактивная отладка процедур на SQL Server;
• управление версиями при групповой разработке ПО;
• моделирование и анализ сценариев распределенных вычислений.
Создание сред RAD для сетевого программирования требует решения
ряда дополнительных
проблем, обусловливаемых
обилием применяемых форматов данных и
т.п. Решение этих проблем, а также устранение некоторых особенностей
языка C++, усложняющих программирование, достигнуто
в языке программирования Java. Для этого языка разработана
своя инструментальная среда JDK (Java Developer's Kit). В ней
имеются библиотека классов и инструментальные средства, такие,
как компилятор байт-кодов, интерпретатор, просмотрщик аплетов,
отладчик, формирователь оконных форм и т.п. Значительное
внимание уделяется разработке инструментальных сред для создания
Web-узлов, примером такой среды может служить HAHTSite
фирмы HAHTSoftware. Для разработки Java-программ из готовых
компонентов служит среда IBM Visial Age for Java, в которой имеются
(как и в среде VB) учебная, профессиональная и общецелевая
(Enterprise) версии.
Спецификации моделей информационных систем. Важное значение
в процессе разработки информационных систем имеют средства
спецификации их проектов. Средства спецификации в значительной
мере определяют суть методов CASE.
Существует ряд способов представления моделей [36]. Практически