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

·  существует множество международных и национальных стандартов, которые не полностью и неравномерно удовлетворяют потребности в стандартизации объектов и процессов создания и применения сложных информационных систем;

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

·  функциональными стандартами поддержаны и регламентированы только самые простые объекты и рутинные, массовые процессы: телекоммуникации, программирование, документирование программ и данных. Наиболее сложные и творческие процессы создания и развития крупных распределенных информационных систем — системный анализ и проектирование, интеграция компонентов и систем, испытания и сертификация — почти не поддержаны требованиями и рекомендациями стандартов из-за трудности их формализа­ции и унификации;

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

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

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

Между приложениями и средой определяются стандартизованные интерфейсы — Application Program Interface (API), которые являются необходимой частью профилей любой открытой системы. Кроме того, в профилях могут быть определены унифицированные интерфейсы взаимодействия функциональных частей друг с другом и интерфейсы взаимодействия между компонентами среды системы. Спецификации выполняемых функций и интерфейсов взаимодействия могут быть оформлены в виде профилей компонентов системы. Таким образом, профили информационной системы с иерархической структурой могут включать в себя:

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

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

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

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

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

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

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

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

·  опубликовать профиль и/или продвигать его по формальным инстанциям для дальнейшего распространения.

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

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

Структура профилей информационных систем

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

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

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

Лекция 14

Общая структура профиля информационной системы

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

·  определение целей использования данного профиля;

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

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

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

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

·  информационные ссылки на все исходные документы.

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

·  профиль прикладного программного обеспечения;

·  профиль среды информационной системы;

·  профиль защиты информации в информационной системе;

·  профиль инструментальных средств, встроенных в информационную систему.

Профиль прикладного программного обеспечения

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

Профиль среды информационной системы

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

Стандарты интерфейсов приложений со средой (API) должны быть определены по функциональным областям профилей информационной системы. Декомпозиция структуры среды функционирования системы на составные части, выполняемая на стадии эскизного проектирования, позволяет детализировать профиль среды информационной системы по функциональным областям эталонной модели OSE/RM:

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

·  область реляционных или объектно-ориентированных СУБД (например, стандарт языка SQL-92 и спецификации доступа к разным базам данных);

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

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

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

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

Профиль защиты информации

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

·  функции, реализуемые операционной системой;

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

·  функции управления данными, реализуемые СУБД;

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

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

·  функции администрирования средств безопасности.

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

Профиль инструментальных средств

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

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

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

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

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

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

·  настройкой пользовательских интерфейсов (генерацией экранных форм и отчетов);

·  ведением баз данных системы;

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

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

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

Лекция 15

Фазы жизненного цикла в рамках методологии RAD

При использовании методологии быстрой разработки приложений жизненный цикл информационной системы состоит из четырех фаз:

    фаза анализа и планирования требований; фаза проектирования; фаза построения; фаза внедрения.

Рассмотрим каждую из них более подробно.

Фаза анализа и планирования требований.

На данной фазе выполняются следующие работы:

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

примечание

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

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

Если реализация проекта принципиально возможна, то результатом фазы анализа и планирования требований будет список функций разрабатываемой информаци­онной системы с указанием их приоритетов и предварительные функциональные и информационные модели системы.

Фаза проектирования

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

примечание

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

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

примечание

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

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

При необходимости для каждого элементарного процесса создается частичный про­тотип: экран, диалог или отчет (это позволяет устранить неясности или неоднознач­ности). Затем определяются требования разграничения доступа к данным. После детального рассмотрения процессов определяется количество функциональ­ных элементов разрабатываемой системы. Это позволяет разделить информаци­онную систему на ряд подсистем, каждая из которых реализуется одной командой разработчиков за приемлемое для RAD-проектов время (порядка полутора меся­цев). С использованием CASE-средств проект распределяется между различными командами — делится функциональная модель.

На этой же фазе происходит определение набора необходимой документации. Результатами данной фазы являются;

·  общая информационная модель системы;

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

·  точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

·  построенные прототипы экранов, диалогов и отчетов.

примечание

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

Фаза построения

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

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

·  определяется необходимость распределения данных;

·  производится анализ использования данных;

·  производится физическое проектирование базы данных;

·  определяются требования к аппаратным ресурсам;

·  определяются способы увеличения производительности;

·  завершается разработка документации проекта.

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

Фаза внедрения

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

примечание

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

Ограничения методологии RAD

Несмотря на все свои достоинства, методология RAD тем не менее (как, впрочем, и любая другая методология) не может претендовать на универсальность. Ее при­менение наиболее эффективно при выполнении сравнительно небольших систем, разрабатываемых для вполне определенного предприятия.

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

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

Лекция 16

Стандарты и методики

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

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

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

·  стандарты на продукты и услуги;

·  стандарты на процессы и технологии;

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

Виды стандартов

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

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

·  по утверждающей организации. Здесь можно выделить официальные международные, официальные национальные или национальные ведомственные стандар­ты (например, ГОСТы, ANSI, IDEFO/i), стандарты международных консорциу­мов и комитетов по стандартизации (например, консорциума OMG), стандарты «де-факто» — официально никем не утвержденные, но фактически действующие (например, стандартом «де-факто» долгое время были язык взаимодействия с реляционными базами данных SQL и язык программирования С), фирменные стандарты (например, Microsoft ODBC);

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

примечание

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

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

·  методика Oracle CDM (Custom Development Method) no разработке прикладных информационных систем под заказ;

·  международный стандарт ISO/IEC 12207: на организацию жизненного цикла продуктов программного обеспечения;

·  отечественный комплекс стандартов ГОСТ 34.

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

Методика Oracle CDM

Одним из уже сложившихся направлений деятельности фирмы ORACLE стала разработка методологических основ и производство инструментальных средств для автоматизации процессов разработки сложных прикладных систем, ориентирован­ных на интенсивное использование баз данных. Методика Oracle CDM является развитием давно разработанной версии Oracle CASE-Method, применяемой в CASE-средстве Oracle CASE (в новых версиях - Designer/2000).

Основу CASE-технологии и инструментальной среды фирмы ORACLE составляют:

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

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

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

·  наличие централизованной базы данных, репозитария, для хранения спецификаций проекта прикладной системы на всех этапах ее разработки. Такой репозитарий представляет собой базу данных специальной структуры, работающую под управлением СУБД ORACLE;

·  возможность одновременной работы с репозитарием многих пользователей. Такой многопользовательский режим почти автоматически обеспечивается стандартными средствами СУБД ORACLE. Централизованное хранение проекта системы и управление одновременным доступом к нему всех участников разработки поддерживают согласованность действий разработчиков и не допускают ситуацию, когда каждый проектировщик или программист работает со своей версией проекта и модифицирует ее независимо от дру­гих;

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

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

Общая структура

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

·  стратегия (определение требований);

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

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

·  реализация (написание и тестирование приложений);

·  внедрение (установка новой прикладной системы, подготовка к началу эксплуа­тации);

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

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

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

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

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

примечание

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

Методика Oracle CDM выделяет следующие процессы, протекающие на протяже­нии жизненного цикла информационной системы;

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

·  исследование существующих систем;

·  определение технической архитектуры;

·  проектирование и построение базы данных;

·  проектирование и реализация модулей;

·  конвертирование данных;

·  документирование;

·  тестирование;

·  обучение;

·  переход к новой системе;

·  поддержка и сопровождение.

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

Особенности методики Oracle CDM

Отметим основные особенности методики Oracle CDM, определяющие область ее

применения и присущие ей ограничения.

    Степень адаптивности CDM ограничивается тремя моделями жизненного цикла:
      классическая — предусматривает все этапы; быстрая разработка — ориентированна на использование инструментов моделирования и программирования Oracle; облегчённый подход — рекомендуется в случае малых проектов и возможно­сти быстро прототипировать приложения.
    Методика не предусматривает включение дополнительных задач, которые не оговорены в CDM, и их привязку к остальным. Также исключено удаление за­дачи (и порождаемых ею документов), не предусмотренное пи одной из трех моделей жизненного цикла, и изменение последовательности выполнения за­дач по сравнению с предложенной. Все модели жизненного цикла являются по сути каскадными. Даже «облегчен­ный подход», несмотря на итерационность выполнения действий по прототипированию, сохраняет общий последовательный и детерминированный поря­док выполнения задач. Методика не является обязательной, но может считаться фирменным стандар­том. При формальном применений степень обязательности полностью соответ­ствует ограничениям возможностей адаптации. Прикладная система рассматривается в основном как программно-техничес­кая система — например, возможность выполнения организационно-структур­ных преобразований, практически всегда происходящих при переходе к новой информационной системе, в этой методике отсутствуют. CDM теснейшим образом опирается на использование инструментария Oracle, несмотря на утверждения о простом приспособлении CDM к проектам, в кото­рых используется другой комплект инструментальных средств. Методика Oracle CDM представляет собой вполне конкретный материал, дета­лизированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах информационных систем с опорой на инст­рументальные средства и СУБД фирмы Oracle.

Международный стандарт ISO/IEC 12207:

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6