Внешняя спецификация должна детализировать только свойства, указанные или подразумеваемые в соглашении о требованиях, что защитит проект от расширения масштабов разработки. Добавление или изъятие свойств, предусмотренных в соглашении о требованиях, не допускается. [2]
Внешние спецификации отображают результаты разработки требований к программе, а также содержат все сведения, необходимые вызывающим программу модулям. [4]
Внешние спецификации должны описывать продукт с точки зрения пользователя и избегать ограничений на внутреннее устройство системы. Однако иногда бывает необходимо подсказать или сообщить какие-то идеи относительно внутреннего проектирования функции. Практиковать это следует как можно реже, но, если это необходимо, соответствующую информацию следует сообщить в этом разделе. [5]
Внешняя спецификация должна описывать продукт ПО с точки зрения пользователя и избегать ограничений внутреннего проекта. Но время от времени необходимо сообщать идеи о внутреннем проекте функции. Эта практика должна быть сведена к минимуму, но, где необходимо, этот раздел используется для сообщения информации. [6]
Проектирование и архитектура программных систем — Разработка требований. Моделирование 20.09.21
Внешние спецификации для программы в целом полностью определяются требованиями, предъявляемыми к программе. По мере проектирования программы для каждого модуля составляются внутренние спецификации. Каждая из спецификаций может быть документирована в комментариях к соответствующему модулю. Комментарии являются частью исходного текста программы для каждого модуля, таким образом составляются самодокументирующиеся программы. [7]
Предварительные внешние спецификации оцениваются теми, кто отвечает за подготовку целей, разработку архитектуры и детальное внешнее проектирование. Спецификации следует сопоставить с целями, рассматривая каждую цель и анализируя, насколько адекватно она отражена в спецификациях. [8]
Первоначальная внешняя спецификация оценивается специалистами, ответственными за цели, архитектуру системы и подробный внешний проект. Спецификации должны сверяться с целями путем рассмотрения каждой из них и последующего определения адекватности отражения цели, в спецификациях. [9]
Внешние спецификации программы полностью определяются результатами разработки требований к программе, и к их составлению приступают сразу же после того, как эти требования сформулированы, в то время как внутренние спецификации разрабатываются позже. [10]
Рецензент внешней спецификации должен считать, что будут реализованы только те свойства, которые определены в спецификации. Например, если во внешней спецификации без дополнительных оговорок написано, что параметр А может принимать любое значение в пределах от 3 до 14, то он в праве предположить, что дробные числа, такие, как 5 71, допустимы, а граничные значения 3 и 14 недопустимы. [11]
Разработчики внешних спецификаций проверяют полноту удовлетворения и аккуратность выполнения внешних спецификаций системы. Разработчики компонентов системы проверяют возможности построения предполагаемого компонента и доступность требований архитектуры системы. В связи с тем, что процесс построения архитектуры системы может выполняться параллельно с процессом внешнего проектирования, важно своевременно согласовать выходы и входы этих процессов. [12]
ruSTEP10feb22Anureev
Подготовка полных и правильных внешних спецификаций — сегодня самая ответственная задача в разработке программного обеспечения. Как мы видели на рис. 2.1 и 3.2, внешние спецификации участвуют в большем числе процессов перевода, чем любой другой проектный документ. [13]
РЗО — внешние спецификации утверждены; Р31 — составление внутренних спецификаций завершено; Р40 — начаты испытания класса А; Р41 — демонстрация изделия проведена; Р42 — приемочные испытания проведены; О10 — требуемые по проекту средства установлены; ОН — информационный листок выпуска готов к печати; О12 — информационный листок выпуска издан; О20 — изделие передано на распространение; Б01 — план выпуска документации составлен; Б02 — подготовка справочных материалов начата; Б10 — план выпуска документации утвержден; Б11 — техническое редактирование начато; Б12 — утверждение справочных материалов начато; Б20 — справочные материалы готовы к печати; Б21 — справочные материалы изданы; И01 — план испытаний составлен; И10 — план испытаний утвержден; И11 — спецификации испытаний составлены — И12 — разработка контрольных примеров начата; И13 — спецификации испытаний утверждены; ИД) — состав приемочных испытаний определен; ИЗО — начаты испытания класса В; И31 — последний цикл испытаний начат; И32 — отчет об испытаниях класса В издан; Д01 — план поддержки составлен; Д1С — план поддержки утвержден; Д11 — рекламные интервалы подготовлены; Д12 — рекламные материалы сданы в печать; Д13 — план обучения издан; Д20 — рекламные материалы распространены; Д21 — учебные пособия подготов-лены; ДЗО — обучение закончено; С10 — внесение изменений запрещено; С20 — спецификация сопровождения готова. [15]
Источник: www.ngpedia.ru
Билет №7. Внешняя спецификация задачи, ее роль в процессе разработки программы
Состав внешней спецификации, структура документа.
Внешняя спецификация программы — это полное и точное описание задачи.
Внешние спецификации программ должны включать описания состава входных и выходных данных, а также требуемых зависимостей между ними, фиксируя точный смысл поставленной задачи. Кроме того, во внешние спецификации должны входить описания структуры и формы записи входных тестов с входными данными и структуры и формы выходных текстов, включающих результаты ввода и анализа выходных данных, а также решения задач и, возможно, промежуточные результаты вычислений.
Спецификация имеет следующую структуру:
2. Входные данные:
состав (имя, смысл, тип, структура); диапазон; точность; объем; форма записи.
3. Выходные данные:
состав (имя, смысл, тип, структура); диапазон; точность; объем; выходная форма.
5. Аномалии: описание аномальных ситуаций; реакция на нее.
6. Функциональные тесты.
во-первых, служит заданием на разработку программы (из нее разработчик программы должен извлечь все, что ему нужно знать о стоящей перед ним задаче);
во-вторых, является частью соглашения между заказчиком программы и ее разработчиком, описанием задачи, которое приемлемо для заказчика, не обязательно сведущего в программировании;
в-третьих, она должна использоваться для проверки готовой программы (решает ли разработанная программа поставленную задачу).
_____________________________________________________________________________________
_____________________________________________________________________________________
Билет №8
Синтаксис и семантика языка. Состав языка программирования.
Метаязык для записи синтаксических правил.
Синтаксис и семантика языка программирования.
Синтаксис – правила построения конструкций языка.
Семантика – правила истолкования синтаксических конструкций языка.
5 уровней языка:
-выражение – правила для вычисления значения (операнды, соединенные знаком операций):
Целые, вещественные, логические, литерные.
— слова – константы и переменные
— алфавит – таблица ASCII – символы языка + ключевые слова
Метаязык — это язык для описания языка, средствами которого описываются и исследуются свойства некоторого другого, предметного (объективного) языка (пример: Backus-Naur form). Язык может являться своим же метаязыком (например, для описания русского языка можно использовать тот же русский язык).
1) Форма Бэкуса-Наура (БНФ) – язык строится с помощью рекурсии;
2) Расширенные БНФ (повторение, циклическое);
3) Синтаксические диаграммы (вложенные в блок-схему РБНФ).
_____________________________________________________________________________________
Кардиналистский и ординалистский подходы Кардиналистский (количественный подход) к анализу полезности основан на представлении о возможности измерения различных благ в условных единицах полезности.
Обзор компонентов Multisim Компоненты – это основа любой схемы, это все элементы, из которых она состоит. Multisim оперирует с двумя категориями.
Композиция из абстрактных геометрических фигур Данная композиция состоит из линий, штриховки, абстрактных геометрических форм.
Важнейшие способы обработки и анализа рядов динамики Не во всех случаях эмпирические данные рядов динамики позволяют определить тенденцию изменения явления во времени.
Метод Фольгарда (роданометрия или тиоцианатометрия) Метод Фольгарда основан на применении в качестве осадителя титрованного раствора, содержащего роданид-ионы SCN.
Потенциометрия. Потенциометрическое определение рН растворов Потенциометрия — это электрохимический метод исследования и анализа веществ, основанный на зависимости равновесного электродного потенциала Е от активности (концентрации) определяемого вещества в исследуемом растворе.
Гальванического элемента При контакте двух любых фаз на границе их раздела возникает двойной электрический слой (ДЭС), состоящий из равных по величине, но противоположных по знаку электрических зарядов.
Классификация ИС по признаку структурированности задач Так как основное назначение ИС – автоматизировать информационные процессы для решения определенных задач, то одна из основных классификаций – это классификация ИС по степени структурированности задач.
Внешняя политика России 1894- 1917 гг. Внешнюю политику Николая II и первый период его царствования определяли, по меньшей мере три важных фактора.
Оценка качества Анализ документации. Имеющийся рецепт, паспорт письменного контроля и номер лекарственной формы соответствуют друг другу. Ингредиенты совместимы, расчеты сделаны верно, паспорт письменного контроля выписан верно. Правильность упаковки и оформления.
Источник: studopedia.info
Внешняя спецификация
1. 1. Наименование и шифры ПО (полное наименование, сокращенные наименования, шифры ПО и проекта).
1. 2. Краткое описание ПО (включая сведения об авторском праве, иерархию документов, с указанием документов вышестоящих уровней).
1. 3. Результирующие компоненты ПО (оформляется в виде таблицы или другой формы и включает в себя, перечень спецификаций, другой документации и компонентов программного обеспечения).
Этот раздел содержит причины выпуска ПО с указанием различного типа заявок, планов и т. п. и носит полностью управленческий характер.
3. 1. Соглашения относительно представления материала.
3. 1. 1. Обозначения (определяются все обозначения, используемые в требованиях: например, если применяются индексы, то дается пример их использования и определяется принцип индексации).
3. 1. 2. Терминология (особенно специфическая для данного изделия).
3. 1. 3. Синтаксис (приводятся, если необходимо, синтаксические правила для дальнейшего описания требований).
3. 2. Генерируемое программное обеспечение (классифицируется как вспомогательное и порождаемое описываемым изделием).
3. 3. Системное программное обеспечение (все остальное ПО, включая ОС, утилиты, пакеты прикладных программ, которое классифицируется как основное, поскольку оно генерирует ПО предыдущего пункта).
Примечание. Причина такой расстановки пунктов состоит в том, что при правильном проектировании сверху вниз генерируемое программное обеспечение является основной целью проектирования и должно быть описано раньше, чем его генератор. Другими словами, структура генерируемых программ должна определять структуру генератора, а не наоборот. Если все ПО является основным, то в п. 3. 2. делается пометка не используется и опускаются все его подпункты. Структура подпунктов п. п. 3. 2 и 3. 3 полностью дублируется и далее для простоты используется нумерация только п. п. 3. 3.
3. 3. n. 1. Внешние ограничения.
3. 3. n. 1. 1. Стандарты (список используемых промышленных стандартов и собственных стандартов предприятия).
3. 3. n. 1. 2. Ограничения на совместимость. Необходимо рассматривать несколько аспектов совместимости:
исходный язык, машинный язык, форматы данных и сообщений, форматы отчетов, форматы листингов и т. п. Специально должна оговариваться совместимость со следующими программными изделиями:
изделиями-предшественниками (т. е. такими, которые пользователь может заменить новым изделием; если число функций при такой замене уменьшается, то следует привести обоснование этому);
изделиями-компаньонами (т. е. относящимися к той же группе средств и являющимися альтернативой);
подобными изделиями (т. е. выполняющих похожие функции в других программных изделиях); конкурирующими изделиями (других организаций).
3. 3. n. 1. 3. Программные ограничения. Описываются программное окружение разрабатываемого ПО, включая указание средств для его загрузки и запуска. Также отмечаются все действующие программные ограничения, например использование вычислений с удвоенной точностью для некоторых функций.
3. 3. n. 1. 4. Аппаратные ограничения. Приводится перечень устройств, необходимых для работы ПО (с указанием минимальной, оптимальной и максимальной конфигурации). Указываются все действующие ограничения на оборудование, например, физические характеристики терминала или требование запрещения использования звукового сигнального устройства.
3. 3. n. 2. Внешние характеристики.
Примечание. Если разрабатываемое ПО является расширением уже существующего, то описываются, главным образом, его дополнительные характеристики. В любом случае наибольшее внимание должно уделяться самым важным для конечного пользователя вопросам. Эти разделы являются основой документа и содержат полное и окончательное описание всех свойств программного изделия.
3. 3. n. 2. 1. Результаты. Описываются все выходные данные ПО с точки зрения их функционального содержания и назначения (например, файлы, сообщения, программно устанавливаемые сигналы и прерывания). При этом должны быть рассмотрены все возможные в системе носители и средства отображения информации. Указываются тип, структура, формат, объем, расположение и диапазон изменения. Для всех выходных данных, читаемых людьми (сообщения и отчеты) должны быть приведены образцы.
3. 3. n. 2. 2. Процессы обработки. Описываются операции, выполняемые ПО в целом или функциональными модулями, рассматриваемыми как черный ящик. Если обсуждение идет на уровне модулей или этапов разработки, указываются также модули или этапы, требуемые для получения определенной выходной информации. Точно определяются все возможные ошибки, потенциальные условия их возникновения и способы рестарта и восстановления. Подраздел должен описывать инициацию, преобразование данных, все варианты завершения работы (нормального и аварийного).
3. 3. n. 2. 3. Входы. Описание подобно п. 3. 3. 2. 1
3. 3. n. 3. Эргономические характеристики.
Примечание. Этот раздел описывает свойства, обеспечивающие надежность, комфорт и продуктивность работы пользователей и операторов, а также вопросы безопасности, секретности, восстанавливаемости после сбоев, мобильности ПО. Остановимся более подробно на двух подразделах: Надежность и Рабочие характеристики.
В разделе Надежность (это свойство программы понимается здесь как способность к восстановлению нормальной работы при ошибках и сбоях в работе оборудования) рассматриваются следующие вопросы:
защита данных пользователя;
степень защиты программ от ошибок, возникающих в других частях системы (например, работающих одновременно с данной программой в другой области памяти). Следует рассмотреть, как могут повлиять на работу предлагаемых программных средств такие ошибки, учитывая следующие моменты: распределение ресурсов памяти (указать, если предусмотрено обеспечение изоляции отводимых областей памяти); связь программ через общие аппаратные ресурсы.
Раздел “Рабочие характеристики” описывает основные параметры или принципы, по которым должна оцениваться эффективность работы программы, по возможности в количественном виде с указанием возможных допусков. Все параметры должны быть измеряемыми, к их числу могут относиться быстродействие, пропускная способность, скорость передачи данных, расход машинных ресурсов, время реакции (или задержки) и т. д.
3. 3. n. 4. Внутренние характеристики (этот раздел полностью расширяется в документе “Внутренняя Спецификация ”, однако частично может быть заполнен с целью полного описания соответствующих внешних свойств).
3. 4. Внутренние ограничения (здесь речь идет о тех свойствах, которые пользователю логично ожидать, но которые по тем или иным причинам будут исключены из программного изделия или потенциально оставлены на усмотрение разработчика: например, неполная взаимозаменяемость носителей, отсутствие поддержки каких-либо возможностей оборудования, и т. п. ).
4. ИСПОЛЬЗУЕМЫЕ МАТЕРИАЛЫ (в т. ч. справочные)
5. ПЕРЕДАЧА ЗАКАЗЧИКУ И ВВОД В ДЕЙСТВИЕ
Источник: helpiks.su