Спецификация — это описание разрабатываемой/разработанной части системы. Документ создают на этапе проработки задач, чтобы адаптировать требования бизнеса под системный язык и передать команде разработки.
В спецификацию включают описание архитектуры, интерфейса, отдельных микросервисов, данные для тестирования, нефункциональные требования и прочее. Обычно спецификации создают системные аналитики и технические писатели, в редких случаях — продвинутые бизнес-аналитики. Как правило, её составляют на странице confluence, в swagger или в отдельном word-документе.
Кому нужна спецификация?
- Системный аналитик создаёт спецификацию, чтобы адаптировать требования бизнеса для команды разработки и описывать процесс создания системы.
- Бизнес-аналитик использует спецификацию, чтобы обозначить требования бизнеса и сравнить их с итоговом работы. А еще он исследует документы других команд, чтобы изучить готовые решения для нового или дорабатываемого процесса.
- Программистам спецификация позволяет извлечь информацию обо всей логике планируемой разработки, чтобы понять задачу: поля, запросы, форматирование и преобразования, обработку ошибок, коды систем и прочее.
- Тестировщикам спецификация позволяет определить логику работы, чтобы просчитать все возможные сценарии допущения ошибки.
- Сопровождение просит спецификацию, чтобы в случае возникновения ЧП оперативно локализовать проблему.
Я выявил для себя два подхода ведения документации: один назовем «все по полочкам», а второй — «история создания решения».
Спецификация
Подход «все по полочкам»
Первый способ подразумевает строго повторяющейся шаблон спецификации. Например, при создании нового модуля в confluence используется шаблонный набор страниц: «Описание экранных форм», «Описание микросервисов», «Архитектура», «Интеграции», «Чек-лист внедрения» и подобные.
На наших проектах это выглядело так:
Главная особенность подхода — подробное описание. Если это экранные формы, то текст содержит название компонента, его тип, источник данных, преобразование, маску, обязательность. Спецификация на микросервисы содержит сценарии вызовов, «маппинг» полей, а обработку ошибок вводят, используя макрос swagger.
Подход «все по полочкам» также позволяет описать доработку старого модуля. Достаточно открыть статьи и внести изменения. Корректировки, которые внедряют, помечают красным цветом, а после завершения работы снимают выделения.
Плюсы подхода
Описание кажется исчерпывающим. Когда знаешь, что где лежит, без проблем отслеживаешь весь путь запроса: от извлечения данных из базы до окрашивания полученного значения в интерфейсе. Подход унифицированный, что ускоряет наполнение разделов, и все участники смогут найти требуемую информацию.
Недостатки
Подход задвигает на второй план бизнес-требования к разработке. Конечно, у нас есть страница с описанием процесса и пожеланий. Однако она выглядит сильно обособлено от остальных и не гарантирует выполнение задач. Проблему решает усложнение страницы: установка якорей, добавление ссылки на задачи в Jira, дублирование части логики на страницу с требованиями.
В чем разница между качеством и корректностью программы
Второй недостаток — при изменении требований проблематично отследить, когда и почему произошли перемены. Мы увидим только последние задачи.
Подход «история создания решения»
Второй способ более анархичный. Создаётся центральная страница, в которой идет «повествование», как прорабатывали и создавали решение. На первом этапе её наполняет бизнес-аналитик. Он описывает пользовательский сценарий, как часто операция выполняется, планируемую логику работы разработки, роли в приложении и прочее. После этого рисуют макет интерфейса, который прикладывают к странице.
Далее в дело вступает системный аналитик. Он определяет набор микросервисов, пробегается по статье и проставляет в таблице атрибутов поля сервисов и логику форматирования. Делает ссылки на другие страницы, где добавляют подробные описания.
Задачи на разработку также добавляют в статью, чтобы понимать, в какой части сделан тот или иной функционал. Для тестировщиков в документ вносят информацию по поиску тестовых данных, которые понадобятся.
Оглавление такой страницы выглядит примерно так:
В итоге статья выглядит как большая история требований бизнеса с множественными вкраплениями системных вещей. Сравнить её можно с длинным и пёстрым полотном:
Плюсы подхода
Метод решает главную проблему «все по полочкам». Мы открываем статью и видим, как и когда решали конкретную проблему бизнеса. По опыту отмечу, подход удобен тестировщикам: он позволяет понять контекст. А еще комфортен бизнес-аналитикам: коллеги спокойны, что их требования услышаны.
Недостатки
В подходе «история создания решения» смещен фокус с разработки. Если в задаче сделать ссылку на спецификацию, программисту потребуется прочитать весь документ, чтобы понять, что от него требуется. При этом ему достаточно, чтобы конкретно написали, что важно добавить и куда. Конечно, коллеги сразу указывают пожелания в письме, но так теряется один из смыслов спецификации — постановка задачи разработчику.
Второй недостаток — в одной статье невозможно описать всю логику поведения приложения, запросы, стенды, балансировщики и прочее. Поэтому спецификация всегда будет иметь некоторую неоднозначность и неопределенность, и все детали уточняются именно при анализе кода приложения. Ну и размер статьи стремится к плюс бесконечности.
Сравнение двух подходов
Вместо вывода
Мне, как системному аналитику, больше нравится первый метод. Он позволяет быстро найти запрос. Плюс всегда знаешь, где что лежит.
Если вы только выбираете подход, то продумайте, на кого вы больше ориентируетесь: бизнес или IT-команда.
Источник: outlines.tech
1. Спецификации и их роль в разработке программ
Спецификация программы – это описание задачи, которую решает программа. Слово «спецификация» буквально означает «описание» или «получение описания», а «специфицировать» значит «описывать».
В отличие от компьютерной программы спецификация обращена, прежде всего, к человеку и представляет собой описание в терминах, характерных для самой задачи, а не для ее реализации. Спецификация – это задание для программиста, написанное постановщиком задачи. Она служит основой дальнейшей детализации и разработки. С другой стороны, требования к программе, отраженные в техническом задании, также обращены к человеку. Однако спецификация более формально, чем требования, описывает решаемую задачу.
К основным свойствам спецификации можно отнести следующее.
- Спецификация не должна содержать деталей реализации. В отличие от программы она «говорит», что надо сделать, а не как это делать.
- Спецификация должна обладать формальностью (однозначностью прочтения, точностью), причем диапазон требований здесь очень широк: от полностью формализованного описания до слегка формализованного. Описание на «естественном языке» обычно считается неудовлетворительным, поскольку оно слишком неформально.
- Спецификация должна быть понятной (ясной, читабельной). В этом заключается еще одно отличие от программы. В общем случае спецификация должна быть более понятным описанием задачи, чем программа, так как краткость не всегда содействует ясности и понятности.
- Спецификация должна обладать полнотой описания задачи: ничто существенное не должно быть упущено.
- Разбиение на уровни абстракций.
- Ограниченное число элементов, приходящихся на уровень абстракции (не более 7).
- Ограниченный контекст – включается лишь то, что входит в процесс, а все остальное из рассмотрения исключается.
- В описание включаются как сами данные, так и действия над ними.
Источник: studfile.net
Спецификации и их роль в разработке программ
Составитель Румбешт В.В., кандидат технических наук, доц.
Рецензент Михилев В.М., кандидат технических наук, доц.
Т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”, “-”, “=“, “>“, “
Вершинам Р- схемы соответствуют некоторые состояния вычисленного процесса, а дугам – переходы из одного состояния в другое. Дуги
Р- схем могут содержать текстовые нагрузки. Обычно запись над дугой определяет условие прохождения по этой дуге, а запись под дугой – действие, выполняемое при этом прохождении. Условие – это некоторое выражение, содержащее предикаты и логические операции. Действие – это последовательность операторов присваивания, процедур или функций, которые записываются столбиком под соответствующей дугой.
Примеры фрагментов Р- схем, иллюстрирующие различные варианты текстовой нагрузки дуги, приведены на рис. 1. Как видно из этих примеров, и условие и действие на дуге могут отсутствовать.
Рис. 1. Варианты текстовой нагрузки дуги в Р- схеме
Для изображения переходов между состояниями (вершинами) в
Р- схемах разрешается использовать только горизонтальные линии со стрелками (дуги). Вертикальные линии стрелок не содержат и используются только для соединения дуг, выходящих из одной вершины или входящих в одну вершину.
Дуга, изображенная двумя горизонтальными линиями, соответствует отождествлению соединяемых ею вершин. Такая дуга в Р- схемах называется технологической. Петли в Р- схемах изображаются, как показано на рис. 2.
Рис. 2. Изображение петель на Р–схемах
Построение Р- схемы основывается на комбинации двух структур, называемых базовой и специальной. Структуры Р- схем представлены на
рис. 3.
Рис. 3. Типовые структуры Р- схем:
а – базовая структура; б – специальная структура
На рис. 3 символами: Y1, Y2, …, YN, YN1, YN2, …, YNM обозначены условия прохождения по дуге; символами: D1, D2,…, DN, DN1,
DN2, …, DNM – действия, выполняемые, если соответствующие условия истинны; символом Y – условие повторения вида “i = 1 step 1 until K”, “i = 1 … K” и т.п. Условия Y, Y1, Y2,…, YNM или действия D1, D2, …, DNM могут отсутствовать на дугах, обозначая тем самым безусловный переход, или переход без выполнения действия.
Базовая структура выполняется по следующему принципу. Если процесс находится в состоянии, соответствующем левой вершине, то анализируют прямые дуги (слева направо).
Первая дуга, у которой условие перехода оказывается истинным, выполняется, т.е. выполняют указанные под ней действия, после чего осуществляется переход по дуге Р- схемы в следующее состояние вычислительного процесса (правая вершина). Дуга с отсутствующим условием просматривается последней независимо от ее места положения. После перехода в правую вершину аналогично просматриваются обратные дуги. Если какое-либо условие перехода по обратной дуге истинно, то выполняются соответствующие действия и осуществляется переход в левую вершину.
Специальная структура выполняется следующим образом. Если на технологической дуге ничего не записано, то просматриваются подряд сверху вниз все дуги, выходящие из левой вершины. Первая дуга, у которой условие оказалось истинным, выполняется, после чего осуществляется переход по соответствующей дуге к правой вершине, а далее по технологической дуге к левой вершине.
Затем процесс анализа условий повторяется. Выполнение структуры заканчивается, когда все условия на дугах ложны. В этом случае происходит переход по технологической дуге от левой вершины к правой. Если на технологической дуге записано некоторое условие, то описанный процесс многократного выполнения расположенных ниже дуг производится в соответствии с записью этого условия.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru