В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 17
Текст из файла (страница 17)
Для представления остальнойинформации каждый вариант использования может дополняться набором разнообразныхдиаграмм UML — диаграммами деятельностей, диаграммами сценариев, и пр. Обо всех этихвидах диаграмм будет рассказано в лекции, посвященной архитектуре программного обеспечения.ЗаказДатаСтоимостьЗаказанный товарКоличество единицТоварНаименованиеЦена за единицуТовар у поставщикаКлиентИмяАдресПоставщикЦена за единицуРазмер партииСтоимость доставкиНазваниеАдресРеквизитыРисунок 19. Модель сущностей и связей.52Выделение и анализ требованийПосле получения общего представления о деятельности и целях организаций, в которых будетработать будущая программная система, и о ее предметной области, можно определить болеечетко, какие именно задачи система будет решать.
Кроме того, важно понимать, какие из задачстоят наиболее остро и обязательно должны быть поддержаны уже в первой версии, а какие могутбыть отложены до следующих версий или вообще вынесены за рамки области ответственностисистемы. Эта информация выявляется при анализе потребностей возможных пользователей изаказчиков.Потребности определяются на основе наиболее актуальных проблем и задач, которыепользователи и заказчики видят перед собой.
При этом требуется аккуратное выявление значимыхпроблем, определение того, насколько хорошо они решаются при текущем положении дел, ирасстановка приоритетов при рассмотрении недостаточно хорошо решаемых, поскольку чащевсего решить сразу все проблемы невозможно.Формулировка потребностей может быть разбита на следующие этапы.1. Выделить одну-две-три основных проблемы.2. Определить причины возникновения проблем, оценить степень их влияния и выделитьнаиболее существенные из проблем, влекущие появление остальных.3. Определить ограничения на возможные решения.Формулировка потребностей не должна накладывать лишних ограничений на возможныерешения, удовлетворяющие им. Нужно попытаться сформулировать, что именно являетсяпроблемой, а не предлагать сразу возможные решения.Например, формулировки «система должна использовать СУБД Oracle для хранения данных»,«нужно, чтобы при вводе неверных данных раздавался звуковой сигнал» не очень хорошоописывают потребности.
Исключением в первом случае может быть особая ситуация, например,если СУБД Oracle уже используется для хранения других данных, которые должны бытьинтегрированы с рассматриваемыми: при этом ее использование становится внешнимограничением. Соответствующие потребности лучше описать так: «нужно организовать надежноеи удобное для интеграции с другими системами хранение данных», «необходимо предотвращатьпопадание некорректных данных в хранилище».При выявлении потребностей пользователей анализируются модели деятельностипользователей и организаций, в которых они работают, для выявления проблемных мест.
Такжеиспользуются такие приемы, как анкетирование, демонстрация возможных сеансов работыбудущей системы, интерактивные опросы, где пользователям предоставляется возможность самимпредложить варианты внешнего вида системы и ее работы или поменять предложенные кем-тодругим, демонстрация прототипа системы и др.После выделения основных потребностей нужно решить вопрос о разграничении областиответственности будущей системы, т.е.
определить, какие из потребностей надо пытатьсяудовлетворить в ее рамках, а какие — нет.При этом все заинтересованные лица делятся на пользователей, которые будутнепосредственно использовать создаваемую систему для решения своих задач, и вторичныхзаинтересованных лиц, которые не решают своих задач с ее помощью, но чьи интересы так илииначе затрагиваются ею. Потребности пользователей нужно удовлетворить в первую очередь и наэто нужно выделить больше усилий, а интересы вторичных заинтересованных лиц должны бытьтолько адекватно учтены в итоговой системе.На основе выделенных потребностей пользователей, отнесенных к области ответственностисистемы, формулируются возможные функции будущей системы, которые представляют собойуслуги, предоставляемые системой и удовлетворяющие потребности одной или нескольких групппользователей (или других заинтересованных лиц).
Идеи для определения таких функций можнобрать из имеющегося опыта разработчиков (наиболее часто используемый источник) или изрезультатов мозговых штурмов и других форм выработки идей.53Формулировка функций должна быть достаточно короткой, ясной для пользователей, безлишних деталей. Например:• Все данные о сделках и клиентах будут сохраняться в базе данных.• Статус выполнения заказа клиент сможет узнать через Интернет.• Система будет поддерживать до 10000 одновременно работающих пользователей.• Расписание проведения ремонтных работ будет строиться автоматически.Предлагая те или иные функции, нужно уметь аккуратно оценивать их влияние на структуру идеятельность организаций, в рамках которых будет использоваться ПО.
Это можно сделать, имеяполученные при анализе предметной области модели их текущей деятельности.Имея набор функций, достаточно хорошо поддерживающий решение наиболее существенныхзадач, с которыми придется работать разрабатываемой системе, можно составлять требования кней, представляющие собой детализацию работы этих функций. Соотношение между проблемами,потребностями, функциями и требованиями изображено на Рис.
20.Четкость,конкретность,полнотаПроблемыПотребностиФункцииТребования к ПОРисунок 20. Соотношение между проблемами, потребностями, функциями и требованиями.При этом часто нужно учитывать, что ПО является частью программно-аппаратной системы,требования к которой надо преобразовать в требования к программной и аппаратной еесоставляющим. В последнее время, в связи со значительным падением цен на мощное аппаратноеобеспечение общего назначения, фокус внимания переместился, в основном, на программноеобеспечение.
Во многих проектах аппаратная платформа определяется из общих соображений, аподдержку большинства нужных функций осуществляет ПО.Каждое требование раскрывает детали поведения системы при выполнении ею некоторойфункции в некоторых обстоятельствах. При этом часть требований исходит из потребностей ипожеланий заинтересованных лиц и решений, удовлетворяющих эти потребности и пожелания, ачасть — из внешних ограничений, накладываемых на систему, например, основными законамитой предметной области, в рамках которой системе придется работать, государственнымзаконодательством, корпоративной политикой и пр.Еще до перехода от функций к требованиям полезно расставить приоритеты и оценитьтрудоемкость их реализации и рискованность. Это позволит отказаться от реализации наименееважных и наиболее трудоемких, не соответствующих бюджету проекта функций еще до ихдетальной проработки, а также выявить возможные проблемные места проекта — наиболеетрудоемкие и неясные из вошедших в него функций.Правила работы с требования к ПО и более общими системными требованиями (к программноаппаратной системе), определяются следующими двумя стандартами IEEE.• IEEE 830-1998 Recommended Practice for Software Requirements Specifications [7](рекомендуемые методы спецификации требований к ПО).Описывает структуру документов для фиксации требований к ПО.54•Кроме того, он определяет характеристики, которыми должен обладать правильносоставленный набор требований.o Корректность или адекватность (соответствие реальным потребностям).o Недвусмысленность (однозначность понимания).o Полнота (отражение всех выделенных потребностей и всех возможных ситуаций, вкоторых придется работать системе).o Непротиворечивость (согласованность между различными элементами).o Упорядоченность по важности и стабильности.o Проверяемость (выполнение каждого требования нужно уметь проверять некоторымдостаточно эффективным способом — непроверяемые требования должны бытьудалены из рассмотрения или сведены к проверяемым вариантам).o Модифицируемость (оформление в удобных для внесения изменений структуре истилях).o Прослеживаемость в ходе разработки (возможность увязать требование с подсистемами,модулями и операциям, ответственными за его выполнение, и с тестами, проверяющимиего выполнение).IEEE 1233-1998, 2002 Guide for Developing System Requirements Specifications [8](руководство по разработке спецификаций требований к системам).Описывает правила построения требований для программно-аппаратных систем в целом.Он выделяет следующие необходимые свойства набора требований.o Однократное упоминание отдельных требований.o Отсутствие пересечений между требованиями.o Явное указание связей между требованиями.o Полнота.o Непротиворечивость.o Определение ограничений, области действия и контекста для каждого требования.o Модифицируемость.o Конфигурируемость, удобство поддержки.o Подходящий для определения системы уровень абстракции.Кроме того, следующие свойства считаются необходимыми для отдельного требования.o Абстрактность — формулировка, независимая от возможных реализаций.o Недвусмысленность.o Прослеживаемость.o Проверяемость.Стандарт предписывает определять следующие атрибуты для каждого требования.o Уникальный идентификатор.o Приоритет, важность реализации с точки зрения пользователей.o Критичность для построения и успешности системы с точки зрения аналитиков.o Осуществимость с точки зрения готовности пользователей к новой функции,имеющихся технологий и стоимости реализации.o Риски высокой стоимости, последствий использования для окружающей среды ипользователей, конфликтов со стандартами и законодательством.o Источник (т.е.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
