Спецификация программы: Спецификации и их роль в разработке программ — Студопедия

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

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

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

Белгород 2005

УДК 681.3.06(075)

ББК 32.973–0.18.2

Т38

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

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

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

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

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

УДК 681.3.06(075)

ББК 32.973–0.18.2

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

ОГЛАВЛЕНИЕ

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

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

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

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

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 могут отсутствовать на дугах, обозначая тем самым безусловный переход, или переход без выполнения действия.

Базовая структура выполняется по следующему принципу. Если процесс находится в состоянии, соответствующем левой вершине, то анализируют прямые дуги (слева направо). Первая дуга, у которой условие перехода оказывается истинным, выполняется, т.е. выполняют указанные под ней действия, после чего осуществляется переход по дуге Р-схемы в следующее состояние вычислительного процесса (правая вершина). Дуга с отсутствующим условием просматривается последней независимо от ее места положения. После перехода в правую вершину аналогично просматриваются обратные дуги. Если какое-либо условие перехода по обратной дуге истинно, то выполняются соответствующие действия и осуществляется переход в левую вершину.

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

Спецификация программы

Спецификация программы

Спецификация программы

1. Постановка задачи.
2. Таблица данных.
3. Входная форма.
4. Выходная форма.
5. Аномалии.
6. Тестовые примеры.
7. Метод.
8. Алгоритм.
9. Программа.

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

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

Классы данных:

• входные – то, что задано;
• выходные – то, что нужно получить;
• промежуточные – это данные, которые не относятся к первым двум классам, но нужны для решения задачи. Не всегда можно сразу понять, какие промежуточные переменные потребуются при решении задачи, но к этому пункту можно будет вернуться в ходе разработки алгоритма.

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

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

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

Тип переменной определяет, какие значения могут в ней храниться, размер переменной, допустимые операции.

Структура переменной:

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

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

Формат описывает представление данных, например, может быть задано минимальное и/или максимальное количество символов в представлении числа или строки, количество знаков после запятой для вещественного числа и т.п. Формат обычно задаётся для выходных данных.

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

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

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

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

Тестовые примеры – это наборы исходных данных, с помощью которых определяется правильность работы программы. Тестовые примеры очень важны для разработки программы. Чем больше тестовых примеров вы используете, тем больше вероятность, что ваша программа написана корректно.

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

Рассмотрим пример – найти сумму положительных элементов массива. Метод будет следующим – перебираем все элементы массива, и, если очередной элемент массива положителен, прибавляем его в общую сумму (переменную, которую предварительно необходимо обнулить). В данном случае очевидно, что перебор осуществляется с помощью цикла, а предложение «если …» соответствует управляющей структуре «условный блок». Таким образом, подробное словесное описание метода решения задачи приводит нас к алгоритму и программной реализации.

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

Свойства алгоритма

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

Рассмотрим свойства алгоритма на примере алгоритма перехода улицы:

1. посмотреть налево;
2. если машин нет, то дойти до середины улицы и остановиться, иначе подождать и вернуться к шагу 1;
3. посмотреть направо;
4. если машин нет, то перейти улицу, иначе подождать и вернуться к шагу 3.

Данный алгоритм обладает следующими свойствами:

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

Данный алгоритм не обладает следующими свойствами:

• результативность – если машин окажется слишком много, исполнитель не сможет выполнить алгоритм до конца.

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

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

Спецификация программы — это… Что такое Спецификация программы?



Спецификация программы

49. Спецификация программы

Specification

Словарь-справочник терминов нормативно-технической документации.
academic.ru.
2015.

• Спецификация оборудования, изделий и материалов
• спецификация проекта

Смотреть что такое «Спецификация программы» в других словарях:

• спецификация программы — programos specifikacija statusas T sritis automatika atitikmenys: angl. program specification vok. Programmbeschreibung, f; Programmkenndaten; Programmspezifikation, f rus. спецификация программы, f pranc. spécification du programme, f …   Automatikos terminų žodynas

• спецификация — 3.7.3 спецификация (specification): Документ (3.7.2), устанавливающий требования (3.1.2). Примечание Спецификации могут относиться к деятельности (например, процедурный документ, спецификация на процесс или спецификация на испытание) или… …   Словарь-справочник терминов нормативно-технической документации

• Спецификация программного обеспечения — Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS)  законченное описание поведения программы, которую требуется разработать. Включает ряд пользовательских сценариев (англ. use… …   Википедия

• Функциональная спецификация — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен …   Википедия

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

• РД ЭО 1.1.2.25.0705-2006: Техническое обслуживание и ремонт систем и оборудования атомных станций. Документы программы и регламента. Виды и комплектность. Требования к содержанию и оформлению — Терминология РД ЭО 1.1.2.25.0705 2006: Техническое обслуживание и ремонт систем и оборудования атомных станций. Документы программы и регламента. Виды и комплектность. Требования к содержанию и оформлению: 7.6.1 ВД применяются в комплектах… …   Словарь-справочник терминов нормативно-технической документации

• ГОСТ 19781-90: Обеспечение систем обработки информации программное. Термины и определения — Терминология ГОСТ 19781 90: Обеспечение систем обработки информации программное. Термины и определения оригинал документа: 9. Абсолютная программа Non relocatable program Программа на машинном языке, выполнение которой зависит от ее… …   Словарь-справочник терминов нормативно-технической документации

• Слабейшее предусловие — Преобразователи предикатов расширение логики Флойда Хоара, сделанное Э. Дейкстрой. Впервые появившись в [1][1], с помощью этого метода определяется семантика императивного программирования и соответствующего языка. В нём каждой команде языка… …   Википедия

• Programmbeschreibung — programos specifikacija statusas T sritis automatika atitikmenys: angl. program specification vok. Programmbeschreibung, f; Programmkenndaten; Programmspezifikation, f rus. спецификация программы, f pranc. spécification du programme, f …   Automatikos terminų žodynas

• Programmkenndaten — programos specifikacija statusas T sritis automatika atitikmenys: angl. program specification vok. Programmbeschreibung, f; Programmkenndaten; Programmspezifikation, f rus. спецификация программы, f pranc. spécification du programme, f …   Automatikos terminų žodynas

Визуальные спецификации / Хабр

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

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

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

В жопу спецификации!

И типичное описание требования в таких проектах выглядит так:

Как пользователь

Я хочу добавить новую задачу быстро

Чтобы сэкономить время и не потерять контекст

Что удивительно, такой подход работает. В определенных случаях. Необходимо выполнение всех условий ниже:

• команда сидит в одной комнате
• есть 24×5 доступ к управляющему продуктом
• в команде нет ни одного тестировщика
• дизайнеры умеют придумывать решения любой проблемы за 1 рабочий день

Если хотя бы одно из условий не выполняется, то команда имеет серьезные проблемы.

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

Спецификации и программисты

Многие программисты не любят спецификации. Введем определение, пусть это будут “Программисты класса 1”. Они твердо знают, как система должна работать, на какие сценарии можно выдавать сообщения “Unknown error” или “You can’t do that” и где нужно срезать углы, чтобы меньше возиться с неинтересными вещами.

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

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

Распределение программистов по типам. Большинство нормально относится к спецификациям.

Программисты класса 2 читают спецификацию от корки до корки, методично ее переваривают и задают убийственно точные вопросы.

Для программистов класса 2 можно создавать любые спецификации — они проглотят все. Программистам класса 1 можно показывать только картинки, снабженные короткими, ясными надписями без сложных слов. Еще лучше им показать мультфильм. Я хотел сказать — анимацию.

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

Спецификации и тестировщики

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

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

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

Свойства спецификаций

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

(Не)полнота

Согласно Гёделю, нет никакого смысла стремиться к полной спецификации. Любая полная спецификация противоречива. Так что надо смириться с тем, что любая спецификация будет неполна. Максимум, на что можно надеяться, это на непротиворечивость.

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

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

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

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

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

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

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

Мозгодрочка

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

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

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

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

Размер

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

Может показаться, что размер коррелирует (черт!) с полнотой. Однако, наполнять спецификацию водой — явно не самая хорошая идея. Наполняйте ее смыслом и жизнью.

Методы донесения идей

Какие вообще бывают методы объяснения своих мыслей? Давайте пройдемся по ним.

Псевдо-Нарративные

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

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

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

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

Пример убедительного использования списков.

Такое использование текста портит карму. Не делайте так.

Нарративные

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

История про Васю и Батч DnD

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

Счастливый конец

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

Несчастливый конец

Вася отпускает карточку и вдруг видит тревожное красное сообщение “У тебя, дружище, нет прав на изменение итерации для юзер стори. Попроси админа, может даст”. Карточки прыгают обратно в левую колонку и остаются желтыми, чтобы Вася мог сполна почувствовать собственное ничтожество по сравнению разработчиками системы.

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

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

Может быть, нарративная спецификация недостаточно формальна. Но если ее дополнить правильными картинками, то все будет хорошо.

BDD

Behavior-Driven Development имеет довольно любопытный формат для описания требований. Фактически, мы описываем критерии приемки фичи. Если все критерии проходят, фича считается готовой. Вот один из примеров спецификации в формате BDD:

As a Scrum Master I want to see Release BD Chart drawn by weeks

As a Scrum Master

I want to see Release BD Chart drawn by weeks

When Iterations practice is disabled

So that I can benefit from BD chart

Given any development process

When I turn off Iterations practice in Admin -> Process -> Edit

And navigate to Release BD chart

Then iteration velocity replaced by weekly velocity

And Chart end date is the same as Release end date

And BD chart drawn by weeks instead of iterations

And Chart Start Date is the same as Release Start Date

Что же хорошего и плохого в таком подходе? Из хорошего можно выделить единый формат. К нему привыкаешь, и после нескольких недель уже как-то сразу начинаешь писать спецификацию в таком формате, не особенно включая мозг. Есть / Сделали / Получили — четкий формат реакции на любое действие пользователя.

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

Минусов тоже вполне достаточно. Во-первых, все, что хорошо транслируется в автоматические тесты, обычно плохо транслируется в человеческий мозг. Спецификации в первую очередь пишутся для людей, а не для тестов. Воспринимать формат BDD достаточно тяжело. Особенно уныло смотрится спек из десятка сценариев. Ну ничем не лучше списка или таблицы, а зачастую и хуже, потому что в нем присутствует очень много повторений Given, When, Then. Эти повторения вносят ненужный шум, затрудняя восприятие полезных сигналов.

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

При использовании BDD практически невозможно охватить сразу всю фичу целиком.

Наброски интерфейса

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

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

Набросок системы отчетов в Targetprocess 3.

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

Набросок разрешенных назначений задач на людей в зависимости от роли, проекта и команды в Targetprocess 3

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

Набросок таймлайнов в Targetprocess 3.

Я лично скетчи очень люблю.

Детальный дизайн

С дизайном все просто — он должен быть готов до стадии разработки. Не стоит надеяться, что дизайнер сможет за пару дней склепать что-то такое, за что ему самому будет не стыдно. Дизайнерам нужно время. Обычно много. Дизайн нужно начинать делать задолго до того, как фича попадет в разработку.

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

Готовый дизайн таймланов в Targetprocess 3

Итак, законченный дизайн должен быть непременным атрибутом любой спецификации. Может ли дизайн заменить всю спецификацию? К сожалению, нет. Обычно в дизайне не показаны все состояния системы, не описаны потоки взаимодействий, не проработаны все сценарии. Дизайн статичен. А нам нужна динамика. Можно и в дизайне показывать динамику:

Три варианта изменения карточки требования с течением времени

Но это долго и сложно. Лишь избранные способны так скрупулезно прорабатывать варианты.

Раскадровки / Storyboards

Раскадровки любят режиссеры. В общем-то это просто набор отдельных ключевых кадров какой-то сцены.

Типичная раскадровка к непонятному фильму.

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

Типичная быстрая раскадровка.

В нашей индустрии раскадровка — это набор отдельных состояний системы.

Раскадровки довольно компактны и позволяют понять, какие вообще состояния есть. Отличные раскадровки еще и показывают, как в эти состояния переходить.

Раскадровка быстрого добавления задач в Targetprocess 3 с альтернативным сценарием.

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

Потоки / Flows

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

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

Рисовать диаграммы потоков мне нравится ничуть не меньше, чем скетчи интерфейса.

Поток контекстного редактирования в Targetprocess 3.

Animation / gifs

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

Но все же раскадровки можно анимировать! Тогда получается крайне наглядная штука, которая позволяет представить, как все это будет работать.

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

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

Изменения в прогрессе карточки-требования с течением времени в Targetprocess 3.

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

Быстрое редактирование данных в списках Targetprocess 3

Бумажные прототипы

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

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

Бумажный набор можно положить в рюкзак и отправиться на поиски непуганных пользователей, которые за простой латэ в старбаксе оценят ваш прототип и откроют вам глубины своей… оригинальности.

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

Бумажное прототипирование iPad приложения (которое мы начали делать, но не доделали).

Хороший пример бумажного прототипирования формы регистрации

Интерактивные спеки

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

Единственную интерактивную спецификацию, которую я видел в жизни, сделал Олег Серяга.

Интерактивная спецификация кастомизации карточек в Targetprocess 3. Кликабельно.

Тут мы можем переключать размеры карточек, типы карточек и быстро переходить к нужному элементу с описанием важных свойств.

Стоит ли делать интерактивные спецификации? Скорее всего, нет. Для прототипа их недостаточно, и есть более простые способы донести всю информацию не менее эффективно.

Живые прототипы

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

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

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

К сожалению, практически всегда в прототипах реализуют только позитивные сценарии. Главная цель прототипа — работа на прорыв, доказательство работоспособности конкретного решения. Негативные сценарии никак не влияют на качество доказательства, поэтому их оставляют в сторонке. Однако для разработчика негативные сценарии крайне важны. Если разработчики не хотят о них думать, то тестировщики обожают. В результате придется терпеливо выяснять нюансы поведения системы, мучительно фиксить баги и править сообщения “You can’t do that!”.

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

Первый прототип Targetprocess 3, сделанный для проверки концепции. Показывался клиентам и вызывал общее одобрение. Кликабельно, но работает не все, что видно.

Через прототип очень нудно и долго придется выяснять требования типа “а какая же максимальная длина у этого поля?”. Мало того, что разработчику вообще надо вспомнить, что у поля есть длина, так еще и тыкать в прототип мышкой и смотреть код в тщетной попытке найти там что-то хорошее.

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

Еще один минус — время. Прототипы делать долго. Вообще есть два типа разработчиков: быстрые и медленные. Быстрым можно доверять разработку прототипов, медленным — ни в коем случае. Качество кода в прототипе, как вы понимаете, может быть произвольно плохим. Главное, чтобы работали нужные сценарии. И вроде бы КО похлопывает сейчас меня сзади по плечу, но я сам совершал такие ошибки в прошлом.

Спецификация = визуальное объяснение

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

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

Все методы донесения идей в одном флаконе.

Желательно не использовать методы с низкой полезностью, такие как BDD и псевдо-нарративные. Хорошо работают скетчи, нарративы, диаграммы потоков, раскадровка, бумажные прототипы и готовый дизайн. На анимацию и живые прототипы стоит тратить время только в том случае, если его реально много.

Вступайте на путь добра, друзья! Создавайте понятные визуальные спецификации, которые рассказывают истории на простом языке.

P.S. У меня в запасе осталось еще штук 20 красивых картинок, но статья и так огромная, так что извините.

1.3. Внешняя спецификация программы

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

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

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

Внешняя
спецификация прикладной программы
включает:

• назначение
  программы;

• описание
  входных данных;

• описание
  формы представления результатов при
  допустимых входных данных;

• перечисление
  аномалий во входных данных и реакций
  программы на них.

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

Аномалии
входных данных — это различные нарушения
условий допустимости входных данных.
К аномалиям относят такие значения
входных данных, для которых нельзя
применять реализованный в программе
метод решения. Так, для описанного выше
метода Эвклида, входные данные не могут
быть равны нулю, так что аномалией можно
считать случай, когда либо первое, либо
второе входное число равно нулю.

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

Внешняя
спецификация:

Назначение:

Решение
квадратного уравнения

Входн.
данные:

a,
b, c — вещественные числа

Вых.
данные:

КВАДРАТНОЕ
УРАВНЕНИЕ

<a>*X^2+<b>*X+<c>=0

<
результаты-решения >

где
результаты-решения:

<
КОРНИ: X1 = <x1> X2 = <x2> >

где
х1, y1 — вещественные числа.

Аномалии
входных данных:

(1)
при (a=0)

Недопустимо:
а = 0

(2)
при (b²-4ac)
< 0

Вырождено:
b^2-4ac < 0

Программа
может быть хорошей и плохой.

В
случае плохой программымогут иметь
место:

• непонятный
  текст выходных данных;

• аварийное
  завершение ее при недопустимых входных
  данных. (При этом часто отсутствуют
  сообщения с разъяснением причины).

Прикладная
программа считается хорошей, если
выполнены следующие требования:

• текст
  выходных данных легко понимается, и в
  него включены не только результаты
  решения, но и входные данные решаемой
  задачи;

• тексты
  с выходными данными легко записываются
  и легко исправляются;

• при
  обнаружении аномалий формируется легко
  понимаемый текст с диагностикой
  выявленных ошибок в данных.

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

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

Вых.
данные: Образец:

ЭЛЕКТРИЧЕСКАЯ
ЦЕПЬ: ЭЛЕКТРИЧЕСКАЯ ЦЕПЬ:

<r1>+(<r2>||<r3>)
ом 1.0 + (1.0 || <1.0) ом

НАПРЯЖЕНИЕ:
U=<u> B НАПРЯЖЕНИЕ: U= 3.0 B

<результаты-решения>
МОЩНОСТЬ: W= 6.0 ВТ

Здесь

<r1>,<r2>,<r3>
— обозначения конкретных числовых
значений сопротивлений,

<u>
— обозначение конкретного значения
напряжения,

а
<результаты-решения> — это
составляющая выходного текста, которая
варьируется в зависимости от значений
входных данных.

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

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

Ниже
приводится конкретный пример двух
вариантов описания выходных текстов
для задачи расчета электрической цепи.

Вариант
1. Вариант 2.

Вых.
данные: Вых. данные:

<заголовок>

ЭЛЕКТРИЧЕСКАЯ ЦЕПЬ:

<входные-данные>
R1 + ( R2 || R3 ) ом

R1=<r1> R2=<r2> R3=<r3>

<результаты-решения>
НАПРЯЖЕНИЕ: U=<u> B

где
заголовок:

а) МОЩНОСТЬ: W = 6.0 ВТ

ЭЛЕКТРИЧЕСКАЯ
ЦЕПЬ:

R1
+ ( R2 || R3 ) ом

б) ЗАМЫКАНИЕ: Rобщ=0

где
входные-данные:

R1=<r1>
R2=<r2> R3=<r3> в) СОПРОТИВЛЕНИЕ
< 0

НАПРЯЖЕНИЕ:
U=<u> B

где
результаты-решения:

а)
МОЩНОСТЬ: W = 6.0 ВТ

б)
КОРОТКОЕ ЗАМЫКАНИЕ: Rобщ=0

в)
СОПРОТИВЛЕНИЕ < 0

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

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

Для
описания составляющих, которые могут
войти или не войти в текст выходных
данных, обычно применяют квадратные
скобки.

Пример.

результаты-решения:образец:

[<промежуточные-результаты>]
[ Дискриминант: D = <d>]

<требуемые-результаты>
Корни: Х1=<x1> X2=<x2>

Инструменты разработки и оформления спецификаций программы nanoCAD Механика

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

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

Среди функциональных панелей программы nanoCAD Механика есть панель “Менеджер проектов”, в которой формируется дерево спецификаций файла (рис.1).

В одном файле DWG может быть несколько сборочных единиц с несколькими спецификациями. Перед созданием выноски позиции в “Менеджере проектов” нужная сборочная единица, в которую должна попасть создаваемая позиция, должна быть отмечена флажком “включено”.

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

Для оформления сборочного чертежа и соответствующей ему спецификации в программе nanoCAD Механика используются два основных инструмента: “Редактор позиций” и “Редактор спецификаций”. Любые изменения данных в “Редакторе позиций” приводят к соответствующим изменениям в “Редакторе спецификаций” и наоборот, то есть эти инструменты полностью синхронизированы между собой.

Если выноска позиции спецификации ставится на элемент базы nanoCAD Механика, то из этого элемента в выноску автоматически попадают раздел спецификации и наименование (рис. 2). Например, при установке выноски позиции на авиационный болт по ОСТ 1 31148-80 с резьбой М6 и длиной 24 мм, цинкованный, такой болтон автоматически попадает в раздел спецификации “Стандартные изделия”, а в его наименовании сформируется запись “Болт 6-24-Ц-ОСТ 1 31148-80” в соответствии с требованиями стандарта.  При изменении параметров болта, например, диаметра или длины, наименование в выноске позиции автоматически изменится соответствующим образом. Поля данных позиции спецификации, которые не заполняются автоматически, можно заполнять вручную.

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

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

При простановке выноски на болтовое соединение все детали крепежа попадают в эту выноску, и получается выноска “этажеркой”. Любую другую выноску также можно сделать “этажеркой”, для этого достаточно добавить в “Редакторе позиций” еще одну запись в дополнение к уже имеющейся записи.

Для создания сложных выносок спецификации можно использовать номера позиций в универсальных выносках nanoCAD Механика. Так формируются выноски позиций спецификации с несколькими линиями-выносками, выноски позиций спецификации с заменой, выноски позиций спецификации с дополнительным текстом, появляется возможность использовать команду “Перецепить линию-выноску” и т.д.

Инструмент “Редактор спецификации” (рис. 3) автоматически собирает информацию со всех выносок позиций спецификации файла. При помощи этого инструмента можно настраивать спецификацию, автоматически или вручную сортировать записи, расставлять номера позиций, в том числе с резервированием номеров позиций, а также выводить итоговую спецификацию на чертеж или в файл табличного редактора Microsoft Excel.

В актуальной на сегодняшний день 9.0 версии nanoCAD Механика доступны шесть шаблонов:

• встраиваемая в чертеж спецификация;
• простая спецификация;
• плазовая спецификация;
• спецификация групповая тип А;
• спецификация групповая тип Б;
• электромонтажная спецификация.

Форму и порядок заполнения спецификаций изделий всех отраслей промышленности определяет ГОСТ 2.108-68. Согласно п. 20 этого стандарта допускается совмещение спецификации со сборочным чертежом. Если нужно такое совмещение, то следует использовать шаблон спецификации “Встраиваемая в чертеж”.

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

Плазовые спецификации оформляются на формах 2 и 2а ГОСТ 2.106-96. Если у детали или стандартного изделия из базы есть свойства “Масса” и “Материал”, то эти свойства автоматически попадут в соответствующие столбцы спецификации.

Групповые спецификации типа А и Б оформляются в соответствии с требованиями ГОСТ 2.113-75. Для управления исполнениями в выносках позиций спецификации есть дополнительный столбец. Для создания дополнительного исполнения уже существующего элемента спецификации с выноской позиции следует создать новую выноску позиции., После этого в ее ее “Редакторе позиций” нажать кнопку “Добавить позицию/исполнение” и из предложенного списка выбрать существующий элемент спецификации. Если групповая спецификация типа Б содержит более 10 исполнений, то на первом ее листе автоматически сформируется надпись вида:

«Исполнения         10…19 — см. листы 4, 5,

20…29 — см. листы 6…8»

Электромонтажные спецификации оформляются в соответствии с ГОСТ 2.413-72. У таких спецификаций после всех разделов спецификации на новом листе делается заголовок «Устанавливают по ХХХХ.ХХХХХХ.ХХХМЭ» или «Устанавливают по ХХХХ.ХХХХХХ.ХХХТБ» или «Устанавливают при электромонтаже» и после него опять могут идти разделы “Сборочные единицы”, “Детали”, “Стандартные изделия” и т.д. Нумерация позиций при этом сквозная.

Существующие шаблоны спецификации можно менять, а также на их основе можно создавать пользовательские шаблоны спецификации. Такие изменения осуществляются при помощи кнопки “Настройки спецификации” в “Редакторе спецификаций” (рис. 4).

Вкладка настроек “Документ” задает способ вывода данных в таблицу спецификации. Таких способов на момент написания статьи реализовано четыре. Для встроенной в чертеж, простой и плазовой спецификаций используется простой способ вывода данных в один блок разделов спецификации. Для групповых спецификаций типа А более 3-х исполнений данные выводятся последовательно сначала в основной блок разделов спецификации, затем в блоки разделов следующих последовательно друг за другом исполнений. Групповой тип Б и групповой тип А не более 3-х исполнений (Форма 5 ГОСТ 2.113-75) выводятся одним блоком разделов, но количество при этом попадает в разные столбцы. Для электромонтажной спецификации сначала выводятся данные основного блока разделов спецификации, а затем данные дополнительного.

Вкладка настроек “Разделы” позволяет редактировать перечень разделов спецификации и их порядок. Если у раздела нет выносок, что особенно актуально для документации групповых спецификаций типа Б, то можно менять любое количество в спецификации на пользовательский символ, обычно это символ “Х”.

Вкладка настроек “Заголовок” определяет поля, которые в выносках позиций и в редакторе спецификаций будут  доступны для редактирования.

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

Вкладка настроек “Экспорт” задает дополнительные параметры вывода спецификации в чертеж. Если данные элемента спецификации не помещаются в отведенную для них ячейку, то при включенном флажке “Переносить на следующую строку”, эти данные будут разбиваться на несколько строк, иначе произойдет сжатие текста. Здесь же есть дополнительные настройки для автоматического создания пустых строк для визуального разделения различных данных таблицы спецификации “Пропускать строку после раздела”, “Пропускать первую и последнюю строку” на каждом листе спецификации, “Пропускать при разрыве в нумерации”, “Пропускать строку после группы”. При включенной настройке “Группировать по ГОСТ” однотипные стандартные изделия в спецификации группируются согласно п. 3.17 ГОСТ 2.106-96, при этом под общим наименованием записываются только их параметры и размеры (рис. 5).

Вкладка настроек “Таблицы” задает связь шаблона спецификации с  таблицами базы nanoCAD Механика. Как первый, так и второй листы всех форм спецификаций содержатся в базе элементов, в папке “Спецификации”. Эти таблицы можно изменять, создавая на основе существующих спецификаций пользовательские. Таким образом, можно, например, настраивать шрифты, убирать любые существующие и делать любые дополнительные поля в спецификации, в том числе можно создавать поля данных, которые синхронизируются с данными выносок позиций спецификации.

В стандартах далеко не всегда однозначно указывается, каким образом следует обозначать изделие в спецификации. Так, например, в ГОСТ 8509-86 приведен пример условного обозначения равнополочного уголка. При этом в аналогичном по назначению стандарте ГОСТ 8509-93 уже нет примера обозначения уголка. Иногда может понадобиться после обозначения уголка указать его длину и т.д. Для решения подобных задач в базе nanoCAD Механика данные, которые используются в спецификации любого элемента, можно отредактировать. В таком случае правой кнопкой мыши на элементе базы вызывается выпадающий список, в котором следует выбрать “Открыть в Мастере объектов”, а далее выбрать “Скрипт”.

В скрипте элемента базы nanoCAD Механика за попадание в нужный раздел спецификации отвечает запись вида:

specPartition = “Детали”

За формирование наименования для спецификации, в том числе с использованием различных параметров элемента отвечает запись вида:

strPartName= “Шкив зубчато-ременной передачи m=”+m+“, z=”+zsh

где     m – модуль передачи;

            zsh – число зубъев.

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

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

У спецификаций nanoCAD Механика есть интеграция с полноценной PLM системой TechnologiCS. Как простая, так и групповая спецификация, может быть экспортирована из nanoCAD Механика через формат файла DBF в TechnologiCS для дальнейшей организации производства разработанного изделия (рис. 6).

При передаче спецификации в номенклатуре TechnologiCS заполняются соответствующие справочники. Так, в справочник “Документация” попадают все документы из раздела спецификации “Документация”, в справочник “Детали” попадают все детали и т.д., при этом отслеживается уникальность записей, чтобы одни и те же записи, применяемые в разных спецификациях, не дублировались. В справочник “Сборочные единицы” попадает как головная сборочная единица, так и все входящие, причем для головной сборочной единицы в программе TechnologiCS формируется соответствующая спецификация. В случае передачи групповой спецификации в справочнике “Сборочные единицы” будут сформированы как общая спецификация (со значком “*” перед обозначением), так и отдельные спецификации всех исполнений. Все данные о форматах, зонах, номерах позиций, количестве и примечаниях всех записей спецификации будут также перенесены в систему TechnologiCS. После импорта спецификации в TechnologiCS пользователи на основе такой спецификации могут уже в PLM системе формировать задания для производства и отслеживать фактический ход работ.        

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

Программа для спецификации | ProWoDoc

Варианты получения спецификации:

• простое ручное заполнение строки за строкой, ячейки за ячейкой. В продвинутом случае — на базе спецификации ранее выпущенного комплекта корректируется состав и количественные показатели;
• если в проектной организации существует база данных используемого оборудования и материалов, то к ней можно привязать возможность формирования спецификации по отдельным объектам. Данный подход обеспечивает единообразие в наименованиях позиций, а также возможность последующей обработки полученных данных, например, для формирования закупочных ведомостей или для использования в каких-либо экономических рассчетах;
• программы автоматизации проектирования позволяют формировать перечни используемого оборудования и материалов. К сожалению, обычно в рекламных целях это звучит примерно так: «Наша программа формирует спецификацию», хотя в действительности она выдаёт количество извещателей и кабеля, прокладываемого между ними, что составляет лишь небольшую часть от полной спецификации по разделу.
• хорошо, когда второй и третий из представленных выше вариантов объединены. Я видел попытки такой реализации, но не видел жизнеспособных результатов (это не означает, что их нет).

  Я в своей практике реализовывал два варианта использования базы данных оборудования предприятия:

• когда имеется настоящая база данных оборудования и программа автоматизации проектирования, в последней реализуется возможность обращаться к базе данных и формировать спецификацию, частично на основе полученных программой данных, частично путём добавления оборудования и материалов вручную из базы данных;
• когда база данных оборудования составлена на основе книги Excel, что достаточно часто распространено в практике (прайс-листы различных организаций), пользователь выбирает необходимое оборудование, выполняет двойной щелчок по какой-либо ячейке строки, и данные строки автоматически переносятся в формируемую спецификацию. Эффект состоит только в том, что не нужно выполнять копирование данных через буфер, увеличивается скорость формирования документа. Сложности работы с чужими прайсами состоят в отсутствии стандарта на их формирование.

  В конце статьи можно скачать файл «Template_specification.xls«, являющийся краткой заготовкой девятиграфной спецификации. Именно её заполняет одна из программ автоматизации формирования спецификации, приводить которую нет смысла потому, что она настроена на работу с файлами конктретного предприятия и никому больше не пригодится. Но вот вторую программу, преобразовывающую данные из Excel в таблицу Word, можно скачать в конце страницы, поскольку спецификации в формате Excel встречаются нередко.

Программа ExcelToWord

  Программа ExcelToWord предназначена для перевода данных из таблицы Excel в таблицу Word. Основная цель – перевод спецификации оборудования, изделий и материалов. Предполагается, что в Excel у Вас заполнена обыкновенная девятиграфная спецификация, шаблон которой приводится в папке с архивом для скачивания «ExcelToWord.rar«. Для того чтобы привести её к виду, позволяющему использовать её в рабочей документации, необходимо разбить её на страницы и дополнить различными надписями. Один из способов заключается в переносе данных в таблицу Word. Программа позволяет выполнить два способа переноса:

1. Если установить курсор на левую верхнюю ячейку таблицы Excel (или предназначенного для переноса диапазона ячеек) и запустить на выполнение программу переноса данных, то будут перенесены все данные из девяти столбцов. Обратите внимание: не УГОЛ ЛИСТА, а угол таблицы, которая в общем случае может быть в любом месте листа Excel, причём под шапкой, поскольку в файле WORD шапка своя: 
2. Если выделить диапазон ячеек, то в таблицу Word будут перенесены данные только из ячеек указанного диапазона. Если при этом таблица Word будет содержать меньше столбцов, чем задано в диапазоне Excel, то лишние данные будут утеряны.

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

  Для выполнения переноса данных:

• Откройте файл Excel, содержимое ячеек которого Вы хотите перенести в таблицу Word. Для проверки работы программы можно заполнить несколько строк находящегося в папке с программой файла.
• Установите курсор в левую верхнюю ячейку подлежащего переносу диапазона ячеек.
• Запустите на выполнение программу ExcelToWord (у меня кнопка запуска добавлена на панель Excel, Вы можете щёлкнуть по иконке файла «ExcelToWord.exe«). Она откроет расположенный в одной папке с файлом ExcelToWord.exe файл с именем «Шаблон спецификации.doc», пересохранит его в ту же папку, в которой находится источник данных (обрабатываемый файл Excel), и начнёт заполнять данными из ячеек Excel. Признаком конца диапазона является отсутствие данных в десяти идущих подряд строках. Поэтому визуально можно увидеть, как программа добавляет в конце работы десять пустых строк, а затем, определив, что они пустые, удаляет их.
• если в Excel несколько ячеек окажутся объединены, например, ячейки столбца 2 и 3, то программа занесёт имеющиеся в объединенной ячейке данные в графы 2 и 3 таблицы Word.

  Если Вы хотите использовать программу для переноса иных данных, преобразуйте таблицу Word в соответствии со своими задачами и попробуйте использовать программу. Если возникнут трудности, пишите.

Пробуйте, пишите отзывы 🙂

Спецификация программы | Статья о спецификации программы от The Free Dictionary

* Полная спецификация программы кредитования из бэк-офиса MARS в MARS POS позволяет избежать необходимости в последующих телефонных звонках или факсах для получения информации, которая была опущена; в тех немногих случаях, когда функциональность была изменена с момента последней редакции спецификаций программы, вся спецификация теста должна была быть быть переписанным (и спецификация программы была быстро пересмотрена). Домашняя страница сайта представляет собой снимок заявления о целях Epic CNC Training Academy и технических характеристик программы, поддерживаемых навигацией по боковой панели и ссылками на внешние ресурсы, чтобы облегчить учащимся выполнение требований приложения.По мере ускорения роста производства самолетов нового поколения производители оригинального оборудования и эксплуатанты должны иметь возможность поддерживать как новые, так и устаревшие программные спецификации для существующих самолетов, которые использовались параллельно на протяжении десятилетий. Спецификации программы Калифорнийских долговых расписок (AEC, 2004) были пересмотрены, и существует общее мнение, что некоторые из спецификаций следует пересмотреть. Успех вашей программы управления техническим обслуживанием будет зависеть от вашей способности заключать контракты на услуги с надежными поставщиками убедитесь, что требования программы соблюдаются и ваш владелец должным образом защищен.Поскольку у устаревших приложений была ограниченная документация и не было спецификаций программ, группа выполнила унаследованные приложения и задокументировала каждое функциональное требование. * Аудиторы имеют лицензию на инспекцию свежих фруктов и овощей, а также обучены методам аудита и спецификациям программ. (2) Программа представляет собой Совместная программа федерального уровня и штата, в которой BLS отвечает за спецификации программ, анализ данных и публикацию ежемесячных и квартальных выпусков новостей, а государства отвечают за сбор данных, интервью с работодателями, разработку данных и свои собственные публикации.«Это означает, что мы стремимся создать подход, который с точки зрения правонарушителя был как можно более цельным и последовательным (в терминологии, философии, спецификациях программ)», — сказал Маккарти. Моими специальностями стали преобразование данных, авторитетный контроль, стандарты MARC в их мельчайшие детали и написание спецификаций программы. Сначала эти спецификации предназначались для конкретных целей манипулирования данными, но в конце концов я создал службу обработки контроля полномочий и стал участвовать в написании спецификаций для обслуживания существующих программ, а также добавлении функций в эти программы..Спецификация программы

Википедия

В информатике формальных спецификаций представляют собой математически обоснованные методы, цель которых — помочь при реализации систем и программного обеспечения. Они используются для описания системы, анализа ее поведения и помощи в ее проектировании путем проверки ключевых свойств, представляющих интерес, с помощью строгих и эффективных инструментов рассуждения. ^{[1] [2]} Эти спецификации являются формальными в том смысле, что у них есть синтаксис, их семантика находится в пределах одного домена, и они могут использоваться для вывода полезной информации. ^[3]

Мотивация []

С каждым десятилетием компьютерные системы становятся все более мощными и, как следствие, более значимыми для общества. Из-за этого необходимы более совершенные методы для помощи в разработке и внедрении надежного программного обеспечения. Установленные инженерные дисциплины используют математический анализ в качестве основы для создания и проверки дизайна продукта. Формальные спецификации — один из таких способов достижения надежности программного обеспечения, как это было предсказано ранее.Для повышения качества кода чаще используются другие методы, такие как тестирование. ^[1]

Использует []

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

Важно отметить, что формальная спецификация — это не реализация, а, скорее, ее можно использовать для разработки реализации. Формальные спецификации описывают, что должна делать система, а не , как система должна это делать.

Хорошая спецификация должна иметь некоторые из следующих атрибутов: адекватная, внутренне согласованная, однозначная, полная, удовлетворительная, минимальная ^[3]

Хорошая спецификация должна иметь: ^[3]

• Конструктивность, управляемость и возможность развития
• Удобство использования
• Коммуникабельность
• Мощный и эффективный анализ

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

Ограничения []

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

Формальные методы разработки программного обеспечения не получили широкого распространения в промышленности.Большинство компаний не считают рентабельным применять их в своих процессах разработки программного обеспечения. ^[4] Это может быть по разным причинам, в том числе:

• Время
  • Высокие начальные затраты на запуск при низкой измеримой прибыли
• Гибкость
  • Многие софтверные компании используют гибкие методологии, ориентированные на гибкость. Формальная спецификация всей системы заранее часто воспринимается как противоположность гибкости.Тем не менее, есть некоторые исследования преимуществ использования формальных спецификаций при «гибкой» разработке ^[5]
• Сложность
  • Им требуется высокий уровень математических знаний и аналитических навыков для их понимания и эффективного применения ^[5]
  • Решением этой проблемы может быть разработка инструментов и моделей, которые позволяют реализовать эти методы, но скрывают лежащую в основе математику ^{[2] [5]}
• Ограниченный объем ^[3]
  • Они не охватывают свойства, представляющие интерес для всех заинтересованных сторон в проекте ^[3]
  • Они плохо справляются с заданием пользовательских интерфейсов и взаимодействия с пользователем ^[4]
• Не рентабельно
  • Это не совсем так, поскольку они показали рентабельность, ограничивая их использование только основными частями критических систем ^[4]

Другие ограничения: ^[3]

Парадигмы []

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

• Спецификация на основе истории ^[3]
  • Поведение на основе истории системы
  • утверждения интерпретируются с течением времени
• Спецификация на основе состояний ^[3]
  • Поведение на основе состояний системы
  • серии последовательных шагов, (например,г. финансовая операция)
  • языков, таких как Z, VDM или B, полагаются на эту парадигму ^[3]
• Спецификация на основе переходов ^[3]
  • Поведение на основе переходов из состояния в состояние системы
  • лучше всего использовать с реактивной системой
  • языка, такие как Statecharts, PROMELA, STeP-SPL, RSML или SCR, полагаются на эту парадигму ^[3]
• Функциональная спецификация ^[3]
  • определяет систему как структуру математических функций
  • OBJ, ASL, PLUSS, LARCH, HOL или PVS полагаются на эту парадигму ^[3]
• Операционная спецификация ^[3]
  • ранние языки, такие как Пейсли, GIST, сети Петри или алгебры процессов, полагаются на эту парадигму ^[3]

Помимо вышеперечисленных парадигм, существуют способы применения определенных эвристика, помогающая улучшить создание этих спецификаций.В упомянутой здесь статье лучше всего обсуждается эвристика, используемая при разработке спецификации. ^[6] Они делают это, применяя подход «разделяй и властвуй».

Программные средства []

Обозначение Z является примером ведущего языка формальных спецификаций. Другие включают язык спецификации (VDM-SL) Венского метода разработки и нотацию абстрактной машины (AMN) B-метода. В области веб-сервисов формальная спецификация часто используется для описания нефункциональных свойств ^[7] (качество обслуживания веб-сервисов). ^{a b} Hierons, R.M .; Богданов, К .; Bowen, J. P .; Cleaveland, R .; Деррик, Дж .; Дик, Дж .; Георге, М .; Harman, M .; Капур, К .; Krause, P .; Lüttgen, G .; Simons, A.JH .; Вилкомир, С. А .; Woodward, M. R .; Зедан, Х. (2009). «Использование формальных спецификаций для поддержки тестирования». Вычислительные исследования ACM . 41 (2): 1. CiteSeerX 10.1.1.144.3320. DOI: 10.1145 / 1459352.1459354.

Внешние ссылки []

.

Спецификация программы — Скачать PDF бесплатно

Ассистент врача

Ассистент врача Исследования Ассистент врача Телефон: (540) 568-8171 Веб-сайт: http: // www.jmu.edu/heathsci/paweb Временный руководитель академического отдела Д-р Паула Максвелл Директор программы магистратуры г-н Джеймс Хаммонд,

Дополнительная информация

Магистр медсестер

КОМИТЕТ ВЫПУСКНОГО ФАКУЛЬТЕТА ДОК. Нет. 1149 Утверждено 16 ноября 2009 г. РЕКОМЕНДАЦИЯ ПОДКОМИТЕТА ПО ВЫСШЕМУ КУРСУ И УЧЕБНОЙ ПРОГРАММЕ, КОМИТЕТА ПО ВЫПУСКНОЙ ПРОГРАММЕ И ФАКУЛЬТЕТУ КОЛЛЕДЖА

Дополнительная информация

УЧЕБНАЯ ПРОГРАММА.ДЛЯ B.Sc. в Сестринском

УЧЕБНАЯ ПРОГРАММА ДЛЯ B.Sc. ФАКУЛЬТЕТ МЕДИЦИНЫ, УНИВЕРСИТЕТ JAFNA 2010 1 Теория Теория Часы Часы Глава 4 СТРУКТУРА УЧЕБНОЙ ПРОГРАММЫ ДЛЯ бакалавриата Учебный план для первых

Дополнительная информация

Спецификация программы 1

Спецификация программы 1 1. Программы: Название программы Код UCAS Код GU Степень BN / Степень BN с отличием B700 M33B700 2.1 SCQF Уровень: 10 2.2 Кредиты: 460 3. Наградное учреждение: Университет Глазго

Дополнительная информация

Бакалавр сестринского дела

Программа бакалавриата по медсестринскому делу 1 Программа бакалавриата по медсестринскому делу Это четырехлетняя программа бакалавриата с полным рабочим днем. Выпускники этой программы будут подготовлены к регистрации как General

.

Дополнительная информация

Как получить степень медсестры

МАСТЕР НАУКИ Директор программы Сестринское дело Джудит Л.Папенхаузен, доктор философии, координатор по выпускным курсам и председатель Дениз М. Борен, доктор философии, доктор медицинских наук Миссия магистерской программы по сестринскому делу в Калифорнии

Дополнительная информация

Школа медсестер UConn

Сертификат школы медсестер UConn для поступления в программу медсестер (CEIN / BS) Утверждено: Департаментом высшего образования Коннектикута Советом медсестер штата Коннектикут В настоящее время мы принимаем

Дополнительная информация

Результаты программы медсестер

Миссия программы младшего медицинского персонала в Общественном колледже Томаса Нельсона — дать студентам возможность получить знания, навыки и отношения, необходимые для успешной подачи заявки на Национальный

.

Дополнительная информация

Требования к медицинскому образованию

20-10-1.Определения Используемые в разделах с 20-10-1 по 20-10-3, включая: (a) «Аккредитованная больница» означает больницу, аккредитованную Совместной комиссией по аккредитации больниц. (б) «Отдел»

Дополнительная информация

ХИРУРГИЧЕСКАЯ ТЕХНОЛОГИЯ — КОД A45740

ХИРУРГИЧЕСКАЯ ТЕХНОЛОГИЯ — КОД A45740 Учебная программа по хирургическим технологиям готовит людей к оказанию помощи в уходе за хирургическим пациентом в операционной и к работе в качестве члена хирургического отделения

Дополнительная информация

.Спецификация программы

— перевод на немецкий — примеры английский

Эти примеры могут содержать грубые слова на основании вашего поиска.

Эти примеры могут содержать разговорные слова, основанные на вашем поиске.

Строка 33 — это пример использования спецификации программы .

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

Ein System nach einem jeden der Ansprüche 1 bis 3, weiter umfassend Mittel zum Eingeben der Programmspezifikation in der Sprache der vierten Generation, welche die gewünschten Programmfunktionen darstellt.

Компьютерная программа, сгенерированная генератором (2), проверяется на наличие ошибок в верификаторе (3), в то время как транслятор (6) повторно транслирует компьютерную программу во вторую спецификацию программы , а компаратор (7) сравнивает две программы.

Ein von dem Generator (2) содержит Rechnerprogramm wird in dem Verifikator (3) auf Fehler überprüft, wobei der Translator (6) das Rechnerprogramm in eine zweite Programmspezifikation rücküberträgt und der der die Komparatikation. (7)

Сохраните спецификацию программы и вернитесь к первому экрану.

Sichern Sie dann Ihre Angaben und kehren Sie auf das Einstiegsbild zurück.

Заказывайте независимую, основанную на правилах спецификацию программы Система .

Предложите пример

Другие результаты

Использование логотипов должно соответствовать требованиям программы EMC Co-op .

В настоящее время предлагаемые изменения в спецификации программы NAID AAA Certification будут включать программу с требованиями оценки рисков HIPAA.

Используя спецификацию программы Intel Cluster Ready , Dell предлагает ряд интегрированных решений для удовлетворения различных потребностей рабочих групп и подразделений в высокопроизводительных вычислениях.

Dell bietet eine Reihe von integrierten Lösungen an, die einerseits die Spezifikationen des Intel Cluster Ready-Programms erfüllen und andererseits vielen Anforderungen von Arbeitsgruppen und Abteilungen gerecht werden.

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

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

Аппаратное обеспечение, спецификации продукта , руководства, инструкции, спецификации программы , SAP, инструкции по установке

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

Als Fachinformatiker / -in für Systemintegration pflegst und entwickelst Du Die verschiedensten IT-Komponenten unserer Systemlandschaft. Du wählst Softwarebestandteile aus, legst Programmspezifikationen fest und konzipierst funktionsgerechte und ergonomische Bedienoberflächen.

syslogd (8) теперь позволяет нескольким хостам или программам быть названными в спецификации хоста или программ в syslog.conf (5) файлы.

Из syslogd (8) ist jetzt möglich, bei der Angabe einer System- oder Programmspezifikation in der Konfigurationsdatei syslog.conf (5) mehrere Systeme or Program anzugeben.

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

System nach Anspruch 11, Welches Ferner eine Einrichtung zur Editierung und / oder Definierung von wenigstens einigen der Variablen der Programmspezifikationen enthält unter Verwendung eines Zellenformats zur Anzeige und Editierung der Variablen.

В настоящее время председателем комитета является Энджи Сингер Китинг из Reclamere. Комитет по правилам сертификации отвечает за определение и пересмотр спецификаций , приложений и процессов программы NAID AAA Certification .

Derzeit ist Angie Singer Keating von Reclamere die Vorsitzende des Ausschusses. Der Zertifizierungsregelungsausschuss ist verantwortlich für die Festlegung und Überarbeitung der NAID-AAA-Zertifizierungsspezifikationen , -anwendungen und -verfahren.

Сертификация: покупка сертифицированной системы гарантирует, что кластер спроектирован и построен в соответствии со спецификациями программы .

Zertifizierung: Mit dem Kauf eines zertifizierten Systems ist sichergestellt, dass der Cluster den Spezifikationen des Programms entspricht.

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

«Братья и сестры» 675 других программ EMH с аналогичными спецификациями

Программа маркировки Energy Star должна использовать спецификации , перечисленные в Приложении C.

Программа маркировки Energy Star должна использовать спецификации , перечисленные в Приложении C.

.