Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Непейвода Н.Н. -> "Основания программирования " -> 78

Основания программирования - Непейвода Н.Н.

Непейвода Н.Н., Скопин И.Н. Основания программирования — Институт компьютерных исследований , 2002. — 919 c.
Скачать (прямая ссылка): osnovanprogramm2002.pdf
Предыдущая << 1 .. 72 73 74 75 76 77 < 78 > 79 80 81 82 83 84 .. 316 >> Следующая

Рис. 4.11 б) демонстрирует три одновременно выполняеме итерации: вторая начинается в ходе выполнения программирования первой итерации с таким расчетом, чтобы ее этап программирования начался после окончания тестирования первой итерации. Планирование третьей итерации начинается одновременно с этапом программирования второй итерации.
Рис. 4.11 в) показвает области недопустимого, возмо ного и рационального совмеения, а так е область последовательного вполнения двух итераций. Недопустимость совмещения означает, что для планирования очередной итерации нет достаточно полной информации, как следствие, оно не моет бть вполнено эффективно. В ходе конструирования наступает момент, когда такая информация появляется, следовательно, появляется возмо ность активизации работ над новой итерацией. пределение области рационального совмеения работ двух итераций отраает то, что бло бы неразумно начинать этап программирования новой итерации, когда рабочий продукт предыдуей итерации не протестирован. Совмеение, изобра енное на рис. 4.11 б) удовлетворяет этому услови . бласть последовательного выполнения указывает на то время, которое соответствует началу следуей итерации после заверения работ над предыдуей (совмеения нет).
Определение перечисленных областей повышает гибкость распределения времени выполнения проекта. Тем не менее, планируя работы, луче не рассчитвать на совмеения итераций, а оставлять эту возмо ность как резерв временного ресурса проекта. Таким образом, оказывается, что итеративность проектирования повает устойчивость к рискам невполнения проектного задания.
4.3.4. Моделирование итеративного наращивания возможностей системы
В предыдущих моделях итеративного жизненного цикла программного обеспечения не был наглядно выделен важный аспект подхода: постепенное нараивание возмо ностей системы по мере развития проекта. ля его отра-ения мо но предло ить представление изненного цикла в виде спирали
212
ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ
развития, которая показана на рис. 4.127.
Предоставляемые возможности
\^Пл\ Ан| Ко \ I рр_^е]_Оіі^
V
IV
III
II
I
(—\ , ,
\^Пл\ Ан\ Ко\ Пр\ Те\ Onj
^^^^^^^^^^ Пр^^Ъ^О^
Пл\ Ан\ Ко\ Пр\ Те\ Оц^
->¦ Время
Рис. 4.12. Спираль развития объектно-ориентированного проекта
На рисунке горизонтальные отрезки с пометками, имеющими тот же смысл, что и в предыдущей модели, — это итерации. Они помещены в пространство предоставляемых в зависимости от времени возможностей системы. Линии, параллельные временной оси, отображают уровни пользовательских возмож-ностей, реализуемых на итерациях (римскими цифрами справа указаны номера итераций). Стрелки-переходы между итерациями учитывают условия совмещения работ, о которых шла речь вше. Этой моделью подчеркивается тот факт объектно-ориентированного развития проектов, что возмо но-сти, предоставляемые очередной итерацией, никогда не отменя т уровня, достигнутого на предествуих итерациях.
Постепенное наращивание возможностей системы по мере развития проекта часто изобраа т в виде спирали, раскручиваейся на плоскости от центра, как это показано на рис. 4.13. В соответствии с этой грубой моде-
7 В несколько модернизированном виде здесь приводится ставшая классической модель Г. Буча [16], ставшая основой ООП.
4.3. ИТЕРАТИВНЫЕ МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА
213
Рис. 4.13. Модель расширения охвата прикладной области объектно-ориентированной системой
лью развитие проекта описывается как постепенный охват расширяющейся области плоскости по мере перехода проекта от этапа к этапу и от итерации к итерации. По существу, данная модель делает акцент на том, что объектно-ориентированное развитие (как и любое другое экстенсивное развитие, ориентированное на переиспользование) приводит к постепенному расши-рени прикладной области, для которой использу тся конструируемые рабочие продукта.
Про объектно-ориентированное развитие проектов часто говорят: «Оно предполагает, что традиционне этап изненного цикла разработки программной системы никогда не кончаются». Модель раскручивающейся спирали наглядно показывает смысл этого тезиса.
В данной модели можно усмотреть еще один аспект конструирования программных систем — типичную схему развития коллектива разработчиков, который, начиная от первого своего проекта, постепенно пополняет накапливаемый багаж переиспользуемых в разных системах компонентов.
В отличие от предыдущих моделей, обе спиралевидные модели никак не отражают тот факт, что у проекта есть фаза завершения. Как следствие, они предполагают, что все модификации какой-либо версии программной системы, которые требу тся после ее выпуска, будут относиться к одной из сле-
214
ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ
дуих версий. а практике очень часто это поло ение наруается: приходится поддерживать (и, в частности, модифицировать) сразу несколько версий системы.
§ 4.4. ТРЕБОВАНИЯ К ПРОГРАММНОМУ ИЗДЕЛИЮ И ЖИЗНЕННЫЙ ЦИКЛ
Есть еще один важный мотив моделирования жизненного цикла программных изделий. Это изучение и систематизация требований при развитии программных проектов.
Традиционные технологии рассматривают определение и анализ требований в рамках предварительного этапа, предествуего собственно разработке, за которй вявляется вся информация для последуего конструирования. твердается, что успеность дальнейей работ над проектом прямо зависит от того, насколько полно и тщательно выполнен аналитический этап, что внесение корректив в зафиксированне требования приводит к необходимости повторения проектирования и всех других последуих этапов. Иными словами, изменение требований в процессе разработки рассматривается как ошибка аналитического этапа.
Предыдущая << 1 .. 72 73 74 75 76 77 < 78 > 79 80 81 82 83 84 .. 316 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100