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

⇐ ПредыдущаяСтр 3 из 6Следующая ⇒

Комментарии к примеру. Приведем примерную структурную схему разрабатываемой системы и описание некоторых подсистем (рисунок 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, которые будут отрабатываться на этапах ЖЦ ПО.

В спецификации требований отражается:

− структура ПО;

− требования к функциям, качеству и документации;

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

Характеристики правильно составленной спецификации требований к ПО

Спецификация требований должна быть [15]:

a) Корректной (каждое требование, изложенное в ней, является требованием, которому должно удовлетворять программное обеспечение);

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

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

d) Непротиворечивой (никакой набор отдельных требований, описанных в ней, не находится в противоречии с ней или с каким-то документом более высокого уровня);

e) Упорядоченной по ее значимости и/или устойчивости (каждое требование должно иметь идентификатор и относиться к определенному классу требований: необходимые, условные и необязательные);

f) Проверяемой (каждое требование, изложенное в ней, может быть проверено.);

g) Модифицируемой (структура и стиль SRS таковы, что любые изменения требований могут быть выполнены легко, полностью и непротиворечивым образом при сохранении структуры и стиля);

h) Отслеживаемой (должен четко прослеживаться источник каждого из ее требований и SRS облегчает обращение к каждому из требований при дальнейшей разработке или модернизации документации).

В процессе работы с требованиями участвуют так называемые «заинтересованные лица»[10], к числу которых мы будем относить:

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

− Заказчиков (людей, которые являются целевой аудиторией на рынке программного обеспечения, в этой роли выступает преподаватель);

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

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

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

Комментарии к примеру. В спецификации качества перечисляются основные требования по показателям качества:

- описывается уровень надежности ПС;

- формулируются требования по быстродействию;

- требования к разработке интерфейса и т.п.

Функциональная спецификациявключает в себя:

- перечень всех функций системы с привязкой их к конкретной подсистеме и к информационной среде (входные и выходные данные), фрагмент функциональной спецификации приведен в таблице 1;

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

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

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

Таблица 2 – Перечень исключительных ситуаций

Название подсистемы	Название исключительной ситуации	Реакция системы
1 Справочная	1.1 Не возможно открыть файл справки	Выдача сообщения «Файл справки поврежден»
1.2 Не возможно найти файл справки	Выдача сообщения «Отсутствует файл справки»
2 Файловая	2.1 Попытка открытия файла с несобственным форматом	Выдача сообщения «Файл поврежден или недопустимого формата»
2.2 Файл с заданным именем не существует	Выдача аналогичного сообщения
…	…	…

Таблица 1 – Перечень функций, выполняемых системой (фрагмент)

Название подсистемы	Название функции	Информационная среда
Входные данные	Выходные данные
Назначение (наименование)	Тип, ограничения	Назначение (наименование)	Тип, ограничения
1 Справочная	1.1 Выдать сведения о разработчиках	Сведения о разработчиках системы (ФИО, номер группы)	Текст (МЕМО)	Визуальное отображение информации	‑
1.2 Выдать сведения о системе	Файл справки	Текстовый (*.HTML)
Код ошибки	целое
2 Настройки параметров	2.1 Задать количество букв в пересечении	Диапазон количества букв: минимальное максимальное	Целое	Текущее значение букв в пересечении	Целое
2.2 Подключить словарь понятий	Имя файла	Строка, *.dict	Список понятий и их определений	Динамический массив строк
Код ошибки	Целое
2.3 Задать длину кроссворда	Диапазон длин: минимальное максимальное	Целое	Текущее значение длины	Целое
Код ошибки	Целое
…	…	…	…	…
3 Файловая	3.1 Загрузить файл с кроссвордом	Имя файла	Строка, *.kros	Кроссворд	Объект, структура определяется в ходе проектирования
Код ошибки	Целое

ЛАБОРАТОРНАЯ РАБОТА № 6
разработка прототипа интерфейса пользователя системы

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

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

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

- чтобы пользователи работали более продуктивно, программа должна быть простой в использовании;

- хороший интерфейс может стать преимуществом против конкурентов, плохой ‑ послужить причиной неудачи всего проекта.

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

- опыт работы пользователей с компьютером, типовые ситуации использования;

- какая информация необходима и когда, какие результаты должны быть получены;

- технологию разработки и платформа, на которой будут работать пользователи.

⇐ Предыдущая 1 234 5 6 Следующая ⇒