ВУЗ:
Составители:
Рубрика:
69
го плана, просто невозможно. Поэтому таблица плана предусматривает столбец
примечаний, который заполняется по мере необходимости в свободной форме.
Следует сказать, что рубрикация календарного плана противоречит распа-
раллеливанию работ, привязке параллельных работ и поставок к срокам. Труд-
но увидеть все нужные показатели на определенный момент времени, как и ре-
шать другие подобные задачи. Для преодоления указанных проблем обычно
используют графики сетевого планирования или сетевые диаграммы.
5.4.3. Спиральная модель ЖЦ
Рассмотренная выше общепринятая модель жизненного цикла программ-
ного обеспечения реализует стратегию однократного прохода в создании ПО.
В этом случае все требования к ПО определены перед началом проектирования
и каждый следующий этап начинается после окончания всех работ предыдуще-
го этапа. Для достаточно сложных систем существенно отодвигает время ис-
пользования результатов разработки (до нескольких лет) и не позволяет учиты-
вать происходящие в течение разработки изменения во внешней и внутренней
среде.
Для преодоления этих недостатков используются инкрементная и эволю-
ционная стратегии разработки ПО.
В первом случае предполагается, что все требования к ПО определены пе-
ред началом проектирования, а сам проект создается в виде нескольких очере-
дей, каждая из которых представляет собой законченный продукт с меньшей
функциональностью, чем вся система в целом. После окончания работ послед-
ней очереди получается полноценная система.
При эволюционной стратегии целевая система создается поэтапно, итера-
ционным способом. Причем на каждом этапе повторяется весь цикл общепри-
нятой модели, начиная с определения требований к ПО данного этапа. В конце
каждого этапа получается система со все большей функциональностью. Приме-
ром эволюционного подхода является классическая спиральная модель ЖЦ.
Постепенное наращивание возможностей системы по мере развития проек-
та часто изображают в виде спирали, раскручивающейся от центра, как показа-
но на рис. 5.2. В соответствии с этой простой (грубой) моделью развитие про-
екта описывается как постепенный охват все более расширяющейся области
плоскости по мере перехода проекта от этапа к этапу и от итерации к итерации.
В данной модели можно усмотреть еще один аспект конструирования про-
граммных систем – типичную схему развития коллектива разработчиков, кото-
рый начиная со своего первого проекта постепенно пополняет накапливаемый
багаж переиспользуемых рабочих продуктов и, что, пожалуй, еще важнее, –
опыт работы и квалификацию.
Модель расширения охвата прикладной области совсем не претендует на
инструментальность. Поэтому обсуждать эти свойства для данной модели мы
не будем.
Страницы
- « первая
- ‹ предыдущая
- …
- 67
- 68
- 69
- 70
- 71
- …
- следующая ›
- последняя »