Файл: Методические указания по выполнению лабораторных и практических работ по мдк.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 28.04.2024
Просмотров: 139
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
8
Спецификация требований к ПО должна быть однозначной как для тех, кто составляет ее, так и для тех, кто ее использует. Однако, эти группы часто не имеют одинаковую квалификацию и, следовательно, не имеют тенденции к описанию требований к программному обеспечению одним и тем же образом. Способы представления требований, которые улучшают спецификацию требований для разработчика, могут оказаться неэффективными в том, что они уменьшают их понимание пользователем, и наоборот.
Полной;
Спецификация требований к ПО является полной, если и только, если она включает следующие элементы:
Все существенные требования, независимо от того, относятся ли они к функциональным возможностям, рабочим характеристикам, проектным ограничениям, атрибутам или внешним интерфейсам. В частности, должны быть подтверждены и обработаны любые внешние требования, налагаемые спецификацией системы.
Определение откликов программного обеспечения на все классы входных данных, которые могут быть реализованы, во всех возможных ситуациях. Следует заметить, что важно определить отклики, как на допустимые, так и недопустимые входные значения.
Полные обозначения и ссылки на все рисунки, таблицы и схемы в спецификации требований к ПО и определение всех терминов и единиц измерения.
Непротиворечивой;
Непротиворечивость обозначает внутреннюю непротиворечивость. Если спецификация требований к ПО не согласовывается с каким-то документом более высокого уровня, таким как, например, спецификации системных требований, то она является некорректной.
Упорядоченной по ее значимости и/или устойчивости;
Спецификация требований к ПО является упорядоченной по значимости и/или устойчивости, если каждое требование в ней имеет идентификатор, указывающий или значимость или устойчивость этого конкретного требования.
Как правило, все требования, которые касаются программного изделия, не являются важными в равной степени. Некоторые требования могут быть необходимыми, особенно для приложений, критичных в течение жизненного цикла, в то время как другие могут быть желательными.
Каждое требование в спецификации требований к ПО должно быть идентифицировано, чтобы сделать эти различия четкими и явными. Идентификация требований следующим образом помогает:
заказчикам более тщательно рассмотреть каждое требование, что часто позволяет разъяснить любые скрытые допущения, которые могут быть заключены в них.
разработчикам принять правильные проектные решения и приложить соответствующие усилия к различным составляющим программного изделия.
Проверяемой;
Спецификация требований к ПО является проверяемой, если и только, если каждое требование, изложенное в ней, может быть проверено. Требование являются проверяемым, если и только, если существует некий конечный эффективный процесс, используя который пользователь или машина могут убедиться, что программное изделие удовлетворяет этому требованию. В целом, любое неоднозначное требование не проверяемо.
Непроверяемые требования включают формулировки типа "работает хорошо", "хороший интерфейс с пользователем" и "обычно должно происходить". Эти требования не могут быть проверены, так как невозможно определить термины "хороший", "хорошо" или "обычно".
Утверждение о том, что "программа никогда не должна зацикливаться" является непроверяемым, так как тестирование этого свойства теоретически невозможно.
Примером проверяемого утверждения является следующее:
Выходные данные программы должны вырабатываться в пределах 20 секунд в течение
60 % временного интервала события; и должны вырабатываться в пределах 30 секунд в
течение 100 % временного интервала события.
Это утверждение может быть проверено, так как в нем используются конкретные термины и измеримые величины.
Если нельзя изобрести метод, чтобы определить, отвечает ли программное обеспечение определенному требованию, то это требование следует исключить или пересмотреть.
9
Модифицируемой;
Спецификация требований к ПО является модифицируемой, если и только, если ее структура и стиль таковы, что любые изменения требований могут быть выполнены легко, полностью и непротиворечивым образом при сохранении структуры и стиля. Как правило, модифицируемость требует, чтобы спецификация требований:
1) Имела связанную и легкую в использовании структуру с оглавлением, алфавитным указателем и явно выраженными перекрестными ссылками;
2) Не была избыточной (то есть, одно и то же требование не должно появляться в спецификации требований более чем в одном месте);
3) Выражала каждое требование раздельно, не смешивая его с другими требованиями.
Избыточность сама по себе не является ошибкой, но она легко может привести к появлению ошибок. Иногда избыточность может помочь сделать спецификацию требований более читаемой, но тогда могут возникнуть проблемы при модификации избыточного документа.
Например, требование может быть изменено только в одном из тех мест, где оно появляется.
Тогда спецификация требований становится противоречивой. Каждый раз, когда избыточность необходима, спецификация требований должна включать явные перекрестные ссылки, чтобы сделать ее модифицируемой.
Отслеживаемой.
Спецификация требований к ПО является отслеживаемой, если четко прослеживается источник каждого из ее требований и если она облегчает обращение к каждому из требований при дальнейшей разработке или модернизации документации. Рекомендуются следующие два типа отслеживаемости:
1. Обратная отслеживаемость (то есть, к предыдущим стадиям разработки).
Зависит от каждого требования, которое в явном виде ссылается на его источник в более ранних документах.
2. Прямая отслеживаемость (то есть, ко всем документы, порождаемым спецификацией требований.
Зависит от каждого требования в спецификации требований, имеющего однозначно определенное имя или номер ссылки.
Прямая отслеживаемость спецификации требований особенно важна, когда программное изделие вступает в стадию функционирования и сопровождения. По мере изменения кода и проектных документов необходимо иметь возможность определить полный набор требований, на которые могут повлиять эти изменения.
Задание.
1. Оформить внешнюю спецификацию к задаче.
2. Составить в виде блок-схемы алгоритм решения задачи.
3. Создать программу решения задачи на любом алгоритмическом языке программирования.
4. Отладить программу.
5. Составить отчет по практической работе.
Отчет по практической работе должен включать:
1. Внешнюю спецификацию.
2. Алгоритм решения задачи.
3. Текст программы на языке программирования.
4. Набор тестов для отладки программы.
Задача: Составить алгоритм и написать программу нахождения экстремального значения и/или его порядкового номера для заданных одномерных массивов (A[N], B[M], где N и M – размер массивов).
Варианты индивидуальных заданий.
1. Определить наименьшую среди сумм
, (K=1,.., N) соответствующий номер K.
2. Определить две наибольшие по абсолютной величине разности A
i
-A
i-1
, где i=2..N, и соответствующие значения индекса i.
3. Определить наибольшее из отношений
, где i=1,...,N и соответствующий индекс i.
10 4. Определить наименьшее и наибольшее значения разности A
i
- B
N-i+1
, где i=1..N, и соответствующий индекс i.
5. Определить наибольшую среди сумм
,
, (K=1,..,N) и соответствующий номер K.
6. Определить два наименьших из значений
,
(K=1,..,M) и соответствующие номера K.
7. Определить наименьшее из значений
, (K=1,..,N) и соответствующий номер K.
8. Определить наименьшую среди сумм
,
, (K=1,..,N) и соответствующий номер K.
9. Определить наибольшее из произведений
,
10. Определить наибольшее из произведений и соответствующий номер K.
11. Определить наименьшее среди произведений
,
(K=1,..,M) и соответствующий номер K.
12. Определить наименьшую среди сумм и
, (K=1,..,N) и соответствующий номер K.
13. Определить два наибольших из абсолютных значений
,
,
(K=1,..,M) и соответствующие номера K.
14. Определить наименьшее из значений
,
(K=1,.., M) и соответствующий номер K.
15. Определить наибольшее по абсолютной величине из отношений
,(K=1,..,N) и соответствующий номер K.
16. Определить наименьшее из значений
, (i=1,.., N) и соответствующий индекс i.
17. Определить два наибольших из произведений
, (K=1,…,N) и соответствующий номер K.
18. Определить наименьшее из значений
, (i=1,.., N) и номер соответствующего индекса i.
11 19. Определить наибольшее среди произведений
,
(K=1,..,M) и соответствующий номер K.
20. Определить наименьшее из значений
,
,
(K=1,..,M) и соответствующий номер K.
21. Определить два наибольших из произведений
,
(i=1,.., N) и соответствующие значения индекса i.
22. Определить наименьшее по абсолютной величине из значений и
, (K=1,..,N) и соответствующие номера K.
23. Определить наибольшее по абсолютной величине из значений
,
(K=1,..,N), и соответствующее значение K.
24. Определить два наименьших по абсолютной величине из значений
,
(K=1,..,M) и соответствующее значение K.
25. Определить наименьшее и наибольшее из произведений
, (K=1,..,N) и соответствующие значения K.
Практическая работа № 1.2. Оформление документации
на программные средства
Цель работы приобретение практических навыков по разработке технологической проектной документации на программные средства различного назначения согласно требованиям стандартов ЕСПД.
Теоретический материал
ГОСТ 19.202. Спецификация. Требования к содержанию и оформлению
Настоящий стандарт устанавливает форму и порядок составления программного документа «Спецификация», определенного ГОСТ 19.101. Спецификация является основным программным документом для компонентов, применяемых самостоятельно, и для комплексов.
Для компонентов, не имеющих спецификации, основным программным документом является
«Текст программы».
Информационную часть (аннотацию и содержание) допускается в документ не включать.
Форма спецификации приведена на рис.1.
Спецификация в общем случае должна содержать разделы:
документация;
комплексы;
компоненты.
Наименование каждого раздела указывают в виде заголовка в графе «Наименование». Для документов, выполненных печатным способом, заголовок подчеркивают.
12
Рисунок 1 - Форма спецификации
В раздел «Документация» вносят программные документы на данную программу, кроме спецификации и технического задания, в порядке возрастания кода вида документа, входящего в обозначение. Далее записывают заимствованные программные документы. Запись их производится в порядке возрастания кодов предприятий-разработчиков и далее в порядке возрастания кода вида документа, входящего в обозначение.
После каждого раздела спецификации необходимо оставлять несколько свободных строк для дополнительных записей.
Графы спецификаций заполняют следующим образом:
в графе «Обозначение» указывают: в разделе «Документация» – обозначение записываемых документов программы; в разделе «Комплексы» – обозначение спецификаций комплексов, входящих в данный комплекс; в разделе «Компоненты» – обозначения основных программных документов компонентов.
в графе «Наименование» указывают: в разделе «Документация» – наименование и вид документа для документов на данную программу; полное наименование программы, наименование и вид документа для заимствованных документов; в разделах «Комплексы» и «Компоненты» – полное наименование программы, наименование и вид документа.
в графе «Примечание» указывают дополнительные сведения, относящиеся к записанным в спецификации программам.
В графе «Обозначение» запись производят в одну строку. В остальных графах спецификации записи допускаются в несколько строк.
ГОСТ 19.301. Программа и методика испытаний. Требования к содержанию, оформлению и контролю качества
Настоящий стандарт устанавливает требования к содержанию и оформлению программного документа «Программа и методика испытаний». Содержит номенклатуру показателей качества ПС, определяемых на основе результатов анализа данного документа, и методические указания по определению количественных значений показателей качества.
Применяемость показателей качества и соответствующих им требований при разработке документа и контроле качества осуществляют в зависимости от принадлежности документируемой программы к конкретному подклассу ПС и устанавливают в соответствии с
ГОСТ 28195. Наименования и обозначения показателей качества приведены по ГОСТ 28195.
1. Требования к содержанию
Составление информационной части (аннотации и содержания) является необязательным.
Документ «Программа и методика испытаний» должен содержать следующие разделы:
• объект испытаний;
• цель испытаний;
• требования к программе;
• требования к программной документации;
• средства и порядок испытаний;
• методы испытаний.
