Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 77
Текст из файла (страница 77)
Вспомогательная программа должна автоматически фиксировать все изменения формулировки требования, а такжс значений его атрибутов. Как только программа обнаруживает изменение, опа автоматически фиксирует его. Кроме того, автоматически записывается автор, дата и время изменения. Программа также должна предоставлять возможность вводить описание изменения. Как правыло, ввод«тся одп<гдва предложения, чтобы объяснить, почему было сделано изменение, сослаться па другис документы, имеющие отношение к этому изменению, и т.д.
Докуысытиро. вапыс измспспыя позволит впоследствии вспомнить мотивы сто внесения. Это очень важно при любой проверке тех изменений, которые влияют на возможпыс претензии, эффективность ц безопасность изделия ы его программного обеспечения. На рис. 34.7 представлена распсчатка фрагмента истории изменений требования БК5 (3К4.4).
Отметим, что ысторня изменений организована в обратном хронологичсскол< порядкс и содержит записи изменений как текста (1.0001 в сравнении с 1.0000). так и значений отдельных атрибутов. Изменения текста могут быть как псзпа п<тсльпымц (например, пзмснснпе пунктуации), так и более существенными (как в слу <ас ЯК4.4). В любом случае всякое измсысние должно надлежащим образом фнксыровагьсв автоматичссю<м средством управления изменениями. Управление конфигураиией и управление изменениями История изменений должна существовать на трех уровнях детализации проекта. 1. При самой подробной детализации в нстор<по ыэмснспнй ваш мыкаются всс изменения каждого отдельного требования.
Этот уровень детализации отражен на рнс. 34.7. 2. На срсдцсм уровне следует автоматичсскн вести аналогичную историю изменений для каждого документа проекта. История па уровне документов обычно ведется системой контроля исходного кода или сыстсмой контроля документов. 3.
На об<цсм уровне нсооходимо автоматически вести историю изменений проекта в целом. Проект и архивы могут полностью включаться в систему управления конфнгура« и ей. Другими слонами, необходим набор вспомогательных средств, обеспечивающих паши» стью автоматическую всеобъемлющую и естественную интеграцию со стандартными прил<» жеп и я ми, которые будут помогать в решении задач управлсшщ конфигурацией, вози пкиощих прп выполнении крупных проектов разработки программного обеспечения. Глава 34. Управление изменениями 3ББ ВП4.4 изменив ммпа щмм:ьоюз к л Оьмнььмт дан Вй4.
Текст; Подтверждение приема сообщения. В ответ на получение сообщения от Управления включением (пульта), ЦБУ (СОН) должен послать следукицее сообщение: Пощ( НО(($ ССЦ БПБ Типтребоввния: Местоположение: Трвссируатся от: Трассируется к: Атрибуты Исправления: 04 19 9 06 АМ выполнвг н Значителыюе изменение требования дш удобсна тестирования. Изменен текст требования. Подтверждение приема сообщения. В ответ нв получение сообщения от Управления включением (пульта), ЦБУ (ССЦ) должен послать следующее сообщение: 1 0001 Описание изменения: 04/1 Б:32 РМ выполнил; он Требование создано.
СЛОЖНОСТЬ: <нвт ввода >-Сред. ПРИОРИТБТ: <нет ввода>-Сред, СТАБИЛЬНОСТЬ: <нет ввода>-Сред. СТАТУС: <нет ввода>-Подтвержд. Контрольная сумме. Контрольная сумма дли сообщения вычисамтся и проверяется по стандарту СПС2.3.
1.0000 Описание изменения Текст Рнс. >е. 7. Истлорьщ изменений Ш4.4 Заключение Безусловно, по мере развития проекта требования будут меняться, но этп изменения нс обязательно дестабплнзирузот процесс разработки. Если создан всеобъемлющий процесс контроля изменений, а артефакты требований подконтрольны нспольз)смой комазтдой разработчиков системе управления конфигурацией, команда будет хорошо подготовлена к рсшсньпо основных задач управления изменениями. Важно понимать, что управлеиис изменсниями в крупном проекте обычно является слишком объемной задачей, чтобы ес можно было решать вручную. ((собходньт тз)>пиес<, чтобы контролировать, каким образом нзлкспсния попадают в проект.
Такжс необходимы автоматические средства для того, чтобы понятна Разветтткккттнл изменения, т.с. найти все затронутые им члементы проекта. 366 Часть 6. Построение правильной системы Часть 6, "Построение правильной системы", завершает переход от понимания проблемы к реализации системы-решения. Спроектировать и реализовать правильную систему достаточно сложно. Один из методов состоит в том, чтобы использовать требования и прецеденты для создания архитектуры и проекта реализации. Мы также обсудили верификацию, аналитический подход, который позволяет постоянно отслеживать эволюцию функций, требований, проекта и реализации системы.
Поддержка верификации осуществляется с помощью методов ифло сирокко, которые позволяют связать друг с другом части проекта. Методы трассировки позволяют убедиться, что все необходимое в проекте присутствует и учиты касте в. С их помощью можно также исключить ненужные элементы. Хотя верификация является аналитическим методом, необходимо помнить о важности ~Минывыений, нельзя ограничиться чисто механическим применением методов верификации. Евге одной составной частью подхода, призванного подтвердить корректность создаваслюй системы, является гфозсрха гфавгыьноиаи 1'оайФабов).
В данном случае выполняются действия по тестированию и применвютсв л~етоды трассировки, чтобы убедиться, что система соответствует нредъявляслгым к ней требованиям. Затем проводятся приемо. сдаточные испытания, призванные продемонстрировать, что в среде заказчика система работает так, как нужно, и действительно решает поставленную проблему. Чтобы решить, какая часть системы нуждается в верификации и проверке правильности и в каком объеме, производится оценка и анализ рисков, Затраты на эти дсйствив следует контролировать с помощью анализа дивидендов (КО1).
Паконец, критически важным аспектом построении правильной системы валяется процесс управления изменениями. Изменения — это жизнь; их можно и нужно гшаньфовашь и оэрабашывашь Управление изменениями дает уверенность в том, что создаваемая система является правильной и, более того, будет правильной и в дальнейшем. По окончании части б можно переходить к последней главе. Глава 35 поможет вам применить приобретенные навыки и взять хороший старт в вашем следующем проекте. Глава ЗБ С чего начать Посвящение На протяжении многих лет мы (все, кго внес свой вклад в появление этой книги) обучили тысячи студентов, интересующихся вопросами управления треоованиями, а также сами многому научились у иих.
Как известно, не существует единственно верного способа осуществления управления требованиями. Ни один метод выявления требований ис является универсальным; ии один процесс пе подойдет всем без исключения ко. мапдам. Проекты очень отличаются по уровню сложности и масвзтабу. Приложения имеют совершенно различное содержание и относятся к разным отраслям. Управление требованиями — очень обширная и глубокая тема. В аудитории постоянно возникает чувство, что студенты ощузцают потребность в более четко определенном процессе; если хотитс, иском рецепте применения пол) лепных иа занятиях знаний.
"Вы рассказали нам слишком много, — говорят оии. — Укажите иам один основной процесс, от которого можно оттолкпуп ся. Мы знаем, что это непросто, ио мы будем счастливы при необходимости модифицировать его применительно к нашему проекту. Опшяитс четкий пошаговый процесс, чтобы мы могли более успению прилшиить то, чеъсу научились. Сказки то зке наконец, с чего нпчазпъг' Даяния глнвп носояэгагшся эшгък снзудгнзпом и зягм, кпю)шздсяягш их томку зргзснл, чему мы научились Итак, подведем итог того, что мы изучили в данной книге.
Введение В главах введения обсуждалась проблема, которая состоит в том, что в навей отрасли зачастую ие удается создать качественные приложения в срок и в рамках бюджета. Неко» торые причины этого известны. ъ1агле всего среди проблем, с которыми столкнулись ие достигшие своих целей проекты, упоминаются нгдоспюпюк зснфо)змаг~ззн от зшлъзооапмвя, неполные ззфгбовптш и спек ифззказ)изь а такзкг изменения гп)згбооаяиз1 и сззгииф~зкапзт. Возможзго, это происходит потому, что зачастую разработчики и заказчики считают, что "даже если мы цс очень точно знаем, чего хотим, лу ппс побыстрее приступить к реа. лизации, так как мы и так выбились из графика и нам некогда.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
