Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 89
Текст из файла (страница 89)
Прецедент должен описывать, чяю происходит внутри системы, а не как или почему это происходит. Если происходит обмен информациеы, то нужно указать, какзл инфор. нация поступает, а какая — отпранлястся. Кроме того, пе очень понятно, что имеется в выду, если сказать, что актор вводит информацию о клиенте; лучше сказать, что актор вводит имя и адрес клиента.
Для того чтобы не делать прецедент очень сложным и нс запутаться в деталях, полезно использовать глоссарий, где можно определить, что понимается под информацией о клиенте. Простые альтернативы можно описать в тексте прецедента. Если для описания того, что происходит в альтернативном случае, достаточно нескольких предложений, следует сделать это непосредственно в разделе, посвященном основному потоку событий. Если альтернативные потоки более сложные, нужно ыспользовать отдельный раздел (Лльтсрпативпыс потоки).
Иногда рисунок ыпформативнее тысячи слов, хотя ничто не заменит чистой и ясной прозы. Если это поможет добиться большей ясности, можно включать в прецедент графические описания интерфейсов потьэоватсля, потоков процессов или другие рисунки. Если для представления сложного процесса принятия решения необходимо использо. вать формлльпые средства спецификациы, такие как диаграммы дсятельности, песомпсппо, это следует делать! Аналогично, если поведение системы зависит от состояния, то диаграмма перехода состояний лучше прояснит его, чем это сделают страницы текста. Используйте представление, которое лучше всего подходит для вашей проблемы, но Приложение В. Образец пакета Мобегп Шб Расйабе 417 будьте осторожны с терминологией, обозначениями или рисунками, которые могут быть непонятны вашей аудитории.
Помните, что ваша задача — прояснить, а не запутать. Альтернативные потоки 1. Первый альтернативный поток. Более сложные альтернативы следует описывать в отдельном разделе. Следует воспринимать альтернативные потоки как зари. анти алътернагггненого ноеедения; каждый альтернативный поток представляет некое альтернативное поведение (вариантов много из-эа исключительных ситуаций, возникающих в основном потоке). Они могут быть произвольной длины, которая требуется для описания связанных с альтернативным поведением событий. Когда альтернативный поток заканчивается, события основного потока продолжаются, если ие оговорено противное.
Альтернативные потоки могут, в свою очередь, также состоять из подразделов. 2. Второй альтернативный поток. Достаточно часто в прецеденте встречается несколь. ко альтернативных потоков. Для большей ясности следует описывать каждую альтернативу отдельно. Использование альтернативных потоков упрощает понимание прецедента, а также предотвращает декомпозицию прецедентов на иерархии прецедентов. Следует полгнить, что прецеденты — зто только текстовые описания, и их главная зада. ча в том, чтобы документировать поведение системы ясно, сжато и понятно.
Специальные требования Здесь обычно приводятся имекипие отновзение к данному прецеденту нефункцио. нальиые требования, которые непросто описать в тексте потока событий прецедента Примерами таких требований могут служить требования законодательства и инструкций, применяемые стандарты, атрибуты качества создаваемой системы, в точ числе требования практичности, надежности, производительности или возможности сопровождения. В данном разделе следует также фиксировать другие требования. такие как описание операционных систем и сред, требования совместимости и ограничения проектирования.
1. Первое специальное требование Предусловия Предусловие прецедента — это состояние системы, в котором она должна находиться перед началом выполнения прецедента. 1. Предусловие 1 Постусловия Постусловия прецедента — зто перечень возможных состояний системы непосредст. вепио после завершения прецедента.
1. Постусловие 1 Точки расширения Точки раснгирепия прецедента. 1. Название точки расширения Определение местоположения точки расширения в потоке событий. Приложение Г Принципы управления требованиями в стандартах ЯЕ1-СММ и 1ЯО 9000 Принципы управления требованиями в стандарте ЯЕ1-СММ В ноябре 1986 года в Институте программирования (8оймаге Епя)пеег)пй 1пзгйосе, 8Е1) при Университете Карнеги. Меллон (Сагпе81е.Мейоп ()п1тегйгу) была предложена концепция совершенствования процесса разработки, которая была призвана повысить качество процесса программирования. В сентябре 1987 года ЬЕ1 выпустил краткое описание структуры процесса, получившей дальнейвгее развитие в работе Уотса Хамфри (Ъуаггз НишрЬгеуз) Мппорп8гИе 5о/)гиаге Ргосезз (1989).
К 1991 году развитие данной концепции привело к появлению "модели повышения уровня зрелости процессов разработки программного обеспечения" (Сарасййгу Ма~ог1гу Моде!, СММ), версия 1.0. В 1993 го. ду была выпущена версия 1.1 СММ (5Е1 1993). В этой версии было определено пять "уровней зрелости" процесса разработки программного обеспечения в организации и предложены пути перехода от более низкого уровня к более высокому, как показано иа рис. Г.1. СММ определяет для разработчиков набор действий.
выполнение которых поможет организации усовершенствовать процесс программирования и добиться повторяемости, управляемости и измеримости. Несмотря на продолжающиеся дебаты относительно преимуществ и недостатков СММ, накопленные данные свидетельствуют, что, следуя СММ, многим компаниям удалось повысить качество программирования и значительно снизить затраты яа разработку приложений. Стандарт СММ достаточно давно использ)ется многими организациями, так что существует статистика положительных результатов его применения. В идеале эти преимущества должны приводить к повышению производительности и значительному сокращению времени до выхода продукта на рынок. В условиях возрастания конкурен. ции нельзя игнорировать никакие усовершенствования, которые могут привести к пс» вышению производительности процесса разработки программного обеспечения.
Стандарт СММ предлагает для соверглепствования процесса структуру, состоящую из "ключевых областей процесса" или видов деятелыгости, которые, как следует из опыта, оказывают влияние на различные аспекты процесса разработки и качество программного обеспечения. В табл. Г.1 представлены ключевые области процесса для каждого из пяти уровней СММ. (Мы рассматриваем эту таблицу в данной книге потому, что в пей в качестве первой ключевой области процесса, которой необходимо уделить внимание для пе.
рехода с уровня 1 на уровень 2, названо управление требованиями.) 420 Прилолсеиии Уровень 5 Рис. ГЛ. "Урсниси зрелости", создастся СММ Таблица Г.1. Уровни СММ н ключевые области процесса Уровень Не выделяются 1. начальный. Разработка осуществляется произвольно(даже хаотично); успех зависит исклю. чительно от индивидуальных героических усилий 2. Повторяемый.
Осуществляется базовое управление проектом с целью отслеживания функциональных возможностей прило. жсиия, затрат и графика 3. Определенный. Пропесс управления и прсскгироВзиня является целоспиаи, ста~дартизоюнным и документированным. Все проекты ссутцествля ются на основе проВерениой, приспособленной к конкретной задаче версии процесса Ключевые области процесса Управление требованиями Планирование разработки программного обеспечения Отслеживание и контроль разработки программы Управление программными субконтрактами Обеспечение качества программного обеспечения Управление конфигурацией программного обеспечения Фокусировка организационного процесса Определение организационного процесса Программа обучения Всеобъемлюнсее управление программированием Инженерия программного обеспечения Координация деятельности различных групп Тщательно организованный промежуточный контроль Приложение Г.
Принципы управления требованиями в стандартах... 421 Околлчпиие ллмбе, Г.1 Уровень Ключевые области процесса Управления процессом на основе количественного анализа Управление качеством программного обеспечения 4. Управлнемый. Производятся оценки характеристик пронсссз программирования и показателей качества программного обеспечения. Как процесс, так и программный продукт понятны н управляемы 5.
Оптимизврующнй. Постоянное совершснстаоаанпе процесса обеспечивается путем испольлоюпия петрик и внедрения инновационных идей н технологий Предупреждение дефектов Управление технологическими изменениями Управление изменениями процесса Стандарт СМ М характеризует деятельность по управлению требованиями следующим образом. Цель уллравления жреб еаниямп соспюиил е досошзкенет общего понимлллил между закпзчнлом и командой лфогроммисглим е тач, чмо касаемся плфебоооллии зпкпзчпка.
Это общее понимание служит основой соглашения между заказчиком и колландой разработчиков, которое является основным документом, определяющим все последующие действия. Формируется Йиоеыи у(зоеень гп)лебовонии, на основании которою осуществля. ется управление разработкой программно~о обеспечения. Стандартом СММ предусматривается, чтобы все планы, графики и рабочие программные продукты разрабатывалась и, если нужно, модифицировались в соответствии с требованиями, налагаемыми на програмлпюе обеспечение. Таким образом, СММ способствует продвижению организации к целостному представлению, в котором технические требования лолжны находиться в соответствии с планами и действиями по разработке.
Для осуществления поддержки дан. ного процесса менеджеры программного обеспечения и заинтересованные лица (включая представителей заказчика и пользователей) должны документировать и пересматривать требования к программному обеспечению. Спецификация програллмных требований является основным документом, который играет определяющую роль по отношению к другим элемеиталг плана разработки. Среди требований есть как технические (поведение приложения), так и нетехнические (нро ще требовшлия к разработке, включая график, бюджет и т.п.).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
