Оценка эффективности методов предупреждения гидратообразования при испытании газоконденсатных скважин

Характеристика программ, используемых в разработке системы предупреждения гидратообразования в скважине: Rational Soda, Rational Clear Quest. Определение атрибутов системы и анализ интеграции модели. Разработка документации для технологического процесса.

Рубрика Производство и технологии
Вид курсовая работа
Язык русский
Дата добавления 12.02.2010
Размер файла 1,1 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

26

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Описание технологического процесса

2. Краткое описание программ, используемых в разработке

2.1 Rational Soda

2.2 Requisite Pro

2.3 Rational Clear Quest

3. Определение атрибутов системы (Requisite Pro). Интеграция модели. Создание типов и требований системы

4. Разработка документации для технологического процесса спроектированного в курсовой работе (Rational Soda)

5. Построение запросов к базе данных дефектов и обращений изменения (Rational Clear Quest)

Заключение

Список используемой литературы

1. Описание технологического процесса

Общая характеристика установки.

Назначение технологического процесса.

1.Оценка эффективности методов предупреждения гидратообразования при испытании газоконденсатных скважин

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

Прежде всего, необходимо установить, при каких условиях для данных залежей на глубинах 2300--3000 м наступает безгидратный режим работы вследствие прогрева ствола скважин восходящим потоком газа. В этом отношении характерно освоение скв. 58 Уренгойского месторождения и скв. 37 Заполярного месторождения.

В скв. 58 после замены глинистого раствора водой и снижения ее уровня в колонне получен газоконденсатный фонтан из интервалов 2885--2898 и 2915-- 2923 м. Отработка скважины велась по затрубному пространству через 2,5-дюймовые трубы в течение 13,5 часов и по НКТ через штуцер диаметром 22 мм -- 4,5 часа. Затем скважина исследована на продуктивность, результаты приведены на рис. 1. Из рисунка видно: освоение и исследование на всех этапах работы проводились в безгидратном режиме (кривая «давление--температура» на режимах проходит выше и правее равновесной гидратообразования).

Рис. 1. Результаты исследования скв. 58 Уренгойской площади кривые: 1 -- зависимость устьевой температуры от дебита; 2 -- равновесная гидратообразования; 3,4 -- зависимость устьевой температуры от давления газа;

В скв. 37 на глинистом растворе с удельным весом 1,2 г/см3 зарядами ПКС-105, с плотностью 7 отверстий на 1 погонный метр вскрытой мощности, перфорирован интервал 2878--2885 м. Приток после спуска НКТ на глубину 2882 м вызван сменой раствора на воду, понижением уровня воды в колонне путем свабирования с одновременной подкачкой воздуха в затрубное пространство компрессором низкого давления. После понижения уровня скважину остановили на приток при закрытом на устье затрубном пространстве. Через 14 часов при устьевом давлении 160 кгс/см2 произошел прорыв газа под башмак НКТ и скважина перешла на фонтанирование газоконденсатом. В отличие от скв. 58 здесь на всех режимах работы отмечалось гидратообразование на глубинах ниже 190--450 м. что подтверждалось спуском глубинных приборов. Для ликвидации гидратов и предупреждения их образования при остановке скважины в НКТ закачивали раствор хлористого кальция с удельным весом 1,2 г/см3. Результаты освоения и исследования представлены на рис.2.

В связи с тем, что по этой скважине не определен состав пластового флюида и равновесную гидратообразования непосредственно рассчитать невозможно, для ориентировочной оценки использованы данные по аналогичным объектам скв. 1 того же месторождения (интервал 2614--2618 и 2365--2374 м). Как видно из рисунка, термодинамические условия в стволе остановленной скважины благоприятствуют гидратообразованию в интервале 100--600 м, а на устье работающей -- на протяжении всего периода исследований.

Рис. 2. Результаты исследования скв.37 Заполярной кривые: 1 -- термодинамические условия по стволу остановленной скважины; 2,3 -- зависимости устьевой температуры от дебита и давления соответственно;4,5 -- равновесные гидратообразования для состава газа из скв.1 Заполярной площади.

На основе сопоставления рассмотренных примеров можно предположить: при дебитах свыше 150--200 тыс. нм3/сут. скважины будут работать в безгидратном режиме за счет прогрева ствола восходящим потоком газа. Это подтверждается опытом растепления газоконденсатной скв.1 Ямбургского месторождения. При дебитах же до 50--100 тыс. нм3/сут., как правило, отмечается гидратообразование различной интенсивности, для предупреждения которого в скв.10 Западно-Таркосалинской площади проверялась опытным путем эффективность инъекции антигидратного ингибитора в призабойную зону пласта перед вызовом притока. В этой скважине в отложениях усть-балыкской толщи готерив-барремского яруса вскрыт перфорацией интервал 2446--2455 м. По промыслово-геофизическим данным объект испытания характеризуется отрицательной амплитудой потенциала СП в 55 мВ, положительным приращением по микрозондам, сужением ствола скважины по каверномеру, кажущимися сопротивлениями, равными по импульсному каротажу 8-18, боковому--23--30 и микробоковому -- 25--32 Ом-м. При испытаниях из этого интервала получен фонтанирующий приток газоконденсата. Скважина исследована на продуктивность и газоконденсатность. Впоследствии планировалось также провести пробную эксплуатацию на режиме с дебитом газа 25,4 тыс. нм3/сут, что практически соответствовало бы производительности при свободном фонтанировании.

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

Для обоснования режима безгидратной эксплуатации произвели глушение скважины 2 % раствором хлористого кальция, а затем нагнетание в пласт 13.4 м3 раствора хлористого кальция 20%(масс.) концентрации. Как показало повторное освоение, скважина фонтанировала без заметного гидратообразования и на режиме с дебитом газа около 11 тыс. нм3/сут работала в течение 9 суток. За это время с профилактической целью в неподвижный газ через лубрикатор каждые 4 часа закачивали 20 л раствора хлористого кальция 30%-ной концентрации. В результате выяснилось: инъекция антигидратного ингибитора в призабойную зону способствовала осушке пласта и резко снижала гидратообразование в малодебитных газоконденсатных скважинах, поэтому данный способ рекомендуется как эффективное средство борьбы с гидратами.

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

(1)

где:Q -- расход газа для условий ствола скважины, cm3/c;

g--ускорение силы тяжести, 980 см/с2;

0 -- удельный вес газа в нормальных условиях, кг/см3;

Р -- среднее давление газа в скважине, кгс/см2;

Т -- средняя температура газа в скважине, °К;

Г -- геотермический градиент, °С/см;

Гa -- градиент температуры для астатического равновесия, °С/см;

Сp -- теплоемкость газа, ккал/кг-°С;

d -- диаметр внутреннего потока, см;

-- коэффициент теплоотдачи, ккал/см2;

Z -- коэффициент сжимаемости газа;

Р0=1,03 кгс/см2;

Т0=293°К.

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

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

При недостаточной мощности насосного парка единственно приемлемым способом глушения является способ поршневого вытеснения газа жидкостью из газоотводящего канала. Для этого необходимо поддерживать такие скорости движения газа у устья (здесь давление движущегося потока наименьшее), при которых жидкость не будет подхватываться газом и выноситься на поверхность. Как показала практика эксплуатации гравитационных сепараторов, таким требованиям отвечает скорость, вертикальная составляющая которой не превышает 0,15 м/с. Это очень низкий предел и выдерживать его из практических соображений не всегда выгодно. Видимо (исходя из промыслового опыта), вертикальную составляющую скорости к окончанию процесса можно доводить до 2 м/с, создавая соответствующее противодавление установкой на устье диафрагмы малого сечения. При такой скорости на контакте газ--жидкость будет отмечаться явление, подобное кипению, наиболее опасное с точки зрения гидратообразования из-за большой площади контакта жидкой и газообразной фаз. Поэтому в качестве профилактического мероприятия целесообразна закачка (в первых порциях) небольшого объема обычно применяемого антигидратного ингибитора. Для контроля за скоростью потока газа можно использовать известное соотношение

(2)

где:V -- скорость газа, см3/с;

Q -- расход газа, тыс. нм3/сут;

D1 -- эффективный диаметр сечения газоотводящего канала у устья скважины, см.

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

2. Краткое описание программ, используемых в разработке

2.1 Requisite Pro

RequisitePRO - продукт, расширяющий поддержку групповой разработки проекта. Позволяет команде разработчиков создавать, структурировать, устанавливать приоритеты, отслеживать, контролировать изменения требований, возникающих на любом этапе разработки компонентов приложения. Поддерживается репозиторий (БД) требований с динамическим связыванием с MS Word, что позволяет управлять требованиями на продукт, спецификациями программных компонент и планированием тестирования. Интеграция с Rational Rose позволяет отслеживать внесение изменений в визуальные модели на каждом этапе проектирования: прямого, обратного (reverse) и циклического (round-trip). Продукт предназначен для преодоления типичных системных проблем, возникающих перед командами разработчиков, перед группами поддержки качества и менеджерами разработки, вовлеченными в создание сложных приложений корпоративного уровня: перерасход бюджета, несоблюдение этапных сроков, проблемы качества продукта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RequisitePRO делает процесс записи требований и структурирования документации легче и полнее путем использования основных и дополнительных шаблонов, которые, в свою очередь, соответствуют стандартам IEEE, ISO, SEI CMM или Rational Objectory Process. Использование данных шаблонов гарантирует полноту окончательного результата путем организации работы с инструкциями, списками как созданными, так и стандартными форматами.

RequisitePRO является первым промышленным инструментом, интегрирующим управление требованиями с ведущими средствами разработки приложений: программами для составления расписания проекта, управления изменениями, моделирования и тестирования.

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

Посредством интеграции с Rational ClearCase, Microsoft SourceCafe и INTERSOLV PVCS, RequisitePRO поддерживает стандартные операции "check in/check out". За счет подобной интеграции достаточно просто сохранять требования вместе с остальными файлами, входящими в состав проекта.

RequisitePRO также позволяет вести управление планами тестирования. Можно экспортировать тестировочные требования в Rational SQA Suite, чтобы автоматизировать тестирование приложения. Связывая требования RequisitePRO с отдельными сценариями и процедурами SQA Suite, разработчики и тестеры могут быстро и эффективно производить основанное на требованиях тестирование.

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

2.2 Rational Soda

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

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

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

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

По задаваемым пользователем шаблонам SoDA "компилирует" документацию, собирая в один документ текстовые и графические данные из различных источников, например из моделей, созданных в Rational Rose. Далее пользователь может отредактировать полученный документ с помощью Microsoft Word или Adobe FrameMaker. Как и любая система отчетности, SoDA базируется на тех данных, которые получает из сторонних программ.

SoDA поддерживает всю линейку продуктов Rational Software, позволяя создавать сложные комбинированные отчеты на основе выходных данных программ состава Rational Suite. Плюс ко всему SoDA имеет доступ к данным из Microsoft Project.

Основные возможности системы:

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

· Сохранение при "перекомпиляции" текста и графики, введенных пользователем вручную в текстовом процессоре. Если пользователь, скажем, в Microsoft Word, добавил какие-нибудь комментарии или иллюстрации в сгенерированный с помощью SoDA документ, то при перестраивании данного документа SoDA его не испортит.

· Настройка шаблонов, по которым генерируется документация. С помощью удобного визуального редактора можно создавать шаблоны, соответствующие всевозможным внешним стандартам (таким как ISO 9000, IEEE, MIL-STD-498 и DOD-STD-2167A) или внутренним стандартам компании.

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

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

· Сбор информации из многочисленных и разнородных источников.

· Документирование всех этапов работы над проектом.

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

· Поддержка русифицированных шаблонов и отчетов.

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

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

Продукты, поддерживаемые генератором отчетов: Rational Rose, Requisite PRO, ClearCase.

2.3 Rational Clear Quest

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

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

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

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

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

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

Процесс управления запросами на изменение (CRM -- Change Request Management) представляет собой целый цикл работ по регистрации, отслеживанию, анализу запроса, принятию по нему решения, реализации, проверке и закрытию. Реализация CRM требует принятия ряда решений руководителями различных подразделений и обмена информацией между заинтересованными лицами о поставленных задачах и произведенных работах.

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

3. Определение атрибутов системы (Requisite Pro). Интеграция модели. Создание типов и требований системы

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

1. Требования по архитектуре отвечают за целостность проекта.

2. Требования к системе определяют аппаратную составляющую проекта.

3. Функциональные требования отвечают за работоспособность.

4. требования к документам определяют содержание технической документации проекта.

5. требования к интерфейсу определяют содержание панели управления объектом, выводимой пользователю.

6. требования на тестирование определяют условия тестирования.

7. Преценденты - основные требования к процессам, происходящим в рассмотренном проекте.

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

Таблица 1. Типы требований

Тип требований прецентенты необходимо для объединения прецендентов, экспортированных из модели Rose.

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

Преимущества дополнительного хранения этих прецендентов в виде требований Requisite Pro:

§ Возможность создания дополнительных метрик для претендентов;

§ Возможность сортировки и фильтрации прецендентов по названию или атрибутам;

§ Возможность связывания прецендентов с требованиями различных типов;

§ Сохранение истории изменений прецендентов;

§ Ведение дискуссий по отдельным прецендентам или по их группам.

В проекте данная модель выглядит в виде:

Рис.4 Модель прецендентов

Для ассоциации этих прецендентов создается тип документов «Общие документы». После этого каждое из этих требований связывается с проектом созданным в Requisite Pro. В результате все требования ассоциируются с проектом и относятся к типу «Преценденты». Данных требований 4:

1. Создать сетевой план.

2. Измерение показателей процесса.

3. Создание протокола работ.

4. Управление устройствами.

Для удобства все они переносятся в одну папку, где создается матрица атрибутов (рис.5)

Рис.5

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

Функциональные требования

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

Трассировочная матрица

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

4. Разработка документации для технологического процесса, спроектированного в курсовой работе (Rational Soda)

Данный компонент пакета Rational существенно упрощает оформление технической документации для проектов, реализованных в Rational Rose. Сформировать отчет по состоянию системы или его отдельного элемента можно 2 способами. Первый предполагает при помощи настройщика документации (Wizard) автоматически сформировать отчет при помощи шаблона. Пользователю только необходимо связать этот шаблон с файлом проекта и программа сгенерирует отчет. В дальнейшем возможно модифицировать отчет, добавляя, редактируя, удаляя его содержимое. Soda взаимодействует тесно с пакетом Microsoft Office и не составит труда при освоении.

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

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

В задании требуется спроектировать 5 типов документации по проекту, разработанному в Rational Rose и сгенерировать отчет о состоянии одного из элементов.

5. Построение запросов к базе данных дефектов и обращений на изменения (Clear Quest)

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

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

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

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

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

Рассмотрим простейший случай создания рабочей базы:

Далее необходима создать соединение, в котором укажем используемую базу данных, ее основу и интегрируемую БД.

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

Использование Clear Quest Designer необходимо чтобы установить учетные записи для входа в систему пользователей и определить их права их доступа; для looserov - пароль всех учетных записей и права доступа хранятся в папке установки программы в каталоге user.login. После этого, пользователю доступно основное окно программы, в котором отражено все содержимое сконструированной базы данных.

Рабочее окно Clear Quest

Заключение

Rational Rose - это программный пакет для визуального объектно - ориентированного моделирования систем на основе классов и их взаимодействия, или, другими словами, это визуальный редактор, позволяющий моделировать программные системы любой сложности на основе графических диаграмм языка UML (Unified Modeling Language).

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

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

Открытая архитектура Rational Rose позволяет включать в него поддержку языков программирования, которые не предусмотрены стандартной поставкой, например, языка Assembler, для чего достаточно написать лишь собственный модуль.

Главное отличие Rational Rose от других CASE-средств в том, что он полезен не только проектировщику систем, но и разработчику программного кода. Однако, Rational Rose не создает для вас готовый исходный код. Пакет сможет создать основу для системы, заготовки классов вместе с их взаимодействием, а наполнять методы содержанием должен программист.

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

Размещено на Allbest.ru


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.