Классы автоматизированных ИС — КиберПедия 

Автоматическое растормаживание колес: Тормозные устройства колес предназначены для уменьше­ния длины пробега и улучшения маневрирования ВС при...

Двойное оплодотворение у цветковых растений: Оплодотворение - это процесс слияния мужской и женской половых клеток с образованием зиготы...

Классы автоматизированных ИС

2017-05-20 354
Классы автоматизированных ИС 0.00 из 5.00 0 оценок
Заказать работу

ВВЕДЕНИЕ

. Одной из наиболее важных проблем отечественных товаропроизводителей является повышение их конкурентоспособности. Управление конкурентной позицией предприятия возможно, главным образом, за счёт изменения подходов к организации производства и управления. По нашему мнению основой таких подходов является внедрение интегрированных информационных систем на базе вычислительных комплексов для управления предприятием. Подобные системы являются программной реализацией методологий, базирующихся на популярных во всём мире стандартах управления. Причем под стандартом управления нами понимается стандарт функционального рассмотрения процессов (производства, логистики, финансов, маркетинга) и их результатов во взаимосвязи. Эти стандарты дают возможность упорядочить и синхронизировать процессы в реальном времени. Современные информационные системы позволяют слаженно управлять всеми ресурсами предприятия. Тем самым оптимизируются производственные процессы и минимизируются затраты и потери. Современные мировые стандарты управления на базе вычислительных комплексов и экономико-математических методов позволяют интегрировать потребности «покупателя» в процессы планирования и производства. Такие подходы помогают более оперативно находить возможности для создания конкурентных преимуществ и выводят управление предприятием на качественно новый уровень. Необходимость внедрения информационных систем на основе современных стандартов управления очевидна.. Те же предприятия, которые внедряют у себя автоматизированные системы управления, и таких становится всё больше и больше, доказывают своей успешной экономической деятельностью необходимость развивать информационные технологии на остальных предприятиях. В то же время, существуют примеры неудачных внедрений информационных систем управления, когда предприятиями были затрачены значительные средства и силы, а ожидаемого эффекта не последовало. Многообразие информационных технологий, отраслевые, а также неудачные внедрения автоматизированных систем управления на некоторых предприятиях, указывают на необходимость научного подхода к этим вопросам. Состояние изученности проблемы. Основоположниками методологии управления ресурсами предприятия при помощи вычислительных машин можно назвать американских учёных Орлицки (Orlicky) и Оливера Уайта (Oliver Wight). Их работы продолжили Робин Гудфеллоу (Robin Goodfellow), Норман Гайвер (Norman Gaither), Джимми Браун (Jimmie Browne), Ричард Пинкертон (Richard Pinkerton), Томас Вольманн (Thomas Vollmann), Уильям Берри (William Berry), Клай Уайбарк (D. Clay Whybark), Деррил Ландватер (Darryl Landvater), Кристофер Грэй (Christopher Gray). Труды этих учёных сформировали общую концептуальную основу информационных систем управления предприятиями. Первые работы по теории оптимизации распределения ресурсов методами линейного программирования были написаны ещё в 1939 году профессором Ленинградского университета Л.В. Канторовичем. Начиная с 1970-х годов большой вклад в развитие автоматизированных систем управления внесли советские учёные В.В. Новожилов, С.А. Соколицин, С.Н. Абдуллина, СИ. Сухоруков, С.Г. Пуртов. Их труды позволили успешно использовать автоматизацию для управления предприятиями при плановой экономике. С переходом к рыночным отношениям в 90-х годах прошлого века стало очевидно, что прежние информационные системы созданные для плановой экономики не годны, в то же время информационные технологии во всём мире ушли далеко вперед. Поэтому работы российских ученых направлены в основном на использование в информационных системах зарубежных стандартов управления. Наибольший интерес по нашему мнению представляют 5 труды таких ученых, как Г.А. Титоренко, Д.А. Гаврилов, Г.Н. Калянов, В.А. Лапидус, Ю.П. Попов, В. Краснова, А. Привалов, СБ. Кутыркин, С.А. Волчков, И.В. Балахонова, С. Питеркин, С.Н. Колесников, И.И. Бажин. Всестороннее изучение трудов зарубежных и отечественных ученых показало, что практически все они сосредоточены на проблемах внедрения и эксплуатации информационных систем управления.

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


ОСНОВНЫЕ ПОНЯТИЯ И ОПРЕДЕЛЕНИЯ АИС

В научно-технической литературе часто используются термины «система», «система управления», «автоматизированная система управления», «автоматизированные информационные системы».

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

Понятие «система» имеет широкую область применения.

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

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

Для системы характерны следующие основные свойства:

· сложность;

· делимость;

· целостность;

· многообразие элементов и различие их природы;

· структурированность.

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

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

Целостность системы означает, что функционирование множества элементов системы подчинено единой цели.

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

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

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

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

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

Таким образом, любой системе управления экономическим объектом соответствует своя информационная система, называемая экономической информационной системой.

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

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

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

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

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

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

Автоматизированные информационные системы разнообразны и могут быть классифицированы по ряду признаков (рис. 1.1).

Модели ИС. Виды моделей

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

каскадная модель (70-85 г.г.);

спиральная модель (86-90 г.г.).

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

Положительные стороны применения каскадного подхода заключаются в следующем [2]:

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

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

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

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

Рисунок 1.2.2. Реальный процесс создания ИС на базе каскадной модели

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

 

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

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

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

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

 


Пример использования структурного подхода

Описание предметной области

В данном примере используется методология Yourdon [12], реализованная в CASE-средстве Vantage Team Builder [14].

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

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

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

Организация проекта

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

На фазе анализа строится модель среды (Environmental Model). Построение модели среды включает:

· анализ поведения системы (определение назначения ИС, построение начальной контекстной диаграммы потоков данных (DFD) и формирование матрицы списка событий (ELM), построение контекстных диаграмм);

· анализ данных (определение состава потоков данных и построение диаграмм структур данных (DSD), конструирование глобальной модели данных в виде ER-диаграммы).

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

Например, в данном случае назначение ИС формулируется следующим образом: ведение базы данных о членах библиотеки, фильмах, аренде и поставщиках. При этом руководство библиотеки должно иметь возможность получать различные виды отчетов для выполнения своих задач.

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

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

Начальная контекстная диаграмма изображена на рисунке 2.42. В отличие от нотации Gane/Sarson внешние сущности обозначаются обычными прямоугольниками, а процессы - окружностями.

. Начальная контекстная диаграмма

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

Аббревиатура Тип
NC Нормальное управление
ND Нормальные данные
NCD Нормальное управление/данные
TC Временное управление
TD Временные данные
TCD Временное управление/данные

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

Матрица списка событий имеет следующий вид:

Описание Тип Реакция
  Клиент желает стать членом библиотеки ND Регистрация клиента в качестве члена библиотеки
  Клиент сообщает об изменении адреса ND Регистрация измененного адреса клиента
  Клиент запрашивает аренду фильма ND Рассмотрение запроса
  Клиент возвращает фильм ND Регистрация возврата
  Руководство предоставляет полномочия новому поставщику ND Регистрация поставщика
  Поставщик сообщает об изменении адреса ND Регистрация измененного адреса поставщика
  Поставщик направляет фильм в библиотеку ND Получение нового фильма
  Руководство запрашивает новый отчет ND Формирование требуемого отчета для руководства

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

Потоки на диаграмме верхнего уровня Потоки на диаграмме нулевого уровня
Информация от клиента Данные о клиенте, Запрос об аренде
Информация для клиента Членская карточка, Ответ на запрос об аренде
Информация от руководства Запрос отчета о новых членах, Новый поставщик, Запрос отчета о поставщиках, Запрос отчета об аренде, Запрос отчета о фильмах
Информация для руководства Отчет о новых членах, Отчет о поставщиках, Отчет об аренде, Отчет о фильмах
Информация от поставщика Данные о поставщике, Новые фильмы

На приведенной DFD (рисунок 2.43) накопитель данных "библиотека" является глобальным или абстрактным представлением хранилища данных.

Анализ функционального аспекта поведения системы дает представление об обмене и преобразовании данных в системе. Взаимосвязь между "абстрактными" потоками данных и "конкретными" потоками данных на диаграмме нулевого уровня выражается в диаграммах структур данных (рисунок 2.44).

На фазе анализа строится глобальная модель данных, представляемая в виде диаграммы "сущность-связь" (рисунок 2.45).

Между различными типами диаграмм существуют следующие взаимосвязи:

· ELM-DFD: события - входные потоки, реакции - выходные потоки

· DFD-DSD: потоки данных - структуры данных верхнего уровня

· DFD-ERD: накопители данных - ER-диаграммы

· DSD-ERD: структуры данных нижнего уровня - атрибуты сущностей

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

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

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

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

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

Рис. 2.43. Контекстная диаграмма

Диаграмма структур данных

Результатами проектирования архитектуры являются:

· модель процессов (диаграммы архитектуры системы (SAD) и миниспецификации на структурированном языке);

· модель данных (ERD и подсхемы ERD);

· модель пользовательского интерфейса (классификация процессов на интерактивные и неинтерактивные функции, диаграмма последовательности форм (FSD - Form Sequence Diagram), показывающая, какие формы появляются в приложении и в каком порядке. На FSD фиксируется набор и структура вызовов экранных форм. Диаграммы FSD образуют иерархию, на вершине которой находится главная форма приложения, реализующего подсистему. На втором уровне находятся формы, реализующие процессы нижнего уровня функциональной структуры, зафиксированной на диаграммах SAD.

Рис. 2.45. Диаграмма "сущность-связь"

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

· уточнение модели базы данных для последующей генерации SQL-предложений;

· уточнение структуры пользовательского интерфейса;

· построение структурных схем, отражающих логику работы пользовательского интерфейса и модель бизнес-логики (Structure Charts Diagram - SCD) и привязка их к формам.

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

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

· модель данных (определение в ERD всех необходимых параметров для приложений);

· модель пользовательского интерфейса (диаграмма последовательности форм (FSD), показывающая, какие формы появляются в приложении и в каком порядке, взаимосвязь между каждой формой и определенной структурной схемой, взаимосвязь между каждой формой и одной или более сущностями в ERD).

На фазе реализации строится реализационная модель. Процесс ее построения включает в себя:

· генерацию SQL-предложений, определяющих структуру целевой БД (таблицы, индексы, ограничения целостности);

· уточнение структурных схем (SCD) и диаграмм последовательности форм (FSD) с последующей генерацией кода приложений.

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


Методология DATARUN

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

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

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

Методология DATARUN

Одной из наиболее распространенных в мире электронных методологий является методология DATARUN [6,26]. В соответствии с методологией DATARUN ЖЦ ПО разбивается на стадии, которые связываются с результатами выполнения основных процессов, определяемых стандартом ISO 12207. Каждую стадию кроме ее результатов должен завершать план работ на следующую стадию.

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

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

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

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

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

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

Методология DATARUN опирается на две модели или на два представления:

· модель организации;

· модель ИС.

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

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

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


Поделиться с друзьями:

Архитектура электронного правительства: Единая архитектура – это методологический подход при создании системы управления государства, который строится...

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

Организация стока поверхностных вод: Наибольшее количество влаги на земном шаре испаряется с поверхности морей и океанов (88‰)...

Индивидуальные и групповые автопоилки: для животных. Схемы и конструкции...



© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!

0.081 с.