Материал: Правила выполнения и проведения лабораторных работ 5 Критерии оценки лабораторных работ 5

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

Рабочие характеристики.

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

Атрибуты.

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

Проектные ограничения, налагаемые на реализацию изделия.

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

Спецификация требований к ПО:

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

б) Не должна описывать детали разработки или реализации. Они должны быть описаны на этапе разработки проекта.

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

Правильно составленная спецификация требований к ПО должна быть:

а) Корректной;

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

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

б) Однозначной;

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

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

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

в) Полной;

Спецификация требований к ПО является полной, если и только, если она включает следующие элементы:

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

г) Непротиворечивой;

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

д) Упорядоченной по ее значимости и/или устойчивости;

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

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

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

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

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

е) Проверяемой;

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

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

Примером проверяемого утверждения является следующее:

Выходные данные программы должны вырабатываться в пределах 20 секунд в течение 60 % временного интервала события; и должны вырабатываться в пределах 30 секунд в течение 100 % временного интервала события.

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

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

ж) Модифицируемой;

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

1) Имела связанную и легкую в использовании структуру с оглавлением, алфавитным указателем и явно выраженными перекрестными ссылками;

2) Не была избыточной (то есть, одно и то же требование не должно появляться в спецификации требований более чем в одном месте);

3) Выражала каждое требование раздельно, не смешивая его с другими требованиями.

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

з) Отслеживаемой.

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

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

Зависит от каждого требования, которое в явном виде ссылается на его источник в более ранних документах.

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

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

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

Задание.

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

Лабораторная работа №59: Санитарно-гигиенические требования к размещению компьютерного оборудования

Цели работы: Изучение эксплуатационных требований к компьютерному рабочему месту; выполнить характеристику и анализ организации своего рабочего места.

Продолжительность: 2 часа

Теоретическая часть

Согласно СанПиН 2.2.2/2.4.1340—03 «Гигиенические требования к персональным электронно-вычислительным машинам и организации работы»: площадь на одно рабочее место пользователей ПЭВМ с ВДТ на базе электроннолучевой трубки (ЭЛТ) должна составлять не менее 6 м2, в помещениях культурно-развлекательных учреждений и с ВДТ на базе плоских дискретных экранов (жидкокристаллические, плазменные) — 4,5 м2.

При размещении рабочих мест с ПЭВМ расстояние между рабочими столами с видеомониторами (в направлении тыла поверхности одного видеомонитора и экрана другого видеомонитора), должно быть не менее 2,0 м, а расстояние между боковыми поверхностями видеомониторов — не менее 1,2 м.

Рабочие места с ПЭВМ при выполнении творческой работы, требующей значительного умственного напряжения или высокой концентрации внимания, рекомендуется изолировать друг от друга перегородками высотой 1,5 — 2,0 м.

Экран видеомонитора должен находиться от глаз пользователя на расстоянии 600 — 700 мм, но не ближе 500 мм с учетом размеров алфавитно-цифровых знаков и символов.

Высота рабочей поверхности стола для взрослых пользователей должна регулироваться в пределах 680 —800 мм; при отсутствии такой возможности высота рабочей поверхности стола должна составлять 725 мм.

Модульными размерами рабочей поверхности стола для ПЭВМ, на основании которых должны рассчитываться конструктивные размеры, следует считать: ширину 800, 1000, 1200 и 1400 мм, глубину 800 и 1000 мм при нерегулируемой его высоте, равной 725 мм.

Рабочий стол должен иметь пространство для ног высотой не менее 600 мм, шириной — не менее500 мм, глубиной на уровне колен — не менее 450 мм и на уровне вытянутых ног — не менее 650 мм.

Конструкция рабочего стула должна обеспечивать:

- ширину и глубину поверхности сиденья не менее 400 мм;

- поверхность сиденья с закругленным передним краем;

- регулировку высоты поверхности сиденья в пределах 400 — 550 мм и углам наклона вперед до 15 град, и назад до 5 град.;

- высоту опорной поверхности спинки 300 +-20 мм, ширину — не менее 380 мм и радиус кривизны горизонтальной плоскости — 400 мм;

- угол наклона спинки в вертикальной плоскости в пределах +-30 градусов;

- регулировку расстояния спинки от переднего края сиденья в пределах 260 — 400 мм;

Источник: https://files.student-it.ru/previewfile/275630

Смотрите также:



17. Введение 18. Линейные программы 19. Ветвления 20. Программирование циклических алгоритмов
Сборные железобетонные ребристые плиты перекрытия
_-___-~1
_3 тема - Диффузия
_Роджерс Карл, Брак и его альтернативы
_Штерн Вильям, Дифференциальная психология и ее методические основы
- Описание типа СЭТ7009
- Программа ГПИ