МГТУ СТАНКИН 
 
 
 
 

     Реферат

     на  тему:

     “Управление требованиями клиент-серверного программного обеспечения” 
 
 
 
 
 
 
 

     Магистранта группы И-9-15

     Крылова Алексея 
 

     Москва, 2011

Оглавление

Управление требованиями клиент-сервер приложений. 3

Что такое управление требованиями? 3

Требования и процесс управления проектом. 4

Основные определения клиент-серверной архитектуры. 5

Пользовательские требования к клиент-сервер ПО. 6

Функциональные требования к клиент-сервер ПО. 8

Системные и архитектурные требования к клиент-сервер ПО. 8

Нефункциональные требования к клиент-сервер ПО. 20

Вывод. 21

Список использованной литературы. 22

Управление  требованиями клиент-сервер приложений.

Что такое управление требованиями?

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

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

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

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

Требования  и процесс управления проектом.

 

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

     Бизнес-требования (business requirements) содержат высокоуровне-

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

     Требования  пользователей  (user requirements) описывают цели и

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

способам представления  этого вида требований относятся  варианты

использования, сценарии и таблицы ≪событие — отклик≫. Таким обра-

зом, в этом документе указано, что клиенты смогут делать с помощью

системы.

     Функциональные  требования (functional requirements) определяют

функциональность ПО, которую разработчики должны построить, что-

бы пользователи смогли выполнить свои задачи в рамках бизнес-тре-

бований. Иногда именуемые требованиями поведения (behavioral requirements), они содержат положения с традиционным ≪должен≫ или

≪должна≫.

     Термином  системные требования (system requirements) обозначают

высокоуровневые требования к продукту, которые содержат многие подсистемы, то есть система (IEEE, 1998с). Говоря о системе, мы под -

разумеваем программное обеспечение или подсистемы ПО и обору-

дования. Люди — часть системы, поэтому определенные функции сис-

темы могут  распространяться и на людей. 

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

     В настоящее время весьма широко распространенной системой управления требованиями является так называемая V-образная модель (рис.1), которая состоит из четырёх этапов.

     Рис.1. V-образная модель. 

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

     Такая схема вполне применима и к  разработке клиент-серверного программного обеспечения.

Основные  определения клиент-серверной  архитектуры.

     ·Клиент.

Объект, запрашивающий информацию по сети. Как правило, это

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

информацию у  сервера

     · Промежуточное программное обеспечение.

Набор драйверов, прикладных программных интерфейсов и прочего

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

клиентским приложением  и сервером

     · Реляционная база данных.

База данных, в которой доступ к информации ограничен выбором строк,

удовлетворяющих определенным критериям поиска

     · Сервер.

Компьютер (как правило, высокопроизводительная рабочая станция, мини-

компьютер или  мэйнфрейм), хранящий информацию, с которой работают

сетевые клиенты

     ·Вычислительная модель клиент-сервер.

Разделение приложения на отдельные задачи, размещаемые на различных

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

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

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

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

режимом работы компьютера, а менеджеры уровня отделов  получают

возможность реагировать  на локальные проблемы.

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

различные отделы компании от накладных расходов по управлению

сложными вычислительными  системами, но позволяет им выбирать типы

машин и интерфейсы, которые им необходимы для доступа  к данным. С

подобным сочетанием централизованного и распределенного  управления

мы уже.

     · Как корпоративные пользователи, так и производители отдают

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

пользователю  предоставляется более широкий  выбор продуктов и большая

свобода в объединении  оборудования от различных производителей.

     · Компьютерная сеть является ключевым звеном данной архитектуры.

Поэтому вопросы  сетевого администрирования и сетевой  безопасности при

работе с информационными  системами данного типа имеют  приоритет.

Пользовательские  требования к клиент-сервер ПО.

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

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

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

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

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