Скачать презентацию Спецификация на ПО Наиболее важная
Спецификация на ПО.pptx
- Количество слайдов: 61
Скачать презентацию Спецификация на ПО Наиболее важная
Скачать презентацию Спецификация на ПО Наиболее важная
Спецификация на ПО
• Наиболее важная функция спецификации – проектирование программы (design the program).
• Спецификации сокращают информационные потоки. • Без детальной спецификации невозможно составить план.
Завершенная спецификация на ПО должна отвечать следующим критериям: • должна быть в состоянии адекватно служить в качестве учебного материала для новых участников проекта, давая им достаточно информации и понимания о ходе реализации проекта, с тем чтобы они могли понимать, что говорится о дизайне на собраниях и не почувствовать себя так, как будто они "тонут", когда им впервые предложат создать или изменить исходный код. • должна служить "объективным доказательством" того, что дизайнеры и/или программисты выполняют свои обязательства по реализации функций, описанных в спецификации требований. • должна быть как можно более подробной, но в то же время не быть слишком обременительной для дизайнеров и/или разработчиков, то есть не становится слишком трудной для создания и поддержки.
• Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) — законченное описание поведения программы, которую требуется разработать. • Включает ряд пользовательских сценариев (англ. use cases), которые описывают все варианты взаимодействия между пользователями и программным обеспечением.
• Пользовательские сценарии являются средством представления функциональных требований. В дополнение к пользовательским сценариям, спецификация также содержит нефункциональные требования, которые налагают ограничения на дизайн или реализацию (такие как требования производительности, стандарты качества, или проектные ограничения).
• Методика составления спецификаций требований к программному обеспечению (IEEE-830 -1998) • В стандарте IEEE 830 содержится рекомендации к структуре и методам описания программных требований — «Recommended Practice for Software Requirements Specifications» . • http: //www. webisgroup. ru/services/programmin g/srs/ieee-830 -1998/
Функциональная спецификация: • 1. Описание внешней информационной среды, с которой будет взаимодействовать разрабатываемое программное обеспечение. • Должны быть определены все используемые каналы ввода и вывода и все информационные объекты, к которым будет применяться разрабатываемое ПС, а также существенные связи между этими информационными объектами.
Функциональная спецификация: • 2. Определение функций программного обеспечения, определенных на множестве состояний этой информационной среды. • Вводятся обозначения всех определяемых функций, специфицируются их входные данные и результаты выполнения, с указанием типов данных и заданий всех ограничений, которым должны удовлетворять эти данные и результаты. Определяется содержание каждой из этих функций.
Функциональная спецификация: • 3. Описание исключительных ситуаций, если таковые могут возникнуть при выполнении программ, и реакций на эти ситуации, которые должны обеспечить соответствующие программы. • Должны быть перечислены все существенные случаи, когда программное обеспечение не сможет нормально выполнить ту или иную свою функцию. Для каждого такого случая должна быть определена реакция программы.
• Спецификации могут быть формальными и неформальными. • Формальные спецификации имеют точно определенное значение. • Неформальные спецификации легче читать и понимать, но точное их содержание не всегда может быть установлено. • Считается, что языком спецификаций может быть язык более высокого уровня, чем тот, на котором должна быть написана программа.
Спецификации процессов • Спецификации процессов могут быть представлены в виде псевдокодов, блоксхем алгоритмов, Flow-форм, диаграмм Насей — Шнейдермана или просто краткого текстового описания.
• Схемы алгоритмов • Для изображения схем алгоритмов разработан ГОСТ 19. 701— 90
Псевдокоды • Псевдокод — формализованное текстовое описание алгоритма (текстовая нотация). В литературе были предложены несколько вариантов псевдокодов.
Flow-формы • Flow-формы представляют собой графическую нотацию описания структурных алгоритмов, которая иллюстрирует вложенность структур. Каждый символ Flow-формы имеет вид угольника и может быть вписан в любой внутренний прямоугольник любого другого символа
Flow-формы
Диаграммы Насси — Шнейдермана • Диаграммы Насси — Шнейдермана являются продолжением Flow-форм. Отличие их от Flow-форм состоит в том, что область обозначения условий изображают в виде треугольников. Это обозначение обеспечивает большую наглядность представления алгоритма.
Диаграммы Насси — Шнейдермана • При использовании псевдокодов, Flow-форм и диаграмм Насси — Шнейдермана описать неструктурный алгоритм невозможно (для неструктурных передач управления в этих нотациях просто отсутствуют условные обозначения). • По сравнению с псевдокодами Flow-формы и диаграммы Насси — Шнейдермана, являясь графическими, лучше отображают вложенность конструкций. • Общим недостатком Flow-форм и диаграмм Насси — Шнейдермана является сложность построения изображений символов, что затрудняет практическое применение этих нотаций для описания больших алгоритмов.
Словарь терминов • Словарь терминов представляет собой краткое описание основных понятий, используемых при составлении спецификаций. • Он предназначен для повышения степени понимания предметной области и исключения риска возникновения разногласий при обсуждении моделей между заказчиками и разработчиками.
Словарь терминов • Обычно описание термина в словаре выполняют по следующей схеме: • • термин; • • категория (понятие предметной области, элемент данных, условное обозначение и т. д. ); • • краткое описание.
Словарь терминов • • Пример: Термин Web-сайт Категория Интернет-программирование Описание Совокупность Web-страниц с повторяющимся дизайном, объединенных по смыслу, навигационно и физически находящихся на одном сервере.
Диаграммы переходов состояний (SDT) • SDT демонстрирует поведение разрабатываемой программной системы при получении управляющих воздействий (извне). • В диаграммах такого вида узлы соответствуют состояниям динамической системы, а дуги — переходу системы из одного состояния в другое. Узел, из которого выходит дуга, является • начальным состоянием, узел, в который дуга входит, — следующим. • Дуга помечается именем входного сигнала или события, вызывающего переход, а также сигналом или действием, сопровождающим переход.
Диаграммы переходов состояний (SDT)
Диаграммы переходов состояний (SDT)
Диаграммы переходов состояний (SDT)
Функциональные диаграммы • Функциональными называют диаграммы, в первую очередь отражающие взаимосвязи функций разрабатываемого программного обеспечения. • Они создаются на ранних этапах проектирования систем, для того чтобы помочь проектировщику выявить основные функции и составные части проектируемой системы и, по возможности, обнаружить и устранить существенные ошибки.
Функциональные диаграммы • Методология SADT представляет собой набор методов, правил и процедур, предназначенных для построения функциональной модели объекта какойлибо предметной области. • Функциональная модель SADT отображает функциональную структуру объекта, т. е. производимые им действия и связи между этими действиями.
Функциональные диаграммы Основные элементы этой методологии основываются на следующих концепциях: • • графическое представление блочного моделирования. На SADT-диаграмме функции представляются в виде блока, а интерфейсы входа-выхода — в виде дуг, соответственно • входящих в блок и выходящих из него. Интерфейсные дуги отображают взаимодействие функций друг с другом; • • строгость и точность отображения.
Функциональные диаграммы Правила SADT включают: • • уникальность меток и наименований; • • ограничение количества блоков на каждом уровне декомпозиции; • • синтаксические правила для графики; • • связность диаграмм; • • отделение организации от функции; • • разделение входов и управлений.
Функциональные диаграммы • Методология SADT может использоваться для моделирования и разработки широкого круга систем, удовлетворяющих определенным "требованиям и реализующих требуемые функции. • В уже разработанных системах методология SADT может быть использована для анализа выполняемых ими функций, а также для указания механизмов, посредством которых они • Осуществляются.
Функциональные диаграммы • Диаграммы — главные компоненты модели, все функции программной системы и интерфейсы на них представлены как блоки и дуги. • Место соединения дуги с блоком определяет тип интерфейса. • Дуга, обозначающая управление, входит в блок сверху, в то время как информация, которая подвергается обработке, представляется дугой с левой стороны блока, а результаты обработки — дугами с правой стороны. • Механизм (человек или автоматизированная система), который осуществляет операцию, представляется в виде дуги, входящей в блок снизу
Функциональные диаграммы
Функциональные диаграммы • Блоки на диаграмме размещают по «ступенчатой» схеме в соответствии с последовательностью их работы или доминированием, которое понимается как влияние, оказываемое одним блоком на другие. • В функциональных диаграммах SADT различают пять типов влияний блоков друг на друга: • • вход-выход блока подается на вход блока с меньшим доминированием, т. е. следующего; • • управление. Выход блока используется как управление для блока с меньшим доминированием, • • обратная связь по входу. Выход блока подается на вход блока с большим доминированием; • • обратная связь по управлению. Выход блока используется как управляющая информация для блока с большим доминированием; • • выход-исполнитель. Выход блока используется как механизм для другого блока.
Функциональные диаграммы
Иерархия диаграмм • Вся система представляется в виде простейшей компоненты — одного блока и дуг, представляющих собой интерфейсы с внешними по отношению к данной системе функциями. Имя блока является общим для всей системы. • Блок, который представляет систему в целом, детализируется на следующей диаграмме. Он представляется в виде нескольких блоков, соединенных интерфейсными дугами. Каждый блок детальной диаграммы представляет собой подфункцию, границы которой определены интерфейсными дугами. • Каждый из блоков детальной диаграммы может быть также детализирован на следующей в иерархии диаграмме. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы.
Иерархия диаграмм • Все диаграммы связывают друг с другом иерархической нумерацией блоков: первый уровень — АО, второй — Al, A 2 и т. п. , третий — All, A 12, А 13 и т. п. , где первые цифры — номер родительского блока, а последняя — номер конкретного блока детальной диаграммы. • Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию, причем никакие из них не могут быть опущены. То есть родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него не может быть ничего удалено. •
Иерархия диаграмм • Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы. • Последовательность операций, время их выполнения не указываются на SADT-диаграммах. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) • Функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т. Д.
• Диаграмма детализирует Функции программы. На ней показаны три блока: Меню, Сортировка, Вывод результата. Для каждого блока определены исходные данные, управляющие воздействия и результаты. На детализирующей диаграмме используются следующие обозначения: • 11 — размер массива; • 12 — массив; • С 1 — выбор метода; • R 1 — вывод описания метода; • R 2 — отсортированный массив.
Диаграммы потоков данных (DFD) • Такая диаграмма состоит из трех типов узлов: узлов обработки данных, узлов хранения данных и внешних узлов, представляющих внешние по отношению к используемой диаграмме источники или потребители данных. • Дуги в диаграмме соответствуют потокам данных, передаваемых от узла к узлу. Они помечены именами соответствующих данных. • Описание процесса, функции или системы обработки данных, соответствующих узлу диаграммы, может быть представлено диаграммой следующего уровня детализации, если процесс достаточно сложен. • Для изображения диаграмм потоков данных традиционно используют два вида нотаций: нотации Йордана и Гейна — Сарсона.
Диаграммы потоков данных (DFD)
Построения модели разбивается на следующие этапы 1. Выделение множества требований в основные функциональные группы — процессы. 2. Выявление внешних объектов, связанных с разрабатываемой системой. 3. Идентификация основных потоков информации, циркулирующей между системой и внешними объектами. 4. Предварительная разработка контекстной диаграммы. 5. Проверка предварительной контекстной диаграммы и внесение в нее изменений. 6. Построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков. 7. Проверка основных требований контекстной диаграммы. 8. Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса. 9. Проверка основных требований по DFD соответствующего уровня. 10. Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах. 11. Проверка полноты и наглядности модели после построения каждых двухтрех уровней.
Анализ требований и определение спецификаций при объектном подходе • При объектном подходе к программированию модели разрабатываемой системы основываются на предметах и явлениях окружающего мира. • Модель — упрощенное представление реальности. С точки зрения программирования модель — это чертеж системы. • Моделирование необходимо для решения следующих задач: • 1) визуализации системы; • 2) определения ее структуры и поведения; • 3) получения шаблона, позволяющего затем сконструировать систему; • 4) документирования принимаемых решений, используя полученные модели. • Для решения этих задач при описании поведения проектируемого программного обеспечения в настоящее время используется UML (Unified Modeling Language) — унифицированный язык моделирования.
Анализ требований и определение спецификаций при объектном подходе
Схема шаблона: • Введение; Обзор системы; Вопросы проектирования: -Предположения и зависимости; -Основные ограничения; -Цели и руководства; -Методы разработки; Архитектурные стратегии: Стратегия-1 название или описание; Стратегия-2 Название или описание; . . . Архитектура системы: Компонент-1 Название или описание; Компонент-2 Название или описание; . . . Политики и правила: policy/tactic-1 название или описание; policy/tactic-2 название или описание; . . . Детальное описание системы: Модуль-1 Название или описание; Модуль-2 Название или описание; . . . Глоссарий; Библиография.
Введение: • Предоставление обзора всего документа: -описание назначения дока; -границыобласть действия; -целевая аудитория; -определение системы, используя подходящие имена, версии и т. д. ; -ссылки на другие используемые документы; -взаимосвязанные документы; -предпосылки; -документы, описывающие фреймворк; -документы, которые будут писаться на основе этого документа; -определение важных понятий, сокращений, аббревиатур; -краткое содержание.
Обзор системы: Дать общее описание системы, включая ее функциональность и вопросы, связанные с системой в целом и ее структурой (возможно, в том числе обсуждение основных подходов к проектированию и организации). Вы можете разделить это описание на подразделы и тд. Вопросы проектирования: В этом разделе описываются многие из вопросов, которые должны быть заданы или решены, прежде чем пытаться разработать комплексное решение дизайна.
• -предположения и зависимости: Похожие программное или аппаратное обеспечение; Операционные системы; Характеристики конечного пользователя; Возможные и/или вероятные изменения в функциональности.
• -основные ограничения: HW и SW окружение; окружение конечного пользователя; наличие ресурсов; соответствие стандартам; требования совместимости; требования интерфейсов и протоколов; требования БД и транспортов; требования безопасности; ограничения памяти и производительность; быстродействие; сеть; требования тестирования, тестопригодность; другие значения требований качества; другие требования.
• -Цели и руководства: описываются любые цели, правила, руководства, приоритеты, которые влияют на структуру системы. Такие цели могут быть такими: (Сохранить это максимально простым и понятным; (акцент на скорости работы, вместо ограничения выделения памяти; (работать, выглядеть, ощущать продукт, как готовый; Для каждой такой цели пишутся причины ее указания тут и причины принятия (если необходимо- в отдельном подразделе).
• -Методы разработки: Краткое описание методов и подходов для проектирования и разработки системы. Если один или несколько официальных/опубликованных методов были приняты или адаптированы- необходимо включить ссылку на более подробное описание таких методов. Если несколько методов, были серьезно пересмотрены, то каждый из таких методов следует отметить, наряду с кратким объяснением того, почему все или часть его используется или не используется.
• Архитектурные стратегии: Указываются любые проектировочные решения и стратегии, которые влияют на общую организацию системы и на ее структуру высшего уровня. Эти решения должны дать представление о ключевых вопросах и механизмах, используемых в архитектуре системы. Описываются рассуждения для каждого решения (возможно, ссылаясь на ранее определенные цели и принципы). Описываются причины принятия тех или иных решений, их изменения или отказ от них. Такие решения могут касаться (но не ограничиваются ими) вещей, вроде следующих: использование частных (сторонних) продуктов и инструментов- язык программирования, БД, библиотеки и т. д. ; повторное использование существующих компонентов системы; планы на расширение и доработки; используемые образцы интерфейсов (модели вводавывода); примеры взаимодействия HW, SW; обнаружение ошибок и восстановление после сбоев; использование памяти; внешние БД и СУБД; распределенные данные и контроль над всей сетью распределения; основные подходы к контролю; распараллеливание и синхронизация; механизмы взаимодействия; управление другими ресурсами. Каждое значительное решение, вероятно, следует обсуждать в своем собственном подразделе либо (если оно достаточно сложное) в отдельном документе проектирования (с соответствующей ссылкой отсюда, конечно). Убедитесь, что при описании проектного решения вы также обсуждаете любые другие значительные альтернативы, и ваши причины для отказа от них указаны (а также ваши причины для принятия альтернативных решений, которые вы окончательно утвердили к принятию)
• Архитектура системы: Этот раздел должен предоставить общий (высокоуровневый) обзор того, как весь функционал системы был разделен, а затем назначен в подсистемы или компоненты. Не нужно вдаваться в подробности об отдельных компонентах (есть раздел для последующего подробного описания всех компонент). Основной целью является получение общего понимания того, каким образом и почему система разбита на отдельные части, и как отдельные части работают вместе, чтобы обеспечить требуемую функциональность. На самом верхнем уровне описывается основной функционал. Что программное обеспечение должно выполнять и различные роли, которые система (или некая часть системы) должна играть. Описывается, каким образом эта система была разбита на ее компоненты/подсистемы (с указанием каждого компонента (подсистемы) верхнего уровня и распределения функций, возложенных на него). Описывается, как на более высоком уровне компоненты взаимодействуют друг с другом в целях достижения необходимых результатов. Не забудьте предоставить обоснования для выбора данного разбиения системы (возможно обсуждение других предлагаемых разбиений и описания, почему они были отклонены). Не стесняйтесь использовать шаблоны проектирования либо в описании части архитектуры (в формате шаблона ), либо в виде отдельных элементов архитектуры, которые их используют. Если есть какие-либо схемы, модели, диаграммы, документированные сценарии или юзкейсы поведения системы и/или структуры, они могут быть включены сюда (если вы не чувствуете, что они достаточно сложны, чтобы НЕ находиться в подробном разделе "Детальное описание системы"). Диаграммы, схемы описывающие конкретный компонент или подсистему должны быть включены в подраздел, описывающий этот компонент или подсистему. Примечание: Этот раздел (и его подразделы) на самом деле относится только к новым разрабатываемым (или которые еще предстоит разработать) частям системы. Если есть части системы, которые уже существуют к началу разработки новых, то вам нужно описать только те уже существующие части, от которых новые части системы будут зависеть, и только в достаточной детализации, достаточной для описания взаимосвязей и взаимодействий между старыми и новыми частями. Прежние части, которые были изменены или расширены должны быть описаны лишь в той степени, которая необходима читателю, чтобы получить достаточное понимание характера изменений, которые были сделаны.
• Архитектура подсистем: Если есть какой-то компонент, который заслуживает более подробного обсуждения, чем это было представлено в разделе "Архитектура системы", предусматривается, что более подробное описание будет в соответствующем подразделе раздела "Архитектура системы" (или даже может быть в более подходящем для описания компонента в своем собственном документе). Если необходимо, то опишите, как компонент был разделен на подкомпоненты, а также взаимосвязи и взаимодействия между этими подкомпонентами (аналогично тому, что было сделано для верхнего уровня компонентов в разделе "Архитектура системы"). Если какой-либо подкомпонент считается также заслуживающим дальнейшего обсуждения, - опишите его в отдельном подразделе этого раздела (таким же образом). Добавляйте столько уровней/подразделов, сколько необходимо для того, чтобы читателю получить более высокий уровень понимания всей системы или подсистемы (но не забудьте оставить подробности для раздела "Описание системы"). Если этот компонент является очень большим и/или сложным, вы можете рассмотреть вопрос о документировании его структуры в виде отдельного документа и просто, в том числе, ссылки на него в этом разделе.
• Политики и правила: Описываются любые политики, правила, тактические решения, которые не несут за собой архитектурных изменений. Т. е. они не будут существенно влиять на общую организацию системы и ее структуру высшего уровня, но которые тем не менее, влияют на детали интерфейса и/или осуществление различных аспектов системы. Такие решения могут касаться (но не ограничиваются ими) вещей, вроде этих: выбор специфических продуктов- компилятор, интерпретатор, БД, библиотеки и т. д; инженерные компромиссы; стандарты и правила кодирования; протоколы подсистем, модулей, процедур; выбор алгоритмов, паттернов; планы по обеспечению отслеживаемости реализуемых требований; планы тестирования; планы поддержки системы; нтерфейсы для конечных пользователей, программного обеспечения, оборудования и коммуникации; иерархическая организация исходников по файлах, директориям, компонентам; компиляция, сборка и т. д. Каждое конкретное правило или набор правил должны быть вероятно обсуждены в конкретном разделе или (при случае большого или комплексного набора правил) в отдельном документе (с соответствующей ссылкой из этого документа, конечно). Убедитесь, что пока вы описываете решение по архитектуре, дизайну, вы также не забываете рассматривать и описывать альтернативные варианты и причины для отказа от них.
• Детальное описание системы: Большинство компонентов, описанных в разделе "Архитектура системы" потребует более детального обсуждения и описания. Другие компоненты (нижних уровней) и подкомпоненты возможно, необходимо будет также описать. Каждый подраздел этого раздела будет ссылаться или содержать подробное описание программных компонентов системы. В ходе обсуждения должны быть охвачены следующие атрибуты компонентов программного обеспечения: классификация: вид компонента, такого как подсистема, модуль, класс, пакет, функция, файл и т. д. ; определение: специфическое назначение и значение компонента в системе. Может понадобиться ссылка на спецификацию требований; функции и поведение компонента: Что должен выполнять этот компонент? Какие роли он играет? Какие виды сервисов он предоставляет для клиентовпользователей? Для некоторых компонентов здесь может быть необходима ссылка на требования; Ограничения: Любые уместные ограничения, лимиты для этого компонента. Здесь должны быть указаны ограничения по времени, объему данных, состояниям компонента, может включать в себя правила для взаимодействия с этим компонентом (охватывающие предварительные условия, постусловия, инварианты, другие ограничения на входе или выходе, форматы (типы) данных и доступ к данным, синхронизация, исключения и т. д. ); Состав: описание использования и важности субкомпонентов, которые являются частью этого компонента; Использованиевзаимодействие: описание взаимодействия с другими компонентами. Какие другие компоненты используются этим компонентом? какие используют данный компонент (здесь необходимо включить описание влияния на другие части и компоненты, которое может иметь данный компонент). Объектно-ориентированный дизайн должен содержать описание любых известных или предполагаемых подклассов, суперклассов и метаклассов; Ресурсы: описание всех управляемых, находящихся под влиянием этого компонента, а также необходимых ресурсов. Ресурсы являются внешними элементами проектировании, например, память, процессоры, принтеры, БД или библиотеки. Здесь должно быть включено обсуждение всех возможных условий и возможных блокирующих проблем, а также пути их решения; Обработка: описание того, как компоненты действуют, выполняя функционал, который они должны выполнять. Это должно включать в себя описание всех алгоритмов, изменения состояний; соответствующие временные или пространственные сложности; параллельность, методы создания, инициализации, а также очистку; обработку исключений; Интерфейсыэкспорт: набор сервисов (ресурсы, данные, типы, ограничения, процедуры и исключения), которые предоставляются этим компонентом. Четкое определение и объявление каждого такого элемента должно быть актуальным, с комментариями и аннотациями, описывающими значения величин, параметров и т. д. для каждого сервиса; Значительная часть информации, которая появляется в этом разделе не обязательно должна содержаться отдельно от исходного кода. В самом деле, большую часть информации можно почерпнуть из самих исходников (особенно, если они адекватно комментированы). Данный раздел не должен копировать или воспроизводить информацию, которую можно легко получить из чтения исходного кода (было бы нежелательно дублировать усилия, также будет очень трудно быть в курсе послених изменений). Рекомендуется, чтобы большая часть этой информации содержалась в исходниках (с соответствующими комментариями по каждому компоненту, подсистеме, модулю, и подпрограмме). Таким образом, ожидается, что этот раздел будет в значительной степени состоять из ссылок (выдержки из аннотированных схем) и исходного кода.
Скачать презентацию Спецификация на ПО Наиболее важная
Спецификация на ПО.pptx