Методы доступа к передающей среде

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

Метод доступа к передающей среде — метод, обеспечивающий выпол- нение совокупности правил, по которым узлы сети получают доступ кресурсу.

Существуют два основных класса методов доступа: детерминированные, недетерми- нированные.

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

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

Метод передачи права применяется в сетях с кольцевой топологией. Он основан на передаче по сети специального сообщения — маркера.

Маркер — служебное сообщение определенного формата, в которое або- ненты сети могут помещать свои информационные пакеты.

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

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

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

Наиболее распространенным недетерминированным методом доступа является мно- жественный метод доступа с контролем несущей частоты и обнаружением коллизий (CSMA/CD). В сущности, это описанный ранее режим соперничества. Контроль несущей частоты заключается в том, что узел, желающий передать сообщение, "прослушивает" пере- дающую среду, ожидая ее освобождения. Если среда свободна, узел начинает передачу.

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

232 ГЛАВА б КОМПЬЮТЕРНЫЕ СЕТИ

Назначение ЛВС

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

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

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

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

ОБЪЕДИНЕНИЕ ЛВС

Причины объединения ЛВС

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

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

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

Способы объединения ЛВС

Мост. Самый простой вариант объединения ЛВС — объединение одинаковых сетей в пре- делах ограниченного пространства. Физическая передающая среда накладывает ограниче- ния на длину сетевого кабеля. В пределах допустимой длины строится отрезок сети — сетевой сегмент. Для объединения сетевых сегментов используются мосты.

Мост — устройство, соединяющее две сети, использующие одинаковые ме- тоды передачи данных. __

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

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

6.3 ЛОКАЛЬНЫЕ ВЫЧИСЛИТЕЛЬНЫЕ СЕТИ_______________________________________________233

ных топологий, но работающие под управлением однотипных сетевых операционных систем.

Мосты могут быть локальными и удаленными.

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

Удаленныемосты соединяют сети, разнесенные территориально, с использовани- ем внешних каналов связи и модемов.

Локальные мосты, в свою очередь, разделяются на внутренние и внешние.

Внутренниемосты обычно располагаются на одной из ЭВМ данной сети и совме- щают функцию моста с функцией абонентской ЭВМ. Расширение функций осуществляется путем установки дополнительной сетевой платы.

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

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

Маршрутизатор,илироутер,— устройство, соединяющее сети разного типа, но использующее одну операционную систему.

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

Пример 6.7. Необходимо установить связь с абонентом телефонной сети, находящим- ся в другом городе. Сначала набирается адрес телефонной сети этого города — код города. Затем — адрес узла этой сети — телефонный номер абонента. Функции ма- ршрутизатора выполняет аппаратура АТС.

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

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

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

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

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

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

234 ГЛАВА 6. КОМПЬЮТЕРНЫЕ СЕТИ

Пример 6.8. Необходимо объединить локальные сети, находящиеся в разных городах. Эту задачу можно решить с помощью глобальной сети передачи данных. Такой сетью является сеть коммутации пакетов на базе протокола Х.25. С помощью шлюза локаль- ная вычислительная сеть подключается к сети Х.25. Шлюз выполняет необходимые преобразования протоколов и обеспечивает обмен данными между сетями.

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

Методы и средства организации и управления проектом информационных систем   Методы управления проектами. Организация работы над проектом.   Управление проектом- это руководство работами команды исполнителей проекта для реализации проекта с использованием методов управления, планирования и контроля работ, управление рисками, эффективной организацией работы и коммуникационными потоками в команде исполнителей. Основными составляющими любого проекта являются следующие: ресурсы (людские, финансовые и технические), время и стоимость выполнения проекта. Ответственность за координацию и реализацию этих трех составляющих несет менеджер проекта, а ответственность за идейную, функциональную сторону проекта несет главный программист. Методы управления программным проектом Метод критического пути СРМ - исследование возможности эффективного использования вычислительной машины при планировании и создании планов-графиков больших комплексов работ по модернизации заводов этой фирмы. В результате был создан рациональный и простой метод (Уолкера-Келли) управления проектом с использованием ЭВМ, который был назван CPM (Critical Path Method) - метод критического пути. Критический путь - наиболее полный путь работ в сетевом графике, которые лежат на этом пути. Именно продолжительность критического пути определяет наименьшую общую продолжительность работ в проекте в целом. Время выполнения всего проекта может быть сокращено за счет уменьшения времени выполнения задач, которые лежат на критическом пути. Соответственно любая задержка выполнения задач критического пути приводит к увеличению времени выполнения проекта. Эта концепция обеспечивает концентрацию внимания менеджера на критических работах. Однако основное преимущество метода критического пути - управление сроками выполнения задач, которые не лежат на критическом пути. Этот метод разрешает рассчитать возможные календарные графики выполнения комплекса работ на основе описанной логической структуры сети и оценок времени выполнения каждой работы [11.1-11.7]. Метод основан на графическом представлении задач (работ) и видов действий на проекте и задании ориентировочного времени их выполнения в виде графа (рис. 11.1), в вершинах которого располагаются работы и время выполнения каждой работы под вершинами либо на дугах графа. Метод анализа и оценки PERT.Метод PERT представляется сетевыми диаграммами с вершинами-событиями, а работа - в виде линии между двумя событиями, отображающими начало и конец работы. В целом расхождения между этими двумя методами сетевого представления графа работ - незначительные. Однако этот метод, в отличие от CMP, учитывает возникающие неопределенности во времени выполнения каждой операции. Представление более сложных связей между работами для задания узлов графа в виде вершина-событие является более сложным, и потому этот метод реже используется на практике.   3 Системы календарно-сетевого планирования.   В сетевых графиках реализованы функции связи между этапами, план-фактное рассогласование, подключение к этапам ресурсов различных типов, оптимизация использования ресурсов. Но самое главное отличительное преимущество КСП в UPE - возможность интеграции с данными бюджетной модели, с совмещенной временной шкалой (КСП и модели). КСП в UPE также импортируется (экспортируется) из всех распространенных приложений этого класса: например, изMS Project. Сотрудники вашей компании могут продолжать использовать ваши приложения КСП (например, MS Project). Сетевое планирование традиционно используется для разработки инвестиционных планов (бизнес-планов), в бюджетировании - для разработки инвестиционных бюджетов. Также сетевое планирование можно эффективно использовать для описания внутренних проектов компании и некоторых бизнес-процессов. В планировании работ по созданию новых сложных объектов возникает неопределенность, разрешение которой недоступно при традиционных методах планирования, например: установление продолжительности выполнения работ коллективами исполнителей, равномерное распределение ресурсов по видам работ, сокращение срока окончания всех работ при минимальном увеличении затрат и др. Организация планирования может быть существенно улучшена с помощью математических методов анализа и метода сетевого планирования и управления(СПУ). Сетевое планирование и управление программами включает три основных этапа: структурное планирование, календарное планирование и оперативное управление. Этап структурного планирования начинается с разбиения программы на четко определенные операции. Затем определяются оценки продолжительности операций и строится сетевая модель (сетевой график, стрелочная диаграмма), каждая дуга (стрелка) которой отображает работу. Вся сетевая модель в целом является графическим представлением взаимосвязей операций программы. Построение сетевой модели на этапе структурного планирования позволяет детально проанализировать все операции и внести улучшения в структуру программы еще до начала ее реализации. Однако еще более существенную роль играет использование сетевой модели для разработки календарного плана выполнения программы. Конечной целью этапа календарного планирования является построение календарного графика, определяющего моменты начала и окончания каждой операции, а также ее взаимосвязи с другими операциями программы. Кроме того, календарный график должен давать возможность выявлять критические операции (с точки зрения времени), которым необходимо уделять особое внимание, чтобы закончить программу в директивный срок. Что касается некритических операций, то календарный план должен позволять определять их резервы времени, которые можно выгодно использовать при задержке выполнения таких операций или с позиции эффективного использования ресурсов. Если проект оказывается удовлетворительным, то необходимо закончить его составление, в противном случае необходимо выполнить дальнейший анализ сетевой модели, который помог бы ее улучшить. Заключительным этапом является оперативное управление процессом реализации программы. Этот этап включает использование сетевой модели и календарного графика для составления отчетов о ходе выполнения программ. В случае необходимости сетевая модель корректируется. Сетевая модель отображает взаимосвязи между операциями и порядок их выполнения. Событие определяется как момент времени, когда завершаются одни операции и начинаются другие. Начальная и конечная точки любой операции описываются, таким образом, парой событий, которые называют обычно начальным и конечным событием. Каждая операция в сети представляется только одной дугой (стрелкой). Ни одна пара событий не должна определяться одинаковыми начальными и конечными событиями. Для сохранения порядка следования событий на сетевом графике вводятся фиктивные операции. Они отображаются пунктирной стрелкой и не требуют ни затрат времени, ни затрат ресурсов. Методологияпроектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом. Цель создания методологии построения информационных систем заключается в регламентации процесса проектирования ИС и обеспечении управления этим процессом с тем, чтобы гарантировать выполнение требований, как к самой ИС, так и к характеристикам процесса разработки. Основными задачами, решению которых должна способствовать методология проектирования ИС, являются следующие: § обеспечивать создание корпоративных ИС, отвечающих целям и задачам организации, а также предъявляемым требованиям по автоматизации деловых процессов заказчика; § гарантировать создание системы с заданным качеством в заданные сроки и в рамках установленного бюджета проекта; § поддерживать удобную дисциплину сопровождения, модификации и наращивания системы; § обеспечивать преемственность разработки, т.е. использование в разрабатываемой ИС существующей информационной инфраструктуры организации (задела в области информационных технологий). Внедрение методологии должно приводить к снижению сложности процесса создания ИС за счет полного и точного описания этого процесса, а также применения современных методов и технологий создания ИС на всем жизненном цикле ИС - от замысла до реализации. Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования. Модель жизненного цикла отражает различные состояния системы, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом ее полного выхода из употребления. В настоящее время известны и используются следующиемодели жизненного цикла: § Каскадная модель предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. § Поэтапная модель с промежуточным контролем предусматривает разработку ИС итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки. § Спиральная модель На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка. На практике наибольшее распространение получили две основные модели жизненного цикла: § каскадная модель (характерна для периода 1970-1985 гг.); § спиральная модель (характерна для периода после 1986.г.). В ранних проектах достаточно простых ИС каждое приложение представляло собой единый, функционально и информационно независимый блок. Для разработки такого типа приложений эффективным оказался каскадный способ. Каждый этап завершался после полного выполнения и документального оформления всех предусмотренных работ. Можно выделить следующие положительные стороны применения каскадного подхода: § на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; § выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Каскадный подход хорошо зарекомендовал себя при построении относительно простых ИС, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к системе. Основным недостатком этого подхода является то, что реальный процесс создания системы никогда полностью не укладывается в такую жесткую схему, постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ИС оказывается соответствующим поэтапной модели с промежуточным контролем. Однако и эта схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к системе. Согласование результатов разработки с пользователями производится только в точках, планируемых после завершения каждого этапа работ, а общие требования к ИС зафиксированы в виде технического задания на все время ее создания. Таким образом, пользователи зачастую получают систему, не удовлетворяющую их реальным потребностям. Спиральная модель ЖЦ была предложена для преодоления перечисленных проблем. На этапах анализа и проектирования реализуемость технических решений и степень удовлетворения потребностей заказчика проверяется путем создания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы. Это позволяет уточнить требования, цели и характеристики проекта, определить качество разработки, спланировать работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который удовлетворяет действительным требованиям заказчика и доводится до реализации. Итеративная разработка отражает объективно существующий спиральный цикл создания сложных систем. Она позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем и решить главную задачу - как можно быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований. Методология проектирования ИС охватывает три основные области: § проектирование объектов данных, которые будут реализованы в базе данных; § проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным; § учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п. Проектирование информационных систем всегда начинается с определения цели проекта. Цель проекта можно определить как решение ряда взаимосвязанных задач, включающих в себя следующие пункты: § реализация требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования; § реализация требуемой пропускной способности системы; § реализация требуемого времени реакции системы на запрос; § реализация безотказной работы системы; § реализация необходимого уровня безопасности; § реализация простоты эксплуатации и поддержки системы. Согласно современной методологии проектирования процесс создания ИС делится на следующие этапы (стадии): 1. Формирование требований к системе:Задача формирования требований к ИС является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. На єтой стадии осуществляется моделирование бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Для этого необходимо определить требования заказчиков к ИС и отобразить их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и задачам организации. На выходе этапа получаем модель организации, описанную в терминах бизнес-процессов и бизнес-функций. 2. Проектирование:На этапе проектирования формируются модели данных. Проектировщики в качестве исходной информации получают результаты анализа требований к ИС. Построение логической и физической моделей данных является основной частью проектирования базы данных. Полученная в процессе анализа информационная модель сначала преобразуется в логическую, а затем в физическую модель данных. Параллельно с проектированием схемы базы данных выполняется проектирование процессов, чтобы получить спецификации (описания) всех модулей ИС. При проектировании модулей определяют интерфейсы программ: разметку меню, вид окон, горячие клавиши и связанные с ними вызовы. Конечными продуктами этапа проектирования являются: · схема базы данных (на основании ER-модели, разработанной на этапе анализа); · набор спецификаций модулей системы (они строятся на базе моделей функций). · технический проект ИС (техническое задание), эскизный проект, рабочая документация. 3. Реализация:На этапе реализации осуществляется создание программного обеспечения системы, установка технических средств, разработка эксплуатационной документации. 4. Тестирование: обычно оказывается распределенным во времени. После завершения разработки отдельного модуля системы выполняют автономный тест, который преследует две основные цели: § обнаружение отказов модуля (жестких сбоев); § соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций). После того как автономный тест успешно пройдет, модуль включается в состав разработанной части системы и группа сгенерированных модулей проходит тесты связей, которые должны отследить их взаимное влияние. Далее группа модулей тестируется на надежность работы, то есть проходят, во-первых, тесты имитации отказов системы, а во-вторых, тесты наработки на отказ. Первая группа тестов показывает, насколько хорошо система восстанавливается после сбоев программного обеспечения, отказов аппаратного обеспечения. Вторая группа тестов определяет степень устойчивости системы при штатной работе и позволяет оценить время безотказной работы системы. В комплект тестов устойчивости должны входить тесты, имитирующие пиковую нагрузку на систему. Затем весь комплект модулей проходит системный тест - тест внутренней приемки продукта, показывающий уровень его качества. Сюда входят тесты функциональности и тесты надежности системы. Последний тест информационной системы - приемо-сдаточные испытания. Такой тест предусматривает показ информационной системы заказчику и должен содержать группу тестов, моделирующих реальные бизнес-процессы, чтобы показать соответствие реализации требованиям заказчика.   1.2. Модели жизненного цикла по Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы. К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ: · каскадная модель (70-85 г.г.); · спиральная модель (86-90 г.г.). В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Положительные стороны применения каскадного подхода заключаются в следующем: · на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; · выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты. Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако, в процессе использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС "заморожены" в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ, делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.   1.3.2. Методология rad Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента: · небольшую команду программистов (от 2 до 10 человек); · короткий, но тщательно проработанный производственный график (от 2 до 6 мес.); · повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком. Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств. Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользователей. Жизненный цикл ПО по методологии RAD состоит из четырех фаз: · фаза анализа и планирования требований; · фаза проектирования; · фаза построения; · фаза внедрения. На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Определение требований выполняется в основном силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т.п. Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС. На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть: · общая информационная модель системы; · функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков; · точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами; · построенные прототипы экранов, отчетов, диалогов. Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности. В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация. На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репозитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требова