лекция. Сборник лекций по МДК _Технология разработки программного обеспе. Курс лекций для специальности спо базовой подготовки

• Название: Курс лекций для специальности спо базовой подготовки
• Анкор: лекция
• Дата: 02.09.2022
• Размер: 4.41 Mb.
• Имя файла: Сборник лекций по МДК _Технология разработки программного обеспе.docx
• Тип: Курс лекций; #660044
• страница: 28 из 62

4. Требования к внешнему интерфейсу

Ниже рассмотрены конкретные рекомендации по написанию разделов этого параграфа, согласно [11.1]:

4.1 Интерфейсы пользователя

Основные характеристики UI:

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

4.2 Интерфейсы оборудования

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

4.3 Интерфейсы ПО

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

4.4 Интерфейсы передачи информации

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

5. Другие нефункциональные требования

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

5.1 Требования к производительности

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

• 
  Приложение А. Словарь терминов (глоссарий).
  
• 
  Приложение Б. Модели анализа. В этот раздел помещаются все модели, построенные в процессе анализа требований (см. материалы "Расширенный анализ требований. Моделирование" ).
  
• 
  Приложение В. Список вопросов.
  

Это динамический список еще не разрешенных проблем, связанных с требованиями. Это могут быть элементы, помеченные как "ТВD" (to be determined - необходимо определить), отложенные решения, необходимая информация, неразрешенные конфликты и т.п.

Документирование требований в MSF

В начале фазы проектирования проектная группа работает с проектными требованиями. Они подразделяются на:

• 
  бизнес-требования,
  
• 
  требования к эксплуатации,
  
• 
  системные требования,
  
• 
  требования пользователя.
  

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

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

С шаблонами соответствующих документов можно ознакомиться на сайте Microsoft, [11.3].

Проверка требований

Верификация и валидация

Термин "верификация" (verification) в русскоязычной литературе обычно переводят, как "проверка". Термин "валидация" - как "проверка правильности", "аттестация", "утверждение".

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

Трудно ожидать от читателя, впервые столкнувшегося с этой терминологией и ее определениями в этом и других стандартах, ясности понимания. По крайней мере, у автора настоящего курса лекций при первом знакомстве с определениями тех же понятий в ISO IEC 12207 возникло четкое ощущение, что авторы стандарта явно чего-то не договаривают. Посудите сами: согласно данному стандарту, верификация - это подтверждение экспертизой и представлением объективных доказательств того, что конкретные требования полностью реализованы. С другой стороны, валидация - это подтверждение экспертизой и представлением объективных доказательств того, что конкретные требования к конкретным объектам полностью реализованы. Правда, к чести авторов последнего стандарта, они приводят примечание, которое несколько приближает читателя к пониманию: "валидация связана с экспертизой продукта в целях определения его соответствия потребностям пользователя". В этом и заключается суть отличия: если верификация связана с выяснением того, удовлетворяет ли разрабатываемый объект, либо процесс его создания сформулированным требованиям, то валидация отвечает на вопрос - правильно ли разработан целевой объект (продукт), удовлетворяет ли он потребностям заказчика. Другой аспект валидации заключается в том, что она обычно увязывается с формальной приемкой (аттестацией) системы.

Некоторые стандарты, например SWEBOK, IEEE 1059-93 "IEEE Guide for Software Verification and Validation Plans", вводят для этих двух процессов обобщающее понятие V&V (Validation and Verification). Согласно IEEE 1059-93, верификация и валидация программного обеспечения - упорядоченный подход в оценке программных продуктов, применяемый на протяжении всего жизненного цикла. Усилия, прилагаемые в рамках работ по верификации и валидации, направлены на обеспечение качества как неотъемлемой характеристики программного обеспечения и удовлетворение пользовательских требований.

Из вышесказанного ясно, как осуществить верификацию и валидацию АИС и (или) процесса ее создания: в первом случае необходимо убедиться, что АИС (компонента, процесс) соответствует сформулированным требованиям, во втором - что АИС действительно работает! Но если критерием проверки АИС служат требования, то что может послужить критерием проверки самих требований? Ответ заключается в том, что требования должны удовлетворять свойствам, сформулированным в "Свойства требований" , Кроме того, следует убедиться в том, что [12.1]:

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