ЛЕКЦИЯ № 4 Программная эксплуатация АТС Э

⇐ ПредыдущаяСтр 7 из 8Следующая ⇒

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

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

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

Второй уровень управления обычно реализуют процессоры управления коммутацией с распределенными функциями, взаимодействующие друг с другом через коммутационное поле или через общую шину. Для межпроцессорных связей используют разнообразные протоколы, причем в большинстве цифровых АТС применяются модификации стандартных протоколов 0КС7 или Х.25. Основные процессоры управления коммутационным полем для надежности дублируются. На этом уровне анализируются набранные абонентом цифры и выбирается путь через коммутационное поле. После того как соединение установлено, второй уровень управления поддерживает его и разрушает, как только обслуживание вызова переходит в фазу разъединения.

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

Управляющие устройства

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

Технологические аспекты разработки программного обеспечения АТС

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

• разработка,

• тестирование,

• внедрение,

• сопровождение,

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

Преимущества каскадной модели

Нетрудно заметить, что каскадная модель имеет множество преимуществ, если ее использовать в проекте, для которого она достаточно приемлема. Ниже перечислены эти преимущества:

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

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

· она весьма доступна для понимания

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

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

· она отличается стабильностью требований;

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

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

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

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

Недостатки каскадной модели

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

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

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

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

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

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

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

· модель основана на документации, а значит, количество документов может быть избыточным;

· весь программный продукт разрабатывается за один раз. Нет возможности разбить систему на части.

⇐ Предыдущая 1 2 3 4 5 678 Следующая ⇒