АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

Каскадная модель

Читайте также:
  1. V2. Модель IS-LM
  2. V2. Равновесие совокупного спроса и предложения. Модель AD-AS.
  3. V2: Равновесие совокупного спроса и предложения. Модель AD-AS.
  4. XXII. Модель «К» и отчаянный риск
  5. А) Модель Хофстида
  6. А-модель
  7. Адаптивная модель
  8. Адаптивная полиномиальная модель первого порядка
  9. Аксилераторно-мультипликаторная модель (модель Самуэльсона-Хикса).
  10. Акцептор действия — механизм, предвосхищаяющий закодированную модель будущего.
  11. Альтернативні моделі розвитку. Центральна проблема (ринок і КАС). Азіатські моделі. Європейська модель. Американська модель
  12. Альтернативные модели потребления: модель межвременного выбора И. Фишера, теория перманентного дохода М. Фридмена, гипотеза жизненного цикла Ф. Модильяни

Первоначально (1970-1985 годы) была предложена и использовалась каскадная схема разработки программного обеспечении (рис. 11.1), которая предполагала, что переход на следующую стадию осуществляется после того, как полностью будут завершены проектные операции предыдущей стадии и получены все исходные данные для следующей стадии. Достоинствами такой схемы являются:

• получение в конце каждой стадии законченного набора проектной документации, отвечающего требованиям полноты и согласованности;

• простота планирования процесса разработки.

Именно такую схему и используют обычно при блочно-иерархическом подходе к разработке сложных технических объектов, обеспечивая очень высокие параметры эффективности разработки. Однако данная схема оказалась применимой только к созданию систем, для которых в самом начале разработки удавалось точно и полно сформулировать все требования. Это уменьшало вероятность возникновения в процессе разработки проблем, связанных c принятием неудачного решения на предыдущих стадиях. На практике такие разработки встречается крайне редко.

 

 

Рисунок 11.1 ‑ Каскадная схема разработки программного обеспечения

 

В целом необходимость возвратов на предыдущие стадии обусловлена следующими причинами:

• неточные спецификации, уточнение которых в процессе разработки может привести к необходимости пересмотра уже принятых решений;

• изменение требований заказчика непосредственно в процессе разработки;

• быстрое моральное устаревание используемых технических и программных средств;

• отсутствие удовлетворительных средств описания разработки на стадиях постановки задачи, анализа и проектирования.

Отказ от уточнения (изменения) спецификаций приведет к тому, что законченный продукт не будет удовлетворять потребности пользователей. При отказе от учета смены оборудования и программной среды пользователь по­лучит морально устаревший продукт. А отказ от пересмотра неудачных про­ектных решений приводит к ухудшению структуры программного продукта и, соответственно, усложнит, растянет по времени и удорожит процесс его создания. Реальный процесс разработки, таким образом, носит итерацион­ный характер.


1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 |

Поиск по сайту:

Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.003 сек.)