Спецификация программного обеспечения образец

Спецификация программного обеспечения образец

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

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

Рис. 3.8. Процесс разработки требований

Процесс разработки требований включает четыре основных этапа.

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

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

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

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

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

3.4. Проектирование и реализация программного обеспечения

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

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

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

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

Ниже перечислены отдельные этапы процесса проектирования.

1. Архитектурное проектирование. Определяются и документируются подсистемы и взаимосвязи между ними.

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

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

4. Компонентное проектирование. Проводится распределение системных функций (сервисов) по различным компонентам и их интерфейсам.

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

6. Проектирование алгоритмов. Детально разрабатываются алгоритмы, предназначенные для реализации системных сервисов.

Рис. 3.9. Обобщенная схема процесса проектирования

Читайте также:  Удаление фото с айфона через компьютер

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

Все мы прекрасно знаем о том, как разрабатывается ПО. Подумали 10 минут и сразу пошли кодить. Цикл создания программного обеспечения состоит из многих ключевых моментов. Это такие моменты как планирование, создания архитектуры, создание SRS, создание дизайна и тд и тп.

Что такое SRS ?

SRS — Software Requirement Specification — специальная документация для ПО которая содержит в себе информацию о том, как должна себя вести система, какие функции должна выполнять, какую нагрузку должна выдерживать и тд.

Зачем оно надо ?

Все предельно просто. Вы используете ТЗ (велосипед), я использую SRS (машину). Надеюсь аналогия получилась ясная? 🙂

Структура SRS

Ниже приведена структура на англ языке в raw виде. Чуть ниже в статье мы рассмотрим каждый пункт более подробно

  • Introduction
  • Purpose
  • Document conventions
  • Intended Audience and Reading Suggestions
  • Project scope
  • References
  • Overall Description
    • Product perspective
    • Product features
    • User classes and characteristics
    • Operating environment
    • Design and implementation constraints
    • User documentation
    • Assumptions and dependencies
    • System features
      • System feature X (таких блоков может быть несколько)
        • Description and priority
        • Stimulus/Response sequences
        • Functional requirements
        • External interface requirements
          • User interfaces
          • Software interfaces
          • Hardware interfaces
          • Communication interfaces
          • Non functional requirements
            • Performance requirements
            • Safety requirements
            • Software quality attributes
            • Security requirements
            • Other requirements
            • Appendix A: Glossary
            • Appendix B: Analysis Models
            • Appendix C: Issues list
            • И так со структурой разобрались, теперь перейдем к разделам и тому, что в них надо писать.

              Базовые требования ко всем разделам SRS

              • Кратко, четко. Описывает все предельно кратко и четко. Насколько это возможно.
              • Без двусмысленных описаний. Человек читающий SRS должен понимать именно то, что написано, а не что-то другое. Закон Мерфи: Если Вас могут понять неправильно, Вас поймут неправильно. Избегайте этого
              • Простота и «читабельность». Не используйте каких либо слишком заумных оборотов. Красота в простоте 🙂
              • DFD-диаграммы. Спецификация не может быть полной если мы не знаем что на входе в описываемый софт, а что на выходе. Все должно быть четко нарисовано.
              • Степень детализации. Это эвристический параметр. Его можно определить так: если я могу свободно изложить информацию о функционале и написанное не вызывает у меня смущения, если требования однозначны и не подлежат никакому двоякому пониманию, если требования в достаточной для меня мере описывают поведение функционала, то проработку SRS можно считать завершенной

              Пояснение каждого пункта структуры SRS

              Introduction Purpose
              В данной секции описываем приложение или продукт, функционал которого будет описываться в SRS.

              Introduction Document conventions
              Здесь мы описываем все непонятные технические слова или термины которые встречаются в SRS. Заметьте, что описание непонятного слова не может содержать другое непонятное слово. Старайтесь расписать как можно подробнее термин который Вы используете простым и понятным всем языком. Не экономьте на этой секции потому, что чем больше вы распишете непонятных вещей, тем проще будет потом проектировать.

              Introduction References
              В данной секции мы пишем ссылки на литературу в которой можно найти основания использованных технологий и фактов. Допустим можно вставлять RFC если вы пишете приложение работающее с TCP/IP, вставлять ссылки на документы на которые вы ссылаетесь и тд. Ссылки и их описание должны быть максимально полными, чтобы в случае чего (линк умер просто) можно было нагуглить этот материал.

              Overall Description Product features
              В данном разделе мы описываем части функционала на высоком уровне. Более детально каждая часть функционала будет описана в своем разделе ниже. Тут желательно разместить DFD-диаграмму которая покажет общее взаимодействие системы.

              Overall Description Operating environment
              Как понятно из названия раздела тут мы описываем окружение в котором будет работать продукт. ОС, версии компиляторов, базы данных, сервера, софт, железо и другие вещи которые необходимы для работы вашего продукта.

              Overall Description Design and implementation constraints
              Данный раздел гнусный :). Он ограничивает полет мысли разработчика налагая стандарты разработки. Такими ограничениями могут быть, например, такие вещи:

              • Язык программирования, база данных
              • Стандарты кодирования
              • Стандарты обмена данными
              • Ограничения накладываемые Operational Enviroment, допустим совместимость только с ФФ
              • Ограничения которые могут быть наложены бизнес-логикой проекта

              Overall Description User documentation
              Описываем какая документация нужна для пользователей данного продукта. Возможно это книга по HTML если это HTML редактор.

              Читайте также:  Встретившись однажды полностью расстаться невозможно

              System features System feature X
              Называем фичу проекту и даем ей уникальный идентификатор. Например, server.html.editor. Уникальный идентификатор дается для того, чтобы потом где то в тикетах ваших не писать — «а вот та хреновина, которая позволяет редактировать хтмл»

              System features System feature X Description and priority
              Описываем детально фичу продукта. Для чего она? Что должна делать? Какой у нее приоритет выполнения. Из этого раздела читающему срс человеку должно сразу стать понятно зачем этот функционал присутствует в системе.

              System features System feature X Stimulus/Response sequences
              Триггер запуска фичи. Когда она запускается и как себя ведет при запуске? Например, HTML редактор показывается при нажатии пользователя на ссылку меню Открыть HTML редактор

              System features System feature X Functional requirements
              Подробное и детальное описание фичи. Описываем все: как работает, как реагирует на ошибки, что должно проверять, как отображать данные, как и куда что сохраняет и тд

              External interface requirements
              Описание того как система будет взаимодействовать с внешним миров. Если будет конечно. Какие API, как получить те или иные данные и тп. Подразделы служат для детализации требований. Какие софт интерфейсы, «железячные» интерфейсы, комуникационные интерфейсы и прочее.

              Non functional requirements
              Не функциональные требования. Есть требования которые невозможно описать как какую то фичу, например, требования к безопасности.

              Non functional requirements Performance requirements
              Требования к производительности. Это не фича, однако налагает определенные ограничения. Допустим база данных проекта должна выдерживать 1000 запросов в секунду и тп. Эти требования приводят к колоссальной работе по оптимизации проекта.

              Non functional requirements Software quality attributes
              Тут мы описываем требования к качеству кода. Какие тесты использовать? Какие метрики использовать для определения качества кода? Сколько кода должно быть покрыто тестами?

              Non functional requirements Security requirements
              Требования по безопасности. Если это HTML редактор, через которые можно изменять что-то на сайте, то это может быть нечто вроде: через HTML редактор не должно быть возможности поставить shell на сервер и тп

              Appendix A: Glossary
              Приложение. Иногда в SRS пытаются вставлять описание протоколов и тд и тп. Этого делать не нужно. Однако иногда нужно таки прояснить какую то концепцию. Для этого существует этот раздел. Вставляем ссылочки на такие пояснения. Такой себе словарик.

              Appendix B: Analysis Models
              Раздел определяет какие диаграммы нужно использовать при написании SRS. Например, DFD, какие то общие диаграммы взаимодействия и работы

              Appendix C: Issues list
              Данный раздел используется для очень формальных SRS. Описывает пункты TBD(To Be Done) — что в будущем надо еще сделать, но тут не описано.

              Заключение

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

              Технология разработки программных продуктов

              Методические указания к выполнению лабораторных работ
              для студентов специальности 22.03 — Программное обеспечение
              вычислительной техники и автоматизированных систем

              Составитель Румбешт В.В., кандидат технических наук, доц.

              Рецензент Михилев В.М., кандидат технических наук, доц.

              Т38 Технология разработки программных продуктов: Методические указания. – Белгород: Изд-во БИЭИ, 2005. – 42 с.

              В методических указаниях изложены современные методы специфицирования программного обеспечения такие, как Р-технология
              (ГОСТ 19.005–85) и метод структурного анализа. Содержатся задания к выполнению лабораторных работ, посвященных изучению указанных методов.

              Предназначены для студентов специальности 22.03.

              Ó Белгородский инженерно-экономический
              институт (БИЭИ), 2005

              ОГЛАВЛЕНИЕ

              1. Спецификации и их роль в разработке программ .
              2. Основные принципы Р-технологии .
              2.1. Графические структуры Р-схем .
              2.2. Операции соединения графических структур .
              2.3. Дополнительные графические элементы Р-схем .
              2.4. Использование Р-схем в программах .
              2.5. Система инструментальной поддержки Р-технологии .
              3. Метод структурного анализа .
              3.1 Диаграммы потоков данных .
              3.2. Словарь данных .
              3.3. Способы задания спецификаций процессов .
              3.4. Диаграммы сущность–связь .
              3.5. Диаграммы переходов–состояний .
              3.6. Структурные карты .
              3.7. Система инструментальной поддержки структурного анализа .
              ЛАБОРАТОРНАЯ РАБОТА № 1. Изучение основных принципов Р-технологии .
              ЛАБОРАТОРНАЯ РАБОТА № 2. Изучение основных управляющих конструкций Р-схем .
              ЛАБОРАТОРНАЯ РАБОТА №3. Ознакомление с CASE-средством EasyCASE .
              ЛАБОРАТОРНАЯ РАБОТА №4. Разработка диаграмм потоков данных .
              ЛАБОРАТОРНАЯ РАБОТА №5. Разработка диаграмм сущность–связь .
              ЛАБОРАТОРНАЯ РАБОТА №6. Разработка диаграмм переходов–состояний .
              Лабораторная работа №7. Разработка структурных карт .
              Список Литературы . …..

              Спецификации и их роль в разработке программ

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

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

              Читайте также:  Жёсткий диск не определяется и щёлкает

              К основным свойствам спецификации можно отнести следующее.

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

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

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

              4. Спецификация должна обладать полнотой описания задачи: ничто существенное не должно быть упущено.

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

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

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

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

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

              1. Разбиение на уровни абстракций.

              2. Ограниченное число элементов, приходящихся на уровень абстракции (не более 7).

              3. Ограниченный контекст – включается лишь то, что входит в процесс, а все остальное из рассмотрения исключается.

              4. В описание включаются как сами данные, так и действия над ними.

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

              2. Основные принципы Р-технологии

              Р-технология была создана в Институте Кибернетики АН УССР. Для написания спецификаций в Р-технологии используется язык нагруженных по дугам ориентированных графов. Конкретная спецификация, созданная с помощью Р-технологии, представляет собой иерархию таких графов, называемых Р-схемами.

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

              * построение Р-схемы или иерархии Р-схем, реализующей поставленную задачу;

              * генерацию исходного текста программы по заданной Р-схеме;

              * компиляцию и компоновку загрузочного модуля программы;

              * отладку и тестирование, полученной программы;

              * генерацию Р-схемы по исходному тексту программы;

              Язык Р-схем является удобной оболочкой, в которую может быть погружен любой язык программирования от ассемблера до языка высокого уровня, и в настоящее время является составной частью Единой системы программной документации (ГОСТ 19.005–85).

              2.1. Графические структуры Р-схем

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

              Р-технология предполагает, что спецификации создаются по безбумажной схеме и весь процесс разработки выполняется с помощью средств вычислительной техники. При этом элементы Р-схем вводятся в ЭВМ и выводятся из нее с помощью алфавитно-цифровых (не графических) устройств ввода/вывода, а для изображения этих элементов применяются стандартные алфавитно-цифровые символы: “o”, “-” , “=“, “>“, “

              Не нашли то, что искали? Воспользуйтесь поиском:

              Лучшие изречения: На стипендию можно купить что-нибудь, но не больше. 9384 — | 7436 — или читать все.

              Ссылка на основную публикацию
              Снять пароль с роутера tp link
              Домашняя беспроводная сеть Wi-Fi должна быть защищена паролем. Но ведь бывают разные случаи, скажете вы. Например, вы хотите пригласить друзей...
              Скопировать контакты с андроид на компьютер
              Мы уже рассказывали о том, как скопировать контакты со смартфона на смартфон. Но иногда проще перебросить контактную книгу на компьютер....
              Скопировать строку таблицы значений 1с в другую
              Не претендуя на полноту описания функций и методов работы с таблицей значений 1с привожу некоторые аспекты, которые в своё время...
              Снять пароль с макроса excel
              Здравствуйте, друзья! Последние дни бился над такой задачей: Имеется файл .xls, в нем макрос на VBA, защищенный паролем. Файл создается...
              Adblock detector