otvety_118

11

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

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

^ Средства повышения надежности ИС

В настоящее время, можно выделить несколько основных направлений работ по повышению надежности ИС и микропроцессорных систем [1,35,52].

1.

В первую очередь надежность ИС достигается за счет использования в ней высоконадежных элементов. Это достигается применением в устройствах ИС интегральных схем с высокой степенью интеграции (интенсивность отказов в ИС 10-6÷10-8 1/ч), использованием оптических элементов, а также внедрением новых типов печатных плат, контактных соединений, новых технологий ИС и т.д.

2.

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

3.

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

4.

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

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

5.

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

6.

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

12

7. Локализация приложений

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

Для локализации в английском языке иногда применяют сокращение «L10n». Где буквы «L» и «n» — начало и окончание словаLocalization, а цифра 10 — количество букв между ними.

Что такое локализация[править | править исходный текст]

MikTeX — пример сложного ПО, локализованного не полностью.

Зелѐные — функции, которые начинают работать сразу после подключения языкового пакета:

1.Ввод и отображение русских букв.

2.Ключевое слово «Глава».

Оранжевые — функции, присутствующие в MikTeX, но требующие от пользователя дополнительных действий.

3. Наклонный знак «≤» — вводится командой\leqslant (вместо \le).

Красные — функции, не адаптированные под русскую типографику (а пакетов, исправляющих это, в стандартной поставке нет).

4.Курсивный знак интеграла.

5.Курсивная греческая буква.

Локализация — это не просто перевод интерфейса на другой язык, существует три уровня локализации[1]:

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

Корректная работа в локализованной операционной системе.

Вывод на экран символов языка.

Другие манипуляции с языком — ввод текста, алфавитная сортировка, строковые операции и т. д.

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

программы:

Издание документации на целевом языке.

13

2.Перевод текстов в интерфейсе программы на целевой язык.

В сложном ПО не все части стоит переводить — например, многие не согласны с переводом имѐн функций Excel на русский язык.

Корректное выравнивание и размещение элементов интерфейса с учѐтом того, что сообщения-строки в разных языках могут иметь существенно разные размеры (например, типичное сообщение на английском, будучи переведено на немецкий язык, как правило, становится длиннее на 30—50 %). Кроме того, существуют языки с написанием справа налево (арабский, иврит) и сверху вниз (японский);

Чрезвычайно важен перевод терминологии. Например, спорным является применяемый в Windows термин «обозреватель», обозначающий браузер.

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

3.Тонкая настройка под целевую страну.

Работа со словоформами. Примером будет пресловутое «Найдено 3 файлов».

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

Обеспечение интероперабельности локализированной программы с исходной. Например: мы ввели в документ формулу «x*2,5». Будет ли она работать, если открыть документ в английской версии?

Учѐт национального менталитета. Например: красный

цвет у русских ассоциируется не только с опасностью, но и с праздником. На территории бывшего СССР распространѐн клиент обмена сообщениями ICQ, но мало используются AOL Instant Messenger, MSN Messenger и т. д. В играх зачастую приходится менять юмор, а изредка — даже корректировать сюжет (например, в Syberia

2 турецкий иммигрант Sirkos превратился в еврея Цукермана).

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

почты

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

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

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

Таким образом, локализация — это сложная и всеобъемлющая операция, и уже при разработке ПО соображения будущей интернационализации должны учитываться самым

серьѐзным образом. Мы привыкли видеть программное обеспечение, русифицированное по первому-второму уровню; сложного ПО с исчерпывающей русификацией практически не существует. Примером глубокой локализации может служить операционная система Mac OS X компании Apple, где локализация нередко включает и национально-ориентированные пиктограммы.

14

Инструментарий для локализации[править | править исходный текст]

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

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

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

Языковые теги и коды[править | править исходный текст]

Языковые теги могут использоваться для обозначения региональных особенностей того или иного языка. Имеется основной субтег для идентификации языка (например, «en» для английского) и возможный дополнительный субтег для уточнения региона использования (например, «GB» — Great Britain, Великобритания). Между субтегами обычно ставится дефис,

вотдельных случаях — черта снизу. Примеры языковых тегов:

Английский язык: en-GB (Британский английский), en-US (Американский английский), en-AU (Австралийский английский).

Испанский язык: es-ES (Кастильский испанский, письменный и разговорный язык Испании), es-MX (Мексиканский испанский), es-AR (Аргентинский испанский), es-

CO (Колумбийский испанский).

Португальский язык: pt-PT (Европейский португальский, письменный и разговорный язык Португалии), pt-BR (Бразильский португальский).

Китайский язык: zh-CN (Материковый Китай, упрощѐнные иероглифы), zh-

TW (Тайвань, традиционные иероглифы), zh-HK (Гонконг, традиционные иероглифы).Русский язык: ru-RU (Русский, Россия), ru-UA (Русский, Украина), uk-

UA (Украинский, Украина)[2]

Языковые коды определяются стандартом ISO 639-2 в виде трехбуквенного термина для идентификации каждого языка, например «eng» для английского или «tvl» для языка Тувалу. В то же время, эти коды не могут использоваться в качестве тегов, если соответствующий язык имеет двухбуквенный код согласно стандарту ISO 639-1.

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

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

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

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

15

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

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

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

Но не все так плохо! Для упрощения процесса локализации были созданы специальные инструментальные средства, которые позволяют автоматизировать многие типичные задачи и значительно снизить затраты на локализацию. В данной статье будет рассмотрено применение одного из средств для локализации – Lingobit Localizer (www.lingobit.com).

8. Жизненный цикл программного обеспечения. Основные модели ЖЦ.

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.

Процессы жизненного цикла ПО

1.Основные:

1.Приобретение (действия и задачи заказчика, приобретающего ПО)

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

3.Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)

4.Эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему)

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

2.Вспомогательные

1.Документирование (формализованное описание информации, созданной в течение ЖЦ ПО)

2.Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).

3.Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)

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

5.Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)

6.Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)

7.Аудит (определение соответствия требованиям, планам и условиям договора)

16

8.Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)

3.Организационные

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

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

3.Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)

4.Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:

Инициирование приобретения

Подготовка заявочных предложений

Подготовка и корректировка договора

Надзор за деятельностью поставщика

Приемка и завершение работ

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

Формирование требований к системе

Формирование списка программных продуктов

Установление условий и соглашений

Описание технических ограничений (среда функционирования системы и т. д.)

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

17

Классификация моделей жизненного цикла

К настоящему времени наибольшее распространение получили следующие модели (стратегии) жизненного цикла [4, 7]:

·каскадная;

·инкрементная;

·спиральная.

Дальнейшее рассмотрение моделей жизненного цикла ведется с использованием терминологии классического жизненного цикла.

3.2. Каскадная стратегия

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

Рис.3.1. Каскадная стратегия

18

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

Достоинства модели:

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

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

Недостатки модели:

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

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

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

3.3. Инкрементная стратегия

Инкрементная стратегия (англ. increment – увеличение, приращение) подразумевает разработку информационной системы с линейной последовательностью стадий, но в несколько инкрементов (версий), т. е. с запланированным улучшением продукта (рис.3.2).

Рис.3.2. Инкрементная стратегия

20

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

Достоинства модели:

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

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

·обеспечивает большую гибкость в управлении проектом;

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

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

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

Недостатки модели:

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

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

9. Каноническое проектирование ИС

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

Каноническое проектирование ИС характеризуется следующими особенностями:

1.Отражает особенности ручной технологии проектирование;

2.Предполагает выполнение индивидуального (оригинального) проектирования;

3.Не предполагает использования средств интеграции;

4.Соответствует каскадной модели ЖЦ ИС.

На сегодняшний день технологию канонического проектирования используют при разработке сравнительно небольших ИС.

При каноническом подходе выделяются следующие этапы: Стадия 1. Формирование требований к ИС.

На начальной стадии проектирования выделяют следующие этапы работ:

·обследование объекта и обоснование необходимости создания ИС;

·формирование требований пользователей к ИС;

·оформление отчета о выполненной работе и технического задания на разработку. Стадия 2. Разработка концепции ИС.

·изучение объекта автоматизации;

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

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

·оформление отчета и утверждение концепции.