И. Соммервилл - Инженерия программного обеспечения (1133538), страница 17
Текст из файла (страница 17)
Модель пошаговой разработки находится где-то между этими моделями и объединяет их достоинства. Эта модель (рис. З.б) была предложена Миллсом (МНЬ, [240) ) как попытка уменьшить количество повторно выполнясмгях работ в процессе создания ПО и увеличить для заказчика временной период окончательного принлтия решения обо всех деталях системных требований. акачвзв система Нвзаввршанкав сисгама Ркс. 3.6, Модель лааагааай )амрабааькк 3.
Процесс создания программного обеспечения бб В процессе пошаговой разработки заказчик сначала в общих чертах определяет те сервисы (функциональные возможности), которые должны присутствовать у создаваемой системы. Прн этом устанавливаются приоритеты, т.е.
определяется, какие сервисы более важны, а какие — менее. Также определяется количество шагов разработки, причем на ка. ждем шаге должен быть получен системный компонент, реализующий определенное подмножество системных функций. Распределение реализации системньщ сервисов по шагам разработки зависит от нх приоритетов. Сервисы с более высокими приоритетами реализуюзтл первыми. Последовательность шагов разработки определяется заранее до начала нх выполнения. На первых шагах детализируются требования для сервисов, затем для их реализации (на последующих шагах) используется один из подходящих способов разработки ПО. В ходе их реализации анализируются и детализируются требования длл компонентов, которые будут разрабатываться на более поздних шагах, причем изменение требований для тех компонентов, которые уже нэходятсл в процессе разработки, не допускается.
После завершения шага разработки получаем программный компонент, который передастся заказчику для интегрирования в подсистему, рсализующую определенный системный сервис. Заказчик может экспериментировать с готовыми подсистемами и комно. нентами для того, чтобы уточнить требования, предъявляемые к следующим версиям уже готовых компонентов или к компонентам, разрабатываемым па последующих шагах. По завершении очередного шага разработки полученный компонент интегрируется с ранее произведенными компонентами; таким образом, после каждого шага разработки система приобретает все больш)ю функциональную завершенность. Общесистемные функции в этом процессе могут реализоваться сраз> или постепенно, но мере разработки необходн. мых компонентов. В описываемой модели не предполагается, что на каждом шаге нспользуетсл один и тот же подход к процессу разработки компонентов.
Если создаваемый компонент имеет хорошо разработанную спецификацию, то для его создания можно применить каскадную модель. Если жс требования определены нечетко, можно испольэовать эволюционную модель разработки. Процесс пошаговой разработки имеет целый ряд достоинств, Е Заказчику нет необходимости жлать полного завершения разработки системы, чтобы получить о ней представление. Компоненты, полученные на первых шагах разработки, удовлетворяют наиболее критическим требованиям (так как имеют наибольший приоритет) и их можно оценить на самой ранней стадии создания системы, 2.
Закаэчик может использовать компоненты, полученные на первых шагах разработки. как прототипы и провести с ними эксперименты для уточнения требований к тем компонентам, которые будут разрабатываться позднее. Ук Данный подход уменьшает риск общесистемных ошибок. Хотя в разработке отдельных компонентов возможны ошибки, но эти компоненты должны нройтн соответствуюнгсе тестирование и аттестацию, прежде чем их передадут заказчику. 4.
Поскольку системные сервисы с высоким приоритетом разрабатываются псрвымн, а все последующие компоненты интегрируются с ними, нснэГ>сжно получается так, что наиболее важные подсистемы подвергаются более тщательному всестороннему тестированию и проверке. Это значительно снижает вероятность программных ошибок в особо важных частях системы. 64 тйасть 1. Инженерия программного обеспечения: обзор Вместе с тем при реализации пошаговой разработки могут возникнуть определен.
ные проблемы. Компоненты, получаемые на каждом шаге разработки, имеют относительна небольшой размер (обычно не более 20 000 строк кода), но должны реализовать какую-либо системную функцию. Отобразить множество системных требований к компонснтам нуя<ного размера довольно сложно. Более того, многие системы должны обладать набором базовых систсл<ных свойств, которые реализуются совл<естно различными частямн системы. Поскольку требования детально не определены до тех нар, пока не будуг разработаны все компоненты, бывает весьма сложно распределить общесистемные функции по компонентам.
В иастолщсс время предложен метод так называемого экстремального программирования (ех<гсп<е ргояга<пш<пб), который устраняет некоторые недостатки метода пошаговой разработки. Этот метод основан на пошаговой разработке малых программных компонентов, реализующих небольшие функциональные требования, постоянном вовлечо нпи заказчика в процесс разработки и обезличенном программировании (сл<. главу 23). В статье «31] описан метод экстремального программирования и приведено несколько отчетов о его успешном применении, однако подобные отчеты можно привести для всех основных методов разработки ПО. 3.2.2.
Спиральная модель разработки Спиральная модель процесса создания программного обеспечения (рис. 3.7) была впервые предложена в статье «47] и в настоящее время получила широкую известность и популярность В отличие от рассмотренных раисе моделей, где процесс создания ПО представлен в виде последовательности отдельных процессов с возможной обратной свш зью между ними, здесь процесс разработки представлен в виде спирали. Каждый янтак спирали соответствует одной стадии (итерацин) процесса создания ПО. Так, самый вн>трснний виток спирали соответствует стадии принятия решения о создании ПО, на слслующсм витке опрслсляются системные требования, далее следует стад<а< (виток спирали) проектирования системы и т.д.
Кажлый виток спирали разбит па четыре сектора. 1. Ол]идэмкие йемй. Определяются цели каждой итерации проекта. Кроме того, устаиавлнваютсл ограничения на процесс создания ПО и на сам программный продукт, уточняются планы производства компонентов. Определяются проектнь<е риски (например, риск превышения сроков или риск превышения стоимости проекта).
В зависим«сти от "проявленных" рисков, могут планироватьсл альтернатнвныс стратегии разработки ПО. 2. Околки и(яму<е<иение Ьи<кее. Длл каждого определенного проектного риска проводится его детальный анализ. Планируются мероприятия для ул<сньшения (разрешеннл) рисков. Например, если существует риск, что системныс требования определены неверно, планируется разработать прототип системы. 3. Рлзрайи<яка и меемироелкие.
После оценки рисков выбирается модель процесса соз. данию системы. Например, сслн доминируют риски, связанныс с разработкой интерфейсов. наиболес подходящей будет эволюциопнал модель разработки ПО с прототипированием. Если основные риски связаны с соответствием системы и спецификации, скорее всего, следует применить модель формальных преобразова. пнй.
Каскадная модель может быть применена в том случае, если основныс риски определены как ои<ибки, которые могут проявиться на этапе сборки системы. 3. Процесс создании программного обеспечения бб 4. Плпниргмонис Здесь пересматривается проект и принимается решение о том, начинать ли следующий виток спирали. Если принимается решение о продолжении проекта, разрабатывается план на следующую стадию проекта. С)тцественное отличие спиральной модели от других моделей процесса создания ПО заключается в точном определении и оценивании рисков. Если говорить неформально, то рискэто те неприятности, которые могут случиться в процессе разработки системы.
Например, если при написании программного кода используется новый язык программирования, то риск может заключаться в том, что компилятор этого языка может быть ненадежным или что результирующий код может быть не достаточно эффективным.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
