МГТУ СТАНКИН 
 
 
 
 

     Реферат

     на  тему:

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

     Магистранта группы И-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-модель  также отображает системную разработку  в терминах уровней, где каждый  уровень соотносится с определенным  этапом разработки. Несмотря на  то, что на каждом уровне могут  быть использованы несколько  различных процессов, основной  принцип работы с требованиями  не меняется.

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

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

     ·Клиент.

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

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

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

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

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

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

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

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

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

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

     · Сервер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

мы уже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     Важным фактором является метод взаимодействия пользователя с системой, то есть большое значение имеет пользовательский интерфейс клиентской машины. В большинстве систем клиент-сервер графическому интерфейсу пользователя (Graphical User Interface, GUI) уделяется очень серьезное внимание — он должен быть простым и удобным, но одновременно мощным и гибким. Таким образом, модуль услуг представления на рабочей станции можно считать ответственным за дружественный интерфейс с распределенными приложениями. Договорённость об особенностях интерфейса – также очень важный момент, который стоит учитывать на этапе согласования требований.

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

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

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

     -Цель продукта

     -Классы  пользователей

     -Описание  функций

     -Внешний  интерфейс 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     Рис.2. Общая архитектура клиент-сервер. 

     Базы  данных.

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

     Популярным  примером такой логики является язык структурированных запросов (Structured Query Language, SQL).

     Рис.3. Архитектура клиент-сервер для баз данных. 

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

     Клиент-серверная  система управления базой данных может опираться на несколько  типов распределения обязанностей между клиентом и сервером:

     -«интеллектуальные» клиенты;

     -«интеллектуальный» сервер;

     -смешанные системы;

     -многоуровневые системы.  

     Схему реализации выбирают на основе анализа  требований к:

     -сетевому графику;

     -ресурсам клиента и сервера;

     -производительности базы данных. 

     «Интеллектуальные»  клиенты 

     Это один из самых распространенных методов  реализации клиент-серверных приложений. «Интеллектуальному» клиенту можно доверить выполнение как бизнес-логики, так и сервисов представления данных.  

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

     Достоинства «интеллектуальных» клиентов

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

       Наличие хорошо известных и  достаточно мощных средств разработки (например, Visual Basic 5.0).

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