Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 64
Текст из файла (страница 64)
В данной части мы переходим от определения системы-решения к ее построению. Этот шаг наиболее сложный, и для его осуществления потребуется гораздо больше ресур. сов. В последующих нескольких главах мы рассмотрим, как на основании спецификаций (посредством прецедентов) выполнить проектирование и реализацию системы. Зачастую разработчики достаточно быстро переходят к построению системы и по ряду направлений достигают заметного прогресса.
Но в результате оказывается, что, несмотря на затраченные усилия, клиент так и не получил ту систему, которую ои хотел. В этой части книги мы хотим выйти за рамки действий по разработке и узнать: "Как апре. делить, что мы создаем "правильную" системузу'. Ответить на данный вопрос нам помогуг верификация и проверка правильности. Мы подробно рассмотрим, как включить эти методы в деятельность по реализации, чтобы заострить внимание на том, что действительно важно для проекта. Наконец, в процессе разработки никогда не удается избежать изменений.
Г1оэтовп в данной части исследуется природа изменений и обсуждаются такие способы их внесения и управления ими, которые позволяют не выпустить проект иэ-под контроля. Глава 29 Как правильно построить "правильн~" систему: общие положения ' Основные положении . ~": ° Для правильного' построения "правильной" системы йеобходимо''посте» ' -. янно убеждаться, что разработка проводится надлежащим образом,"ее ре-; зулътаты корректны, и обрабатывать возникающие в процессе разработки изменения.
° Верификация (тепйсайоп) позволяет удостовериться, что деятелъносгн ' разработки неизменно соответствуют потребностям клиента. . ° Проверка правилъности (та1Иайгоп) демонстрирует, что продукт соотвеэ., ...,; ствует предъявляемым к нему требованиям и конечный результат получает -, , ' .: одобрение эашичншь Л: ° .
Посколъку изменения неизбежны, следует учитывать это при плаиирова- ~ нии и знать, как нми управлять. Как мы уже неоднократно подчеркивали, крайне важно, чтобы каждый член команды понимал требования к проекту. Но на практике, к сожалению, невозможно ждать, пока абсолютно все станет ясно. Позтол~у мы описали методы итеративной разработки, котс» рые позволяют постепенно уточнять понимание системы по мере продвижения вперед. Но даже тогда проект, в котором до этого момента все шло хорошо, может разрушиться и превратиться в дезорганизованные действия. Причина в том, что команда уже понимаем требования, но еще ке в состоянии построить систему, которая удоэлежэ~фясж им.
В данной главе мы рассмотрим несколько важных дополнительных концепций. которые по зволят убедиться, что вы надлежащим образом строите "правильную" систему. Это подразумевает следующее. ° Необходимо постоянно убеждаться, что разработка находится на правильном пути. ° Необходимо убеждаться в корректности результатов разработки.
° Необходимо научиться обрабатывать изменения. возникающие в процессе раэрабопи. Рассмотрим каждый из этих пунктов более подробно. 296 Часть 6. Построение правильной системы Проверка того, что разработка находится на правильном пути При проектировании и реализации команда должна иметь возможность постоянно проверять, не сбился ли проект "с пути", т.е. соответствуют ли результаты разработки потребностям клиента. Постоянно выполняемый процесс проверки того, что каждый шаг разработки являег ся корректным, удовлетворяет потребности последующей деятельности и не является излишним, мы будем называть ве)зификацией (оеп11сабон). К сожалению, в отрасли имеег ся множество различных толкований того, что же собой представляет верификация.
Поэтому мы обсудим это важное понятие более подробно. Принципы верификации программного обеспечения Стандарт 1ЕЕЕ (1994) определяет верификацию следующим образом. П)Юцесс оценивання системы или компонента с целью олределкть, удовлевюсряют лн ~мзультаты некой фазы условиям, юхлозсенным в начале данной фазы (1ЕЕЕ 101 2-1 98б, у 2, 1994). Таким образом, верификация в значительной мере является аналитической деятель пастью, в ходе которой необходимо убедиться, что каждая стадия разработки (например, реализация в программном обеспечении одного или нескольких требований) соответст. вует заданным на предгядущей стадии требованиям. Как минимум, хотелось бы верифнцировать следующее. ° Описанные нами функции действительно соответствуют потребностям.
° Производные от этих функций прецеденты и требования действительно поддер. жнвают данные функции. ° Прецеденты реализуются при проектировании. ° Проектирование поддерживает функционюгь~гяе и нефункциональные аспекты поведения системы. ° Код действительно соответствует результатам и целял~ проектирования. ° Тесты обеспечивают полное покрытие разработанных требований н прецедентов. Итак, как узнать, что собой представляет пап~а разработка в целом) Нужен метод, ко. тарый позволит гарантировать, что мы провели верификацию всего необходимого (н ничего лишнего().
Для этого нужен план верификации и (желательно) некие автоматические средства, которые помогут выполнить его. Но самое главное, команде необходимо понять, что та. кое верификация, и взять на себя ответственность за ее проведение. Верификация — это не ннмьхо деятельность, осуществляемая группой обеспечения качества проекта ((1А 1еагп), которая, безусловно, играет огромную роль в этом процессе. Одним из методов осуществления постоянного контроля вернфикационных действий является офассиРовха (Ьисеай(йу).
Мы уже упоминали о трассировке в части 5, а в главе 31 обсудим, кэк ее можно использовать для ор~анизацни верифнкационпых действий. Глава 29. Как правильно построить "правильную" систему... 29» Независимо от того, как организована верификация, необходимо помнить, что суть ее в токи чтобы убедиться, что шаг, пад которым мы работаем, имеет соответствующую предысторию и выполняется непротиворечивым и надежным способом.
Более того, необходимо удостовериться, что каждое предпринимаемое нами действие необходимо, а ненужные п»аги отсутствуют. В значительной мере этому способствует применение эффективных процессов разра. ботки програк»много обеспечения, а также осуществление анализа. Например, можно исследовать требования и убедиться, что они корректно, полно и сжато выражают более высокоуровневые потребности пользователей.
Затем можно убедиться, что проектир»» ванне проводилось на основании требований и прецедентов и полученный технический проект является полным и не имеет лип»них элементов. В некоторых ситуациях анализ сокращается до п)з»»смея»)зоа и ревизий. В других случаях можно использовать модели и автоматизированные средства, чтобы проверить полноту, семантику и т,д. Напоминаем, что на данном этапе мы не пытаемся проверить работоспособность, мы займемся этим позднее. Сейчас же необходимо убедиться, что мы сделали то, что должны были сделать, и это следует логике разработки. Итак, достаточно отступлений.
Вернемся к обсуждению некоторых аспектов верификации. Затраты на верификацию Неприятным моментом верификации является то, что можно потратить время на верификационную деятельность, которая не принесет отдачи. Поэтому нужен некий спо соб вычисления "экономических дивидендов" (ге»пгп оп !птешпеп», КО1) верификационной деятельности. Необходим подход, который поможет п)»пеклььп вложить средства в проверку наших действий. Не хочется выполнять лишние проверки, но нельзя пропускать проверку жизненно важных аспектов.
В главе 33 содержится краткое описание методов оценки и анализа рисков и предлагаются рекомендации по использованию этих методов для зкономии средств при проведении проверок. Команда должна сконструировать н реализовать систему, соответствующую требованиям. Другими словами, команда должна иметь возможность убедиться, что планы реализации соответствуют потребностям. Но как на основании требований осуществить проектирование и реализацию? Нельзя же передать требования компьютеру и ожидать, что проектирование и реализация произойдут сами собой! В главе 30 рассматриваются способы перехода от разработки требований к проектированию и описывается, как можно использовать полученные в процессе создания требований артефакты при проектировании и реализации системы.
Верификация на всех уровнях Верификацию можно применять на всех стадиях жизненного цикла разработки; методы ие ориентированы на какую. либо одну фазу. Можно (и нужно!) верифицировать элементы требований, проектирования, реализации, тестирования и другие важные элементы разработки, основываясь на результатах КО1.анализа. В той или иной степени верификацией придется запиматыя на каждой стадии разработки.
Она необходима, чт»ь бы удостовериться в правильности следующих переходов. 298 Часть 6. Построение правильной системы ° От потребностей пользователя к функциям продукта ° От функций продукта к требованиям ° От требований к архитектуре ° От архитектуры к модели проектирования ° От модели проектирования к реализации ° От реализации к планированию тестов (Зазмчание. Мы будем рассматривать тестирование как часть проверки правильности (га1Ыайоп).) ' Хотелось бы вновь подчеркнузь, что верификация чрезвычайно важна на стадии проектирования, так как возникшие на этой стадии ошибки очень сложно устранять на стадии реализации.
Доводы в пользу верификации Мы рекомендуем во всех разработках проводить процесс верификации, который должен начинаться в начале разработки проекта и продолжаться иа протяжении всего ее жизненного цикла. При работе над проектом, в котором процесс разработки регулируется, верификацию, вероятно, придется проводить независимо от вашего желания. Верификация обязательна при разработке систем высокой надежности (систем жизнеобеспечения или таких систем, стоимость сбоя в которых недопустимо высока), в противном случае вы подвергаете недопустимому риску себя или других. Но каждый нетривиальный проект лилль выиграет от хорошо спланированной верификации. Проверка корректности результатов разработки По мере достижения важных вех (этапов) разработки, таких как исполняемые итерации, важно проверить правильность созданных функциональных возможностей, т.е.
убедиться, что они работают корректно и соответствуют требованиям. Мало пользы в прохождении определенного этапа, если созданные части не работают так, как предпола. гэлось, хотя даже в этом случае можно кое-чему научиться. Особое внимание следует уделить этапу завершения проекта. В успешном процессе это просто еще один шаг, подтверждающий, что система сконструирована и реализована в соответствии с потребностями клиента. Кроме того, на этом этапе необходимо показать, что система действительно работает так, как предполагалось.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
