Удобство и простота обслуживания

Производительность

Требования к производительности определяют насколько быстро и качественно система должна выполнять определенные функции. Они определяют время отклика, пропускную способность и т.д. Жесткие требования к производительности существенно влияют на выбор аппаратных средств, технологию разработки и принимаемые инженерные решения при реализации.

Надежность и доступность

Надежность – это вероятность работы системы без сбоев в течение определенного времени. Для измерения надежности может быть использовано среднее время работы системы до сбоя.

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

Безопасность

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

Удобство и простота обслуживания

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

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

Легкость сопровождения и эксплуатации

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

Мобильность

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

Повторное использование

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

Тестируемость

Этот атрибут показывает легкость, с которой компоненты проекта и комплексный продукт могут быть проверены на наличие ошибок.

1.1.2.2. Нефункциональные требования к процессу

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

1.1.2.3. Внешние нефункциональные требования

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

1.2. Свойства требований

Требования должны удовлетворять определенным характеристикам качества. Основные характеристики – это полнота, корректность, необходимость, осуществимость, приоритет, недвусмысленность, непротиворечивость (согласованность), проверяемость и прослеживаемость (см. рис. 1.1).

 

Рис. 1.1

Полнота и корректность

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

Приоритет

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

Сценарии

Люди (пользователи) часто лучше воспринимают и описывают примеры из реальной жизни, поэтому им проще ответить на вопрос "как работает система?", чем "что делает система?" Другими словами, пользователи легко понимают и могут оценить сценарий взаимодействия с программной системой, чем ее абстрактное описание.

Сценарий – это способ описания структуры задачи, представляющий собой повествовательный рассказ о совершаемых действиях, происходящих в данных временных рамках и в данном контексте [8].

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

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

Сценарии событий

Событийные сценарии (event scenarios) используются для документирования поведения системы, представленного определенными событиями. В большинстве случаев сценарий включает в себя:

· Описание начального состояния системы.

· Описание нормального протекания событий.

· Описание исключительных ситуаций и способов их обработки.

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

· Описание конечного состояния системы.

Описание сценария может быть представлено простым (или структурированным) текстом или при помощи схем сценариев, которые позволяют идентифицировать входные и выходные данные системы, управляющую информацию, внутрисистемные данные и исключительные ситуации [9].

2. Разработка системных требований

2.1. Детализация требований пользователей

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

Системные требования состоят из полного списка конкретных свойств и функциональности, которую должна иметь программа, сформулированных в подробностях [10]

Модели потоков данных

Модели потоков данных – это простой и понятный способ описания последовательности обработки данных внутри системы. Для описания модели потоков данных используются диаграммы потоков данных (data flow diagram, DFD), во всем многообразии нотаций которых, можно выделить основные компоненты [5]:

· процесс (трансформационный процесс, системная функция, обрабатывающая единица) – механизм, описывающий способ получения выходных данных из входных данных;

· поток данных – определяющий перемещение данных (материалов) между процессами;

· хранилище – места хранения данных (базы данных, например);

· внешние сущности – объекты внешнего (по отношению к системе) мира.

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

Ценность моделей потоков данных в том, что они позволяют:

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

· проследить и документировать перемещение данных по системе, помогая понять этот процесс;

· учитывая их простоту и понятность, использовать модели для общения с пользователями, занятыми в разработке требований;

· описывать (при проектировании) принятые решения.

Наивысший уровень диаграммы потока данных – контекстная диаграмма – представляет систему, как единый процесс. Контекстная диаграмма содержит внешние, по отношению к системе, сущности, которые являются источниками или потребителями системных потоков данных. Выделив важнейшие процессы системы, можно разработать диаграмму потока данных уровня 0, в которой, кроме внешних сущностей и системных потоков данных, определенных в контекстной диаграмме, содержит эти процессы и те потоки данных, которыми они обмениваются. Каждый процесс из диаграммы нулевого уровня может быть детализирован в виде диаграммы следующего уровня (уровень 1), содержащего всю его функциональность. Детализация может быть продолжена до тех пор, пока процессы на диаграмме не станут содержать только простейшие операции. Функциональные требования в спецификации требований к системе должны точно определить, что происходит в ходе каждого простейшего процесса.

Пример 4.1.

На рис. 4.1 приведена контекстная диаграмма информационной системы архива, которая позволяет:

· записывать в архив подлинники программ;

· вносить в программы изменения;

· выполнять тиражирование программ.

Рис. 4.1

С системой общаются:

· разработчики, выдающие запросы на тиражирование программ и получающие копии программ;

· сотрудники архива, выполняющие прием и регистрацию подлинников программ, и внесение в них изменений (ИИ – извещение об изменении);

· магнитотека (хранилище) программ.

Единственный процесс «Обслужить» не раскрывает функций системы, поэтому для более детального описания необходима более детальная диаграмма (диаграмма 0-го уровня). На рис. 4.2 приведена диаграмма 0-го уровня, которая показывает процессы, выполняемые системой и потоки входных и выходных данных для процессов. Процессы на диаграмме нумеруются и могут, при необходимости, быть описаны более подробно на следующих уровнях детализации.

 

Рис. 4.2

При разработке диаграмм потоков данных следует придерживаться следующих общих правил:

· размещать на диаграмме не более 7 – 10 процессов;

· не загромождать диаграммы несущественными на данном уровне деталями;

· декомпозицию потоков данных выполнять параллельно с декомпозицией процессов;

· однократно определять функционально идентичные процессы и ссылаться на них, на нижних уровнях.

Модели конечных автоматов

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

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

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

Пример 4.2.

На рис. 4.3 приведена диаграмма конечного автомата, описывающего процесс «Принять программу в архив».

Рис. 4.3

Система находится в начальном состоянии и ожидает запроса. После его получения она переходит в состояние «Контроль запроса», где выясняет, имеет ли разработчик полномочия для сдачи программы в архив. Если полномочий недостаточно или программа уже находится в архиве, то система возвращается в начальное состояние.

Прототипы

При разработке требований трудно предвидеть, как система будет взаимодействовать с другими системами, как она повлияет на трудовой процесс, какие операции нужно автоматизировать. Анализ требований позволяет снять некоторую неопределенность, но четкое определение требований к разрабатываемой системе, их проверка – задача весьма сложная. Разработка прототипа позволяет сделать требования более реальными, помогает заинтересованным лицам прийти к общему пониманию требований, ускоряет процесс разработки и анализа.

2.2.1. Роль прототипов при разработке требований

Прототип – это начальная версия программной системы, которая используется для демонстрации концепций, заложенных в системе, проверки вариантов требований, а также поиска проблем, которые могут возникнуть как в ходе разработки, так и при эксплуатации системы, чтобы пользователи могли начать экспериментировать с ним как можно раньше [9].

Прототип полезен в решения следующих задач:

1. Разработка требований.

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

2. Проверка требований.

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

3. Разработка взаимодействия с пользователем.

Прототип позволяет реализовать различные варианты взаимодействия, исследовать альтернативные решения и выбрать оптимальный вариант.

4. Спецификация системных требований.

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

Виды прототипов

Горизонтальные прототипы

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

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

Вертикальные прототипы

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

Разработка прототипов

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

Языки описания программ

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

Примером такого подхода является язык описания программ PDL (program description language). Этот язык строится по образцу языков программирования, управляющие операторы которых определяют:

· внешний синтаксис, т.е. описание структуры управления;

· внутренний синтаксис – описание структур данных и процедур их обработки – не определен и выбирается проектировщиком.

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

Пример 4.4.

Если использовать в описании процесса на PDL предложения, написанные на естественном языке, то описание будет достаточно простым для понимания. На рис. 4.7 приведено описание процесса «Принять программу в архив», рассмотренного в разделе 3.

Рис. 4.7

Графические нотации

Для описания требований применяются различные графические нотации. Наиболее часто используются уже рассмотренные графические средства: диаграммы потоков данных, модели конечных автоматов, диаграммы “сущность-связь”, сценарии, варианты использования, диаграммы использования, диаграммы состояний и диаграммы последовательности UML.

2.5. Документирование системных требований

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

3. Анализ спецификации требований

3.1. Оценка качества спецификации требований

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

Полнота и согласованность

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

Способность к модификации

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

Трассируемость

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

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

4. Управление требованиями

4.1. Причины изменений требований

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

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

· понимание пользователями возможностей системы, решаемых ею задач, может измениться;

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

· понимание разработчиками поставленных перед ними задач меняется.

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

С точки зрения разработки требования можно разделить на два класса:

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

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

Управление изменениями

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

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

1. Все изменения должны вноситься в соответствии с документированным и утвержденным процессом. Неофициальные запросы на изменение не рассматриваются. Запрос на изменение не гарантирует его выполнение. Текст запроса не должен изменяться или удаляться.

2. Для каждого изменения должен выполняться анализ его влияния. Обоснование утверждения или отклонения запроса на изменение должно быть документировано.

3. Реализовывать неутвержденные изменения запрещено.

Диаграмма переходов состояний для типового процесса внесения изменений в спецификацию требований приведена на рис. 7.2.

Рис. 7.2

Процесс инициируется запросом на внесение изменения, или предложением об изменении, оформленным в соответствии с утвержденными правилами и поступивший по официальным каналам. Если запрос не содержит требования, то процесс переходит в состояние «Разработка требования», в котором аналитик и инициатор изменения формируют требование. Полученное требование анализируется для определения ожидаемого от него эффекта и определения стоимости внесения изменения в спецификацию требований и в структуру и код системы. Принимается решение об одобрении или отклонении изменения. В случае положительного решения оформляется документ, содержащий решение об изменении и изменение (например, извещение об изменении, или ИИ), после чего вносится изменение в спецификацию и систему.

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

Стандарты достаточно строго и точно определяют процессы оформления и внесения изменения в спецификацию (документ), но действия по анализу требования и его стоимости, принятия решения об изменении, внесение изменений в код системы – должны быть определены в организации (или проекте).

Производительность

Требования к производительности определяют насколько быстро и качественно система должна выполнять определенные функции. Они определяют время отклика, пропускную способность и т.д. Жесткие требования к производительности существенно влияют на выбор аппаратных средств, технологию разработки и принимаемые инженерные решения при реализации.

Надежность и доступность

Надежность – это вероятность работы системы без сбоев в течение определенного времени. Для измерения надежности может быть использовано среднее время работы системы до сбоя.

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

Безопасность

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

Удобство и простота обслуживания

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

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