Полученная в результате декомпозиции структура системы должна сопровождаться кратким описанием включенных в нее подсистем.
Комментарии к примеру. Приведем примерную структурную схему разрабатываемой системы и описание некоторых подсистем (рисунок 3).
В состав системы входят следующие подсистемы: 1) Подсистема управления, которая отвечает за взаимодействие подсистем между собой и представлена в виде иерархического меню; 2) Подсистема составления кроссворда, в состав которой входят: a) подсистема настройки параметров, которая отвечает за ввод (выбор) значений параметров кроссворда и проверку корректности этих значений; b) подсистема ручного составления, которая … c) подсистема генерирования, которая … 3) Подсистема разгадывания, которая … 4) Файловая подсистема, которая … 5) Подсистема работы со словарем, которая … 6) Подсистема визуализации, которая … 7) Справочная подсистема, которая содержит сведения о системе (руководство пользователю) и ее об ее разработчиках. ЛАБОРАТОРНАЯ РАБОТА № 5 Разработка спецификации программного обеспечения является одним из фундаментальных процессов технологии разработки ПО. Этот процесс анализа, формирования, документирования и проверки функциональных возможностей и ограничений системы называется в терминологии программной инженерии «разработка требований» (спецификация требований). Он является критическим этапом в создании всех видов программных систем, что обусловлено тем, что ошибки, допущенные на этой стадии, ведут к возникновению серьезных проблем на этапах проектирования и разработки. Опыт индустрии информационных технологий однозначно показывает, что вопросы, связанные с управлением требованиями, оказывают критически-важное влияние на программные проекты, в определенной степени ‑ на сам факт возможности успешного завершения проектов. Только систематичная работа с требованиями позволяет корректным образом обеспечить моделирование задач реального мира и формулирование необходимых приемочных тестов для того, чтобы убедиться в соответствии создаваемых программных систем критериям, заданным реальными практическими потребностями. Дадим некоторые определения. Требования ‑ это свойства, которыми должно обладать ПО для адекватного определения функций, условий и ограничений выполнения ПО, а также объемов данных, технического обеспечения и среды функционирования [12, 13]. На практике часто применяется подход, используемый в различных методологиях разработки ПО и базирующийся на определении групп требований к продукту. Такой подход обычно включает группы (типы, категории) требований, например: программные, системные, функциональные, нефункциональные (в частности, атрибуты качества) и т.п. Программные требования (Software Requirements) ‑ свойства программного обеспечения, которые должны быть надлежащим образом представлены в нём для решения конкретных практических задач [14]. Данная область знаний касается вопросов извлечения (сбора), анализа, специфицирования и утверждения требований к разрабатываемой ПС. Функциональные требования задают «что» система должна делать; нефункциональные – с соблюдением «каких условий» (например, скорость отклика при выполнении заданной операции). При разработке этих требований в первую очередь необходимо учитывать потребности пользователя (заказчика). Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Часто пользовательские требования представляют в виде сценариев (вариантов использования) Use Сase (см. лабораторную работу №5). Среди нефункциональных требований на первый план выходят атрибуты качества и ограничения. Атрибуты качества (Quality Attributes) описывают дополнительные характеристики продукта в различных «измерениях», важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п. Данный вид требований мы будем называть спецификацией качества. Ограничения (Constraints) включают в себя формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных,...), которые, в свою очередь, могут относиться, например, к внешним интерфейсам. Спецификация требований к ПО (SRS) ‑ процесс формализованного описания функциональных и нефункциональных требований, требований к характеристикам качества в соответствии со стандартом качества ISO/IEC 9126-94, которые будут отрабатываться на этапах ЖЦ ПО. В спецификации требований отражается: − структура ПО; − требования к функциям, качеству и документации; − задается в общих чертах архитектура системы и ПО, алгоритмы, логика управления и структуры данных.
|
