Лекции.Орг


Поиск:




Категории:

Астрономия
Биология
География
Другие языки
Интернет
Информатика
История
Культура
Литература
Логика
Математика
Медицина
Механика
Охрана труда
Педагогика
Политика
Право
Психология
Религия
Риторика
Социология
Спорт
Строительство
Технология
Транспорт
Физика
Философия
Финансы
Химия
Экология
Экономика
Электроника

 

 

 

 


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




Лабораторная работа № 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 часа тренировки», а не «машинистка может выполнить задачу Х» (Это также может быть определено в Атрибутах Программной Системы в разделе, озаглавленном Простота использования).

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

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





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


Дата добавления: 2016-11-02; Мы поможем в написании ваших работ!; просмотров: 2487 | Нарушение авторских прав


Поиск на сайте:

Лучшие изречения:

Студенческая общага - это место, где меня научили готовить 20 блюд из макарон и 40 из доширака. А майонез - это вообще десерт. © Неизвестно
==> читать все изречения...

2389 - | 2339 -


© 2015-2025 lektsii.org - Контакты - Последнее добавление

Ген: 0.011 с.