Графический интерфейс обладает рядом преимуществ



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

-Каждая программа выполняется в своем окне (окнах). Можно переключаться из одной программы в другую не теряя при этом данных.

Принципы проектирования пользовательских интерфейсов.

Учет знаний пользователя: В интерфейсе необходимо использовать термины и понятия, взятые из опыта будущих пользователей системы.

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

Минимум неожиданностей: Поведение системы должно быть прогнозируемым.

Руководство пользователя: Интерфейс должен предоставлять необходимую информацию в случае ошибок пользователя и поддерживать средаства контекстно-зависимой справки

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

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

 

Билет 7

Модели жизненного цикла ПО.

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

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

В настоящее время известны и используются следующие модели жизненного цикла:

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

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

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

На практике наиболее распространения получили две основные модели: каскадная (характерная для периода 1970-1985 гг); спиральная (характерна для периода после 1986 гг).

Положительные стороны применения каскадного подхода:

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

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

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

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

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

Тестирование ПО.

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

Тестирование – процесс выполнения его программ на некотором наборе данных. Для которого заранее известен результат применения или известны правила поведения этих программ.

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

 

Билет 8

Диаграмма развертывания.

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

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

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

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

Соединение - это канал взаимодействия узлов (сеть).

Принципы и виды отладки ПО.

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

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

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

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

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

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

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

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

 

Билет 9


Дата добавления: 2018-04-04; просмотров: 520; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!