close

Вход

Забыли?

вход по аккаунту

;pptx

код для вставкиСкачать
Часть 2. Понимание потребностей пользователей
Глава 25
Спецификация требований
к программному обеспечению
(Modern Software Requirements
Specification)
Основные положения
Пакет спецификаций требований к программному обеспечению (Modern
SRS Package) представляет собой набор артефактов, полностью описывающих внешнее поведение системы. Он создает концептуальную модель
создаваемой системы.
Документ-концепция (Vision document) служит исходной информацией
для создания Modern SRS Package. Он определяет потребности пользователей, цели, задачи, целевые рынки и функции системы, в то время как в
пакете Modern SRS Package основное внимание уделяется деталям реализации этих функций.
Сбалансированный подход, как правило, заключается в совместном использовании модели прецедентов и традиционной спецификации требований.
После уточнения понимания системы настало время разработать стратегию организации и документирования требований. Хотя большая часть усилий в этом процессе действительно направлена на организацию выявленных и детализированных требований к
программному обеспечению, документов, прецедентов и моделей, самым важным является то, что совокупность данных артефактов представляет полную концептуальную модель
создаваемой системы.
Говоря коротко, для начала у нас есть части относительно полной концептуальной
структуры, с помощью которой мы можем рассуждать о будущей системе. Скорее всего, ее
еще нельзя потрогать (хотя, возможно, мы уже видели некоторые раскадровки и прототипы), но уже можно начать ее анализировать и проверять наше понимание системы, несмотря на то что она до сих пор существует только на бумаге и в виде моделей. Можно
сказать, что мы подошли к важному рубежу: созданию концептуальной модели или посредника (proxy) системы, которую надо построить.
254
Часть 5. Уточнение определения системы
Пакет спецификаций требований
к программному обеспечению
(Modern SRS Package)
Исторически сложилось, что наиболее популярный метод документирования требований состоял в упорядоченной их записи на естественном языке. Этот метод пересматривался и совершенствовался в ходе выполнения множества проектов, и постепенно был
разработан ряд стандартов для подобных документов, в том числе стандарт IEEE
(Institute of Electrical and Electronics Engineers) 830: Standard for Software Requirements
Specification (1994).
Но сегодня при наличии современных инструментальных средств и методов мы
предпочитаем представлять спецификацию программных требований (SRS) в виде логической структуры, а не физического документа. Различные детально описанные требования к системе заключаются в пакет, который мы называем современным пакетом спецификаций требований к программному обеспечению (Modern Software Requirements
Specification Package), в отличие от более ранних форм, которые именуются просто SRS.
Пакет Modern SRS Package связан с документом-концепцией, который служит исходной
информацией для его создания.
Однако эти два артефакта служат разным целям и, как правило, пишутся разными авторами. На данной стадии проекта акцент смещается от общей формулировки потребностей пользователя, целей, задач, целевых рынков и функций системы к детальному описанию того, как эти функции предполагается реализовывать в решении. На рис. 25.1
схематически представлены элементы пакета.
На данном этапе нам нужен пакет информации, полностью описывающий внешнее
поведение системы, т.е. набор артефактов следующего содержания: “Вот то, что система
должна делать, чтобы предоставить эти функции
”. Это и есть Modern SRS Package.
Нет веских причин уделять внимание различиям между используемыми инструментальными средствами. В конце концов, мы собираем требования и должны обращать внимание на эффективность их сбора и организации безотносительно к тому, какие средства используются. Итак, мы будем предполагать, что набор требований образует пакет информации. Поэтому на рис. 25.1 изображены не только
элементы этого пакета, но и их связи.
Пакет Modern SRS Package — это не том замороженной информации, созданный в соответствии с требованиями ISO 9000, который затем положат на полку при продолжении
проекта. Это активный “живой” пакет, во многих случаях играющий чрезвычайно важную роль при переходе к реализации.
Он служит основой для общения между всеми сторонами-участниками: между самими разработчиками, между разработчиками и внешними группами, пользователями и другими заинтересованными лицами.
Формально или неформально, он представляет соглашение между этими различными сторонами: если чего-то нет в пакете, разработчики не должны над этим работать. А если это в пакете есть, они отвечают за то, чтобы предоставить данную
функциональную возможность.
Глава 25. Спецификация требований к программному обеспечению...
255
Потребности
пользователей
Документ&концепция
SRS
Modern SRS Package
Функции
Программные
требования
Модель прецедентов
Документ(ы) требований
x
x
Ok
x
Ok
x
Ok
Ok
x
Ok
Модель
проектирования
Модель
тестирования
Требования
проектирования/тестирования/документирования
Документация
и материалы
конечного пользователя,
а также учебные
материалы
Рис. 25.1. Элементы Modern SRS Package
Он служит в качестве справочника стандартов для администратора программного
изделия. Скорее всего, у него не хватит времени, чтобы читать созданный разработчиками код и сравнивать его непосредственно с документом-концепцией; он
должен использовать данный пакет в качестве стандарта при обсуждении вопросов с командой разработчиков.
Как уже отмечалось ранее, пакет служит исходной информацией для групп, выполняющих проектирование и реализацию. В зависимости от того, как организован проект, люди, занимающиеся реализацией, могли ранее привлекаться к действиям по анализу проблемы и определению функций, что привело к созданию документа-концепции. Но им нужен именно Modern SRS Package, чтобы принять
решение о том, что должен делать их код.
Modern SRS Package служит исходной информацией также для групп, выполняющих тестирование и гарантирующих качество (QA). Эти группы также
следует привлекать к определенным действиям на более ранних этапах, и им,
безусловно, нужно понимать концепцию, лежащую в основе Vision-документа.
Но их основная задача — создать тестовые примеры и QA-процедуры, чтобы
гарантировать, что разработанная система действительно выполняет отраженные в Modern SRS Package требования. Пакет служит в качестве стандарта
при планировании и выполнении тестов.
256
Часть 5. Уточнение определения системы
Modern SRS Package управляет развитием системы на фазе построения; когда
функции документа-концепции модифицируются или когда в него добавляются
новые функции, они детализируются в данном пакете.
Кто отвечает за Modern SRS Package
На самом деле не так уж важно, кто пишет пакет. Гораздо важнее, чтобы
Modern SRS Package существовал и являлся основой для предстоящих
действий по построению и тестированию.
Возникает естественный вопрос: кто отвечает за создание и поддержку компонентов
Modern SRS Package? Обычно члены команды разработчиков самостоятельно берут на себя эту задачу. Команда разработчиков кровно заинтересована в полном понимании пакета и всех его требований и, владея им, может соответствующим образом влиять на многие системные решения. В конечном итоге, кто может лучше написать требования к программному обеспечения, чем люди, которые затем будут отвечать за соответствие им?
Часто за эту задачу (в качестве детальной доработки документа-концепции) берется системный аналитик, в других случаях тестологи работают рука об руку с командой проекта
и берут на себя ответственность за требования.
Каждый подход имеет свои плюсы и минусы, и каждая команда сама будет решать, какая стратегия наилучшая. Из опыта следует, что если к пакету относиться серьезно, не
так важно, кто его написал, хотя и есть некоторая разница в том, отвечает ли за него руководство или команда. Действительно важно то, что Modern SRS Package существует и
является основой для дальнейших действий по разработке и тестированию.
Конечно, авторы SRS не пишут требования в вакууме. Мы обнаружили, что пересмотр
данного пакета — наиболее эффективный шаг, позволяющий убедиться, что разработчики, маркетологи, пользователи и другие участники “поют под одну и
ту же музыку”. Modern SRS Package — “живой” артефакт, который нуждается в обновлениях по мере того, как развивается проект и становятся более понятными различные функции. Никогда не следует допускать, чтобы написанный пакет впоследствии и
гнорировался.
Организация пакета Modern SRS Package
Для большой системы пакет Modern SRS Package может быть весьма объемным. Он
может состоять из сотен страниц текста и диаграмм прецедентов, а также содержать
множество детальной информации, которой разработчики должны
уделить пристальное внимание. Но если пакет правильно написан и
хорошо организован, его размеры не будут помехой при использовании; они только будут свидетельствовать об относительной сложности
создаваемой системы.
Итак, возникает вопрос: как следует организовать пакет? Например,
если в команду приходит новый разработчик и получает задание работать над функцией XYZ,
где ему искать детальное описание этой функции? Или предположим, что администратор
проекта уходит в самый разгар работы; как новый администратор может быстро войти в курс
дела и вникнуть в детали управления текущей деятельностью команды проекта?
Глава 25. Спецификация требований к программному обеспечению...
257
Понятно, что структура пакета должна отвечать природе приложения и организации.
Пакет для разработки текстового процессора в компании по производству программного
обеспечения в Силиконовой долине, вероятно, будет несколько отличаться от аналогичного пакета для системы управления авиаполетами. Нас волнует не то, сможет ли эксперт
по управлению полетами посетить программистскую фирму в Силиконовой долине и
объяснить, что в действительности означают его SRS. Нас заботит, чтобы разработчики
и пользователи внутри конкретной организации могли объяснить смысл созданных SRS,
чтобы их пакет оставался актуальным на протяжении всей разработки, а также при сопровождении системы после того, как она поступит в производство.
Если организация желает при аттестации достичь более высокого уровня по шкале SEICMM или получить сертификат ISO 9000, она более заинтересована в стандартизации организации и формата своего пакета. Даже без оглядки на CMM и ISO, ранее приведенные примеры иллюстрируют выгоды стандартизации: возможность быстрее вникнуть, когда имеется
текучесть кадров или в команду приходит новый человек. Она также позволяет гарантировать, что важнейшая информация не потеряется и все будут знать, где ее искать.
Следует помнить, что пакет Modern SRS Package не предназначен для того, чтобы его читали как роман от начала до конца. Это скорее справочник, и каждый разработчик будет, как
правило, просматривать только необходимые ему разделы. Таким образом, нужно так организовать SRS, чтобы можно было легко и просто находить нужную информацию.
Пакет должен подчиняться некой организационной концепции. Мы пришли к выводу, что следующая организационная схема неплохо подходит практически для всех типов
проектов. Эта схема вместе с комментариями, поясняющими некоторые детали структуры, приводится в приложенииВ.
Общая информация
История пересмотров
Содержание
1.
Введение
1.1. Цель
1.2. Масштаб
1.3. Ссылки
1.4. Предположения и зависимости
2. Краткая характеристика модели прецедентов
3. Краткая характеристика акторов
4. Требования
4.1. Функциональные требования
4.2. Нефункциональные требования
4.2.1. Практичность
4.2.2. Надежность
4.2.3. Производительность
4.2.4. Возможность сопровождения
5. Требования к интерактивной пользовательской документации и системе подсказок
6. Ограничения проектирования
7. Закупаемые компоненты
8. Интерфейсы
8.1. Пользовательские интерфейсы
258
Часть 5. Уточнение определения системы
8.2. Аппаратные интерфейсы
8.3. Программные интерфейсы
8.4. Коммуникационные интерфейсы
9. Требования лицензирования
10. Примечания об авторских правах и т.п.
11. Применяемые стандарты
Индекс
Глоссарий
Приложение. Спецификации прецедентов
История пересмотров прецедента
Дата
Версия
Описание
Автор
Название прецедента
Краткое описание
Потоки событий
Основной поток
Альтернативные потоки
Первый альтернативный поток
Второй альтернативный поток
Специальные требования
Первое специальное требование
Второе специальное требование
Предусловия
Предусловие 1
Постусловия
Постусловие1
Точки расширения
Название точки расширения
Другие материалы прецедента
Документирование функциональных
требований
Итак, рассмотрим, чего мы достигли.
Мы пришли к решению, что документацию системных требований следует организовать в видепакета артефактов.
Эти артефакты могут состоять из текстовых документов, таблиц, схем, прецедентов и других элементов, помогающих разработчикам понять, что хочет клиент.
Мы создали шаблон структуры пакета Modern SRS Package. Данный шаблон позволит организовать и распределить по категориям различные элементы, но основное внимание в нем уделяется текстовым элементам (таким, как спецификации на
Глава 25. Спецификация требований к программному обеспечению...
259
естественном языке отдельных требований) и элементам в виде прецедентов
(представление которых включает в себя графическую модель прецедентов и их
текстовые описания).
Для сбора требований можно применять как традиционные методы спецификации
требований, так и метод прецедентов. Каждый из этих методов сам по себе использовался в тысячах успешных проектов. Но как оптимизировать нашу работу? Какой метод следует применить в каждом конкретном случае?
Что касается спецификации функциональных требований к системе, мы пришли к
выводу, что наилучшим подходом является совместное использование моделирования
прецедентов и традиционных спецификаций требований. Рассмотрим “баланс требований”, представленный на рис.25.2.
Традиционные спецификации
Характеристики команды
Характеристики проекта
Научные или
Хорошо владеет
алгоритмические системы
традиционными
методами
Встроенное управление,
вспомогательные процессы
Мало знакома с
моделированием
Однопользовательские
прецедентов
системы
“Мягкие” функциональные
требования
Много ограничений
проектирования
Традиционный формат
требует заказчик или
регулирующий орган
Моделирование прецедентов
Характеристики проекта
Бизнес&системы
Многопользовательские
системы
Жесткие
функциональные
требования
Немного ограничений
проектирования
Нет обязательных
требований по
стандартам
документации
Характеристики команды
Значительный опыт
в моделировании
Опыт работы с
объектно&
ориентированными
технологиями
Рис. 25.2. Баланс требований
Отметим, что существует множество возможных вариантов. Некоторые проекты характеризуются незначительным числом (или полным отсутствием) спецификаций, которые можно сформулировать с помощью прецедентов. Эти проекты отличаются высоким
удельным весом вычислений и алгоритмов; примерами могут служить системы расчета
прогноза погоды или научные системы. Еще одной крайностью являются проекты разработки систем, предназначенных для удовлетворения функциональных потребностей
пользователей. Такие системы обычно делают уйму вещей для пользователя. Кроме того,
система может обслуживать различные типы пользователей, для описания чего идеально
подходит метод прецедентов.
260
Часть 5. Уточнение определения системы
Необходимо также учитывать, какими профессиональными навыками обладает команда проекта. Некоторые команды не имеют опыта (или имеют незначительный опыт)
в использовании прецедентов и объектно-ориентированных методов. Другие команды
владеют этими методами в совершенстве.
Чтобы использовать представленный на рис. 25.2 “вид с точки зрения баланса”, нужно просто заполнить окна флажков, соответствующие характеристикам вашего проекта и
навыкам вашей команды. В зависимости от того, в какую сторону склонится чаша весов,
можно планировать, какой метод документирования требований выбрать.
В любом случае Modern SRS Package позволяет сочетать лучшие качества моделирования прецедентов и традиционных методов спецификации требований. Задача состоит
в том, чтобы найти правильное их сочетание для вашего проекта и команды. Как следует
из нашего опыта, необходимо внимательно рассмотреть следующие моменты.
Возможности организации
Общие тенденции программных процессов и методов, принятых в организации
Внешние факторы, такие как требования инструкций и другие ограничения
Конкретное содержание проекта
Только после этого можно выбрать определенный метод или комбинацию методов.
Разобравшись в этих факторах, команда сможет выбрать верный работоспособный баланс, а затем двигаться к наиболее эффективной комбинации, если это возможно.
Далее…
Пакет Modern SRS Package является мощным средством отражения потребностей проекта. Однако написать такой пакет непросто. Как и всему
остальному, написанию хороших спецификаций требований к программному обеспечению нужно учиться. В следующей главе рассматриваются
некоторые проблемы, с которыми приходится сталкиваться, когда мы
стремимся написать ясный, не допускающий неоднозначных толкований
набор спецификаций.
1/--страниц
Пожаловаться на содержимое документа