типы D-требований. Типы dтребовании Типичная последовательность действий для сбора и документирования d требований показана на рисунке. Рисунок Порядок получения dтребований
 Скачать 443.22 Kb.
|
|
Содержание Введение ............................................................................................................................. 3 Типы D-требовании ........................................................................................................... 4 Заключение ....................................................................................................................... 11 Литература ........................................................................................................................ 12 3 Введение Разработчикам программного обеспечения нужна база для проектирования и разработки. Эта база представляет собой детальные требования (D-требования). D- требования состоят из полного списка конкретных свойств и функциональности, которую должна иметь программа. Каждое из этих требований пронумеровано, помечено и отслеживается по ходу разработки. D-требования должны быть согласованы с С- требованиями. 4 Типы D-требовании Типичная последовательность действий для сбора и документирования D- требований показана на рисунке. Рисунок – Порядок получения D-требований Существуют несколько типов D-требований: 1. Функциональные требования – определяют работу, которую должно выполнять проектируемая система (например, «приложение будет вычислять стоимость портфеля акций пользователя»). 2. Нефункциональные требования. 2.1. Производительность. Требования к производительности определяют временные ограничения, которые должны быть выполнены в программе. Заказчики и разработчики обсуждают ограничения по времени вычислений, использованию оперативной памяти, объему запоминающих устройств и т. д. 2.2. Надежность и безопасность. Требования надежности определяют надежность в измеряемых величинах. Требования такого типа предполагают вероятность неидеальной работы программы и ограничивают область ее несовершенства. Особое внимание в ПЗ необходимо уделить вопросам обеспечения безопасности системы с учетом возможности искажения данных посредством несанкционированного доступа, сбоя системного или прикладного ПО. 2.3. Обработка ошибок. Эта категория требований объясняет, как программа должна реагировать на возникающие ошибки. Например, что должна делать программа, 5 если она получает сообщение из другой программы в неразрешенном формате? Это не касается ошибок, генерируемых самой программой. 2.4. Интерфейсные требования. Интерфейсные требования описывают формат, в котором программа общается с окружением. 2.5. Ограничения. Ограничения на проектирование или реализацию описывают границы или условия того, как приложение должно быть задумано и разработано. Например, накладываются ограничения на инструменты и языки программирования ввиду сложившихся традиций организации, опыта программистов, совместимости и проч. 3. Обратные требования – это функционал, который система не обеспечивает. Типичная последовательность получения функциональных D-требований с использованием объектно-ориентированного подхода приведена ниже: 1. Процесс начинается с перечисления классов, упомянутых в вариантах использования – это т.н. классы анализа. 2. Полученный набор классов обычно неполон и следует попытаться найти остальные классы предметной области. 3. Для каждого из полученных классов выписывается вся необходимая функциональность программы, за которую отвечает данный класс. Например, «у каждого клиента будет имя» (атрибут класса Клиент) и «программа должна иметь возможность вычислять капитал каждого клиента» (метод класса Клиент). События, которые должны обрабатывать объекты класса, также должны быть определены. В это же время должны быть разработаны и планы тестирования для каждого D-требования. 4. Связи между классами определяются в два этапа: 4.1. Начальный набор связей определяется на основе анализа диаграмм сотрудничества (collaboration) или диаграмм последовательности. Если два объекта взаимодействуют (обмениваются сообщениями), между ними на диаграмме должна существовать связь (путь взаимодействия), которая преобразуется в двунаправленную ассоциацию между соответствующими классами. Если сообщения между некоторой парой объектов передаются только в одном направлении, то для соответствующей ассоциации вводится направление навигации. 4.2. Анализируются и уточняются ассоциации между классами-сущностями. Задаются мощности ассоциаций, могут использоваться множественные ассоциации, агрегации, обобщения и ассоциации-классы. 5. D-требования проверяются и сравниваются с С-требованиями. 6. D-требования проверяются заказчиком и, затем, публикуются. 6 Особое внимание необходимо уделить вопросу получения классов анализа, поскольку – это творческий процесс, тесно связанный с анализом информации о предметной области. При получении классов анализа необходимо учитывать следующие аспекты: 1. Класс анализа является четкой абстракцией, моделирующей один конкретный элемент предметной области. Он должен имеет от 3-х до 5-ти операций. Все свойства класса служат реализации его назначения. Однако для реализации своего назначения класс должен иметь минимальное количество связей с другими классами. 2. В классах анализа содержаться только ключевые атрибуты и операции, определенные на очень высоком уровне абстракции. Как правило, каждая операция уровня анализа затем разбивается на несколько операций уровня проекта. 3. Необходимо избегать глубоких деревьев наследования (3 и более уровней), поскольку частой ошибкой при построении иерархии наследования является использование функциональной декомпозиции, где каждый уровень абстракции имеет только одну операцию. Наследование использует только там, где есть явная иерархи наследования, вытекающая непосредственно из предметной области. 4. При выявлении классов посредством анализа текста С-требования, существительные указывают на классы или атрибуты, а глаголы служат признаком операций. Однако синонимы и омонимы могут стать причиной появления ложных классов. 5. При выявлении классов совместно с пользователями часто используют т.н. CRC (Class- Responsibilities - Collaborators)-анализ с помощью стикеров и мозговой штурм. Без возможности четкого контроля каждого требования от проекта до программного кода, реализующего это требование, было бы сложно убедиться в том, что программа разработана в соответствии с установленными требованиями. Когда требования меняются (чего следует ожидать), это становится еще сложнее. Возможность отображать каждое требование на соответствующие части проекта и программы называется прослеживанием. Один из способов, помогающих обеспечить прослеживание, заключается в отображении каждого функционального D-требования на конкретную функцию целевого языка. На рисунке демонстрируется обеспечение принципа прослеживания для некоторого требования №NNN «Поиск учебно-методических материалов (УММ)»: 1. С-требования, сформулированные заказчиком при проведении анкетирования (или интервью), отображаются на диаграмме вариантов использования; 2. на этапе проработки D-требований, каждое С-требование представляется комплектом из трех диаграмм: деятельности, классов и последовательностей; 7 3. при проектировании архитектуры системы для удовлетворения требования №NNN в некотором классе слоя предметной области предусматривается соответствующий метод(ы) (например, «findByAuthor» и «findByTitle)»; 4. на стадии детального проектирования прорабатывается алгоритм метода, отвечающего за выполнение требования №NNN, а также создается ER-диаграмма БД и конструируется SQL-запрос(ы), выполнение которого обеспечит удовлетворение данного требования; 5. на стадии реализации для выполнения требования №NNN разрабатываются листинги соответствующих методов и, наконец, на стадии тестирования выполнение требования №NNN проверяется с использованием составленного плана тестирования. Рисунок – Пояснение принципа прослеживания На протяжении всего процесса проектирования необходимо прилагать усилия по планированию будущего тестирования. Существует несколько преимуществ в написании тестов одновременно с требованиями. Во-первых, это позволяет прояснить требование. Во-вторых, это переносит некоторую часть работы из фазы тестирования проекта в фазу разработки требований. Пусть, например, SRS включает в свой состав D-требование 8 №NNN следующего содержания: «NNN. ФИО каждого студента информационной системы «Деканат» будет представлять собой строку символов от 1 до 256». C целью планирования процедуры тестирования необходимо составить проект плана тестирования, примерная форма которого может быть представлена в виде таблицы. Таблица «Тестовые данные для проверки D-требования №nnn» № п/п Входные тестовые данные Ожидаемый результат 1 Иванов Иван Иванович Иванов Иван Иванович 2 length()<10 Сообщение с вопросом о корректности вводимых данных 3 length()>256 Сообщение с вопросом о корректности вводимых данных 4 … … При формировании требований к АСОИУ необходимо обеспечить достижение ряда показателей, среди которых наиболее значимыми являются: прослеживание, полнота, согласованность и т.д. Набор D-требований согласован, если между требованиями нет противоречий. По мере увеличения числа D-требований согласованность может стать труднодостижимой, но объектно-ориентированная организация требований помогает избежать несогласованности благодаря классификации D-требований по классам и с помощью разложения их на простейшие составляющие. С целью проверки указанных характеристик составляют таблицу, форма которой приведена на рисунке: Рисунок «Шаблон таблицы для проверки D-требований» Во втором столбце таблицы приводится идентификатор D-требования. В столбце 3 приводится идентификатор С-требования, в состав которого входит данное D-требование. В столбце 4 приводятся идентификаторы D-требований, выполнение которых необходимо и достаточно для реализации данного D-требования. В столбце 5 делают отметку, если данное D-требование не противоречит никакому другому D-требованию из перечисленных в таблице. В столбце 6 делают отметку, если данное D-требование может быть реализовано 9 с учетом ограничений, накладываемых другими С- или D-требованиями, средой разработки, аппаратной платформой и т.д. В столбце 7 делают отметку, если данное D-требование не может быть истолковано двояко. В столбце 8 делают отметку, если данное D-требование сформулировано предельно просто. В случае отсутствия отметки необходимо привести дополнительные разъяснения по содержанию такого требования. В столбце 9 делают отметку, если в данном требовании указаны допустимые отклонения от необходимого результата. В столбце 10 делают отметку, если формулировка данного D-требования не претерпит существенных изменений при возникновении в будущем необходимости наращивания функциональных возможностей системы. В столбце 11 делают отметку, если для данного требования составлен план тестирования. В столбце 12 делают отметку по окончании реализации данного D-требования в виде программного кода. Порядок разработки каждого D-требования показан выше на рисунке и включает следующие шаги: 1. Предварительный анализ требования: A. Классификация требования как функциональное или нефункциональное (рекомендуется использовать подсказки IEEE SRS для большинства нефункциональных требований); B. выбор метода организации функциональных требований. 2. Обеспечение прослеживания требования. Убедиться в возможности прослеживания при проектировании и реализации. 3. Обеспечение тестируемости требования. Спланировать конкретный тест, устанавливающий выполнение требования. 4. Проверка недвусмысленности требования. 5. Назначение требованию приоритет. Например, высокий («важно»), средний («желательно») или низкий («не обязательно»). 6. Проверка полноты требования. Для каждого требования следует убедиться в присутствии всех остальных необходимых или сопутствующих требований. 7. Добавление состояния ошибки: A. сформулировать, что требуется выполнить при возникновении нештатных ситуаций; B. в критичных местах добавить состояния ошибок программирования. 8. Проверка согласованности. Необходимо убедиться, что ни одно требование не противоречит каким-либо аспектам другого требования. 10 Как только все D-требования собраны, необходимо обновить SPMP и передать D- требования под управление конфигурациями. Для формализации и детальной фиксации требований рекомендуется использовать спецификацию требований к программному обеспечению (Software Requirements Specification — SRS) в соответствии со стандартом IEEE 830-1993. 11 Заключение В ходе выполнения данной работы были рассмотрены основные типы D-требований: функциональные требования, нефункциональные требования (производительность, надежность и безопасность, обработка ошибок, интерфейсные требования, ограничения) и обратные требования. А также изучена последовательность действий для сбора и документирования D-требований 12 Литература 1. D-Требования // https://analytics.infozone.pro/requirements-gathering-and- analysis/ (дата обращения: 24.12.2021). 2. D-Требования // https://studbooks.net/1160993/informatika/trebovaniya (дата обращения: 24.12.2021). 3. https://portal.tpu.ru/SHARED/i/IGSAVENKO/academic/Tab/Tab3/trpo_lections_ 230100_2014.pdf (дата обращения: 24.12.2021). 4. Зубкова Т.М. Технология разработки программного обеспечения: Учебное пособие. - Оренбург: ГОУ ОГУ, 2004. – 101 с. 5. Орлов С.А. Технологии разработки программного обеспечения - Учебник для вузов. - Питер, 2002 г.-464 с. 6. Брауде Э. Технология разработки программного обеспечения Э. Брауде. – СПб.: Питер, 2004. – 655 с. 7. Уилсон Скот Ф., Мэйпл Брюс, Лэндгрейв Тим. Принципы проектирования и разработки программного обеспечения. М.: Русская редакция, 2002г. – 736с. |