Краткие сведения из теории. Разработка спецификаций структурных единиц

Лабораторная работа № 1

Разработка спецификаций структурных единиц.

Цель работы

В соответствии с рабочей программой по дисциплине «Системное программирование» в результате выполнения заданий по лабораторным работам студент должен:

уметь:

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

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

знать:

- основные принципы технологии структурного и объектно-ориентированного программирования;

- методы и средства разработки технической документации;

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

Таким образом, студент во время проведения занятия и самостоятельной работы по теме занятия должен:

- приобрести навыки разработки спецификаций системного программного обеспечения;

- закрепить теоретические знания о формировании требований к программному обеспечению.

Краткие сведения из теории

Основными вопросами, которые должны рассматривать составитель (-ли) спецификаций, являются следующие:

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

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

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

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

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

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

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

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

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

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

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

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

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

а) Разбиение программного обеспечения на модули;

б) Присваивание функций модулям;

в) Описание потока данных или управления между модулями;

г) Выбор структур данных.

Рекомендуемое содержание спецификации:

1. Введение

1.1 Назначение

1.2 Область действия

1.3 Определения, акронимы и сокращения

1.4 Публикации

1.5 Краткий обзор

2. Полное описание

2.1 Контекст изделия

2.2 Функции изделия

2.3 Характеристики пользователя

2.4 Ограничения

2.5 Допущения и зависимости

3. Специфические требования

Приложения

Алфавитный указатель

Назначение (Подраздел 1.1Спецификации)

Этот подраздел должен:

а) Обрисовать назначение спецификации;

б) Указать аудиторию, для которой предназначена спецификации.

Область действия (Подраздел 1.2Спецификации)

Этот подраздел должен:

а) Задавать название создаваемому программное изделию (-ям) (например, Host DMBS (Главная система управления базой данных), Генератор отчетов и т.д.);

б) Объяснять, что программное изделие будет и, в случае необходимости, не будет делать;

в) Описывать применение задаваемого программного обеспечения, включая связанные с ним выгоды, цели и задачи;

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

Определения, акронимы и сокращения (Подраздел 1.3Спецификации)

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

Публикации (Подраздел 1.4Спецификации)

Этот подраздел должен:

а) Представить полный список всех документов, на которые делаются ссылки где-либо внутри спецификации;

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

в) Определить источники, из которых могут быть получены ссылки.

Эту информацию можно обеспечить ссылкой на приложение или другой документ.

Краткий обзор (Подраздел 1.5Спецификации)

Этот подраздел должен:

а) Описать, что находится в оставшейся части спецификации;

б) Объяснить, как организована структура спецификации.

Общее описание (Раздел 2Спецификации)

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

Этот раздел обычно состоит из шести подразделов, а именно:

а) Контекст изделия;

б) Функции изделия;

в) Характеристики пользователей;

г) Ограничения;

д) Допущения и зависимости;

е) Разделение требований.

Контекст изделия (Подраздел 2.1Спецификации)

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

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

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

а) Системные интерфейсы;

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

в) Аппаратные интерфейсы;

г) Интерфейсы программного обеспечения;

д) Интерфейсы связи;

е) Память;

ж) Операции;

з) Требования по адаптации места использования.

Системные интерфейсы

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

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

Этот подраздел должен указывать следующее:

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

б) Все аспекты оптимизации интерфейса с пользователем, который должен использовать систему. Они могут просто включать список разрешений и запрещений различных способов представления системы пользователю. Одним из примеров может быть требование, предъявляемое к опции длинных или коротких сообщений об ошибках. Подобно всем другим, эти требования должны быть проверяемыми, например, «машинистка 4-го класса может выполнить задачу X за Z минут после 1 часа тренировки», а не «машинистка может выполнить задачу Х» (Это также может быть определено в Атрибутах Программной Системы в разделе, озаглавленном Простота использования).

Аппаратные интерфейсы

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