Показать сообщение отдельно
Старый 15.05.2015, 14:04   #2
Case
Новичок
 
Регистрация: 15.05.2015
Сообщений: 2
Сказал спасибо: 0
Поблагодарили 9 раз(а) в 2 сообщениях
По умолчанию Продолжения ответов

58. Оптимизация программ.
Оптимизацией программы называют такие преобразования, которые позволяют сделать ее более эффективной, т.е. сделать ее более экономной по памяти и/или более быстрой по выполнению тех же функций, что и до оптимизационного преобразования.
59. Отладка и тестирование программ.
Отладка — этап разработки компьютерной программы, на котором обнаруживают, локализуют и устраняют ошибки. Чтобы понять, где возникла ошибка, приходится:
 Узнавать текущие значения переменных;
 Выяснять, по какому пути выполнялась программа.
Существуют две взаимодополняющие технологии отладки.
1. Использование отладчиков — программ, которые включают в себя пользовательский интерфейс для пошагового выполнения программы: оператор за оператором, функция за функцией, с остановками на некоторых строках исходного кода или при достижении определённого условия.
2. Вывод текущего состояния программы с помощью расположенных в критических точках программы операторов вывода — на экран, принтер, громкоговоритель или в файл. Вывод отладочных сведений в файл называется журналированием.
Тестирование программного обеспечения — процесс исследования, испытания программного продукта, имеющий две различные цели:
 продемонстрировать разработчикам и заказчикам, что программа соответствует требованиям;
 выявить ситуации, в которых поведение программы является неправильным, нежелательным или не соответствующим спецификации.
60. Источники и классификация ошибок.
Классификация ошибок.
По степени критичности (Severity). Принципом такой классификации ошибок является степень их критичности для работы системы в целом. Набор групп, по которым они делятся, отличается в зависимости от области применения этих программ.
Блокирующие (Blocker) – Ошибки, из-за которых дальнейшая работа с системой становится невозможной. Пример: Работа на сайте доступна только зарегистрированным пользователям, а вход возможен только после подтверждения e-mail, указанного при регистрации. На почту не приходит письмо. Работа с системой, соответственно, невозможна.
Важные (Major) — Из-за таких ошибок система, в целом, работает, но что-то работает не так.
Например, опять же, беря в пример наш абстрактный сайт, на сайт можно загрузить аватар, но файл не сохраняется на сервере. Либо письмо для активации приходит, но в неверной кодировке.
Обычные (Normal) — Как правило, к этой категории баги относят очень редко. В качестве примера, могу написать что-то вроде не работает кнопка «Запомнить меня» на сайте.
Малозначимые (Minor) — к таким, как правило, относятся небольшие баги, типа опечаток, «плавания» вёрстки в IE6 на определенной странице в админке и т.п. Редко исправляются по одному, собираются в несколько десятков/сотен/тысяч в зависимости от продукта и фиксятся «пачкой»
По приоритету (Priority). Как быстро надо пофиксить тот или иной баг.
FIX IN RELEASE — Пофиксить в новой версии продукта. Как правило, относится к багам, обнаруженным в процессе тестирования нового функционала.
MUST FIX — Пофиксить как можно быстрее. Как правило, включает в себя блокирующие баги, которые должны быть исправлены в специальном сервис паке, до выхода новой версии.
FIX IF TIME — «Пофиксить, если есть время» — к этой категории, как правило, относятся минорные баги.
NEVER FIX — «Не фиксить никогда». Например, какая та фича будет удалена из следующей версии продукта, либо найдена в продукте, который уже более не поддерживается, или его поддержка прекратится в ближайшее время.
Возникновение всех программных ошибок можно свести к двум общим случаям.
Нарушается физическая или логическая структура файлов, папок и дисков. Грубо говоря, где-то на диске вместо единицы записан ноль (или наоборот) или часть файла не читается вовсе. Возможно, нужный файл был просто удалён, то есть сведения о нём исчезли из файловой системы. Это можно сравнить с опечаткой, кляксой или вырванной из книги страницей. Система пытается найти и прочитать очередной файл, ей это не удаётся, и в ходе загрузки происходит ошибка.


61. Объектно-ориентированное проектирование.
Объектно-ориентированное проектирование (ООП) — это часть объектно-ориентированной методологии, которая предоставляет возможность программистам оперировать понятием «объект», нежели понятием «процедура» при разработке своего кода. Объекты содержат инкапсулированные данные и процедуры, сгруппированные вместе, отображая т.о. сущность объекта. «Интерфейс объекта», описывает взаимодействие с объектом, то, как он определен. Программа, полученная при реализации объектно-ориентированного исходного кода, описывает взаимодействие этих объектов.
62. Язык UML.
Язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.
63. Современные технологии проектирования приложений.
CASE (англ. Computer-Aided Software Engineering) — набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов.[1] Также под CASE понимают совокупность методов и средств проектирования информационных систем с использованием CASE-инструментов.
Средства автоматизации разработки программ (CASE-средства) — инструменты автоматизации процессов проектирования и разработки программного обеспечения для системного аналитика, разработчика ПО и программиста. Первоначально под CASE-средствами понимались только инструменты для упрощения наиболее трудоёмких процессов анализа и проектирования, но с приходом стандарта ISO/IEC 14102 CASE-средства стали определять как программные средства для поддержки процессов жизненного цикла ПО.
Основной целью CASE-технологии является разграничение процесса проектирования программных продуктов от процесса кодирования и последующих этапов разработки, максимально автоматизировать процесс разработки. Для выполнения поставленной цели CASE-технологии используют два принципиально разных подхода к проектированию: структурный и объектно-ориентированный.
Структурный подход предполагает декомпозицию (разделение) поставленной задачи на функции, которые необходимо автоматизировать. В свою очередь, функции также разбиваются на подфункции, задачи, процедуры. В результате получается упорядоченная иерархия функций и передаваемой информацией между функциями.
64. Проблемы человеко-машинного взаимодействия.
В связи с тем, что человеко-компьютерное взаимодействие изучается как с человеческой стороны, так и с компьютерной, то знания, полученные в ходе исследования, опираются как на человеческий фактор, так и на компьютерный. С компьютерной стороны важны технологии компьютерной графики, операционных систем, языков программирования и среды разработки. С человеческой стороны, теория коммуникации, графическое и производственное проектирование, лингвистика, социология, когнитивная психология и такие человеческие факторы как удовлетворение пользователей.
Также имеет значение инженерия и проектирование. Благодаря междисциплинарному характеру человеко-компьютерного взаимодействия, люди с разным уровнем подготовки вносят вклад в его успех. Иногда человеко-компьютерное взаимодействие называют как человеко-машинное взаимодействие, так и компьютерно-человеческое взаимодействие.
Важным критерием является внимание к человеко-компьютерному взаимодействию, так как плохо разработанные интерфейсы могут стать причиной многих непредвиденных проблем. Классическим примером этого является авария на АЭС Три-Майл-Айленд, где в ходе расследования было выявлено, что, по крайне мере, частичную ответственность за катастрофу несёт на себе проектирование интерфейса. Подобным образом, аварии в авиации возникали вследствие решения производителей использовать нестандартные воздушные приборы и/или расположение штурвала. Хотя предполагалось, что новые конструкции более совершенны касательно основного человеко-компьютерного взаимодействия, пилотам было присуще «стандартное» расположение и, таким образом, концептуально хорошая идея, не повлекла желаемые результаты.
65. Законы восприятия информации человеком.
Закон восприятия информации практически говорит сам за себя. Если информация или указания не преподносятся в доступной форме, то данная информация будет неэффективна и от неё не будет никакого положительного действия. В большинстве случаев лучшие указания – самые короткие и самые простые. Использование в равной мере аудио и видео форматов, включая графику и текст, могут сделать указания более информативными и при этом несложными для восприятия.
Использование разнообразных элементов для объяснения важных инструкций, указаний и информационных ключей работает на вас.
66. Цветовые модели.
Цветовая модель — математическая модель описания представления цветов в виде кортежей чисел (обычно из трёх, реже — четырёх значений), называемых цветовыми компонентами или цветовыми координатами. Все возможные значения цветов, задаваемые моделью, определяют цветовое пространство.
Цветовая модель обычно используется для хранения и обработки цветов в дискретном виде, при представлении ее в вычислительных устройствах, в частности, ЭВМ.
Цветовая модель задаёт соответствие между воспринимаемыми человеком цветами, хранимыми в памяти, и цветами, формируемым на устройствах вывода (возможно, при заданных условиях).
67. Основы проектирования пользовательского интерфейса. Этапы и средства проектирования.
Пользовательский интерфейс – это совокупность информационной модели проблемной области, средств и способов взаимодействия пользователя с информационной моделью, а также компонентов, обеспечивающих формирование информационной модели в процессе работы программной системы.
Основное достоинство хорошего интерфейса пользователя заключается в том, что пользователь всегда чувствует, что он управляет программным обеспечением, а не программное обеспечение управляет им. Для создания у пользователя такого ощущения «внутренней свободы» интерфейс должен обладать целым рядом свойств:
Естественность интерфейса - такой, который не вынуждает пользователя существенно изменять привычные для него способы решения задачи. Это, в частности, означает, что сообщения и результаты, выдаваемые приложением, не должны требовать дополнительных пояснений.
Согласованность интерфейса - согласованность позволяет пользователям переносить имеющиеся знания на новые задания, осваивать новые аспекты быстрее, и благодаря этому фокусировать внимание на решаемой задаче, а не тратить время на уяснение различий в использовании тех или иных элементов управления, команд и т.д. Обеспечивая преемственность полученных ранее знаний и навыков, согласованность делает интерфейс узнаваемым и предсказуемым.
Дружественность интерфейса (Принцип «прощения пользователя») - пользователи обычно изучают особенности работы с новым программным продуктом методом проб и ошибок. Эффективный интерфейс должен принимать во внимание такой подход. На каждом этапе работы он должен разрешать только соответствующий набор действий и предупреждать пользователей о тех ситуациях, где они могут повредить системе или данным; еще лучше, если у пользователя существует возможность отменить или исправить выполненные действия.
Принцип «обратной связи» - необходимо всегда обеспечивать обратную связь для действий пользователя. Каждое действие пользователя должно получать визуальное, а иногда и звуковое подтверждение того, что программное обеспечение восприняло введенную команду; при этом вид реакции, по возможности, должен учитывать природу выполненного действия.
Простота интерфейса - интерфейс должен быть простым. При этом имеется в виду не упрощенчество, а обеспечение легкости в его изучении и в использовании. Кроме того, он должен предоставлять доступ ко всему перечню функциональных возможностей, предусмотренных данным приложением. Реализация доступа к широким функциональным возможностям и обеспечение простоты работы противоречат друг другу. Разработка эффективного интерфейса призвана сбалансировать эти цели.
Гибкость интерфейса - это его способность учитывать уровень подготовки и производительность труда пользователя. Свойство гибкости предполагает возможность изменения структуры диалога и/или входных данных. Концепция гибкого (адаптивного) интерфейса в настоящее время является одной из основных областей исследования взаимодействия человека и ЭВМ. Основная проблема состоит не в том, как организовать изменения в диалоге, а в том, какие признаки нужно использовать для определения необходимости внесения изменений и их сути.
Эстетическая привлекательность - корректное визуальное представление используемых объектов обеспечивает передачу весьма важной дополнительной информации о поведении и взаимодействии различных объектов. В то же время следует помнить, что каждый визуальный элемент, который появляется на экране, потенциально требует внимания пользователя, которое, как известно, не безгранично.
Этапы проектирования.
Выбор структуры диалога — это первый из этапов, который должен быть выполнен при разработке интерфейса. Существует 4 разновидности структур диалога:
Диалог типа «вопрос-ответ».
Диалог на основе меню.
Диалог на основе экранных форм.
Диалог на основе командного языка.
Позиционные параметры уменьшают объем вводимой информации, но их существенным недостатком является то, что вводимые значения должны указываться в строго определенном порядке, нарушение которого плохо диагностируется системой и может повлечь серьезные последствия.
Ключевые параметры уменьшают нагрузку на память пользователя в том отношении, что отпадает необходимость в запоминании порядка их следования; кроме того, можно опускать необязательные параметры. С другой стороны, в этом случае пользователю необходимо запомнить множество ключевых слов, а разработчику —подобрать для них «осмысленные» имена.
Разработка сценария диалога. Развитие диалога во времени можно рассматривать как последовательность переходов системы из одного состояния в другое. Ни одно из этих состояний не должно быть «тупиковым», т.е. пользователь должен иметь возможность перейти из любого текущего состояния диалога в требуемое (за один или несколько шагов). Для этого в ходе разработки интерфейса необходимо определить все возможные состояния диалога и пути перехода из одного состояния в другое. Другими словами, необходимо разработать сценарий диалога.
Темп ведения диалога. Процесс общения пользователя с компьютером связан с рядом существенных объективных и субъективных ограничений и должен соответствовать психофизиологическим возможностям человека. В связи с этим при разработке сценария диалога должны учитываться такие психофизиологические особенности потенциальных пользователей, как моторные навыки, время реакции, восприимчивость цветовой гаммы и т.д.
Время ответа (отклика) системы определяется как интервал между событием и реакцией системы на него. Данная характеристика интерфейса определяет задержку в работе пользователя при переходе к выполнению следующего шага задания.
68. Основные правила проектирования программ с точки зрения отображения информации.

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

Добавлено через 4 минуты
Всем кому не очень так удобно читать выделите текст и вставьте в Word.

Последний раз редактировалось Case; 15.05.2015 в 14:08. Причина: Добавлено сообщение
Case вне форума   Ответить с цитированием
7 пользователя(ей) сказали cпасибо: