Графические каскадные модели выглядят следующим образом.

Разработка требований
	Проектирование
		Реализация
			Тестирование
				Ввод в действие

1. На каждом этапе формируется законченный набор проектной документации, отвечающей требованиям заказчика. На заключительных этапах разрабатывается пользовательская документация предусмотренная стандартами разработки АИС.

2. Последовательное выполнение этапов работ, позволяет планировать сроки завершения, и соответствующие затраты.

3. Каскадные модели идеально подходят для разработки таких АИС, как АИС реального времени и АИС автоматизирующих расчет сложных систем.

Недостатки:

1. Существенная задержка в получении результатов проявляется в том, что при последовательном подходе разработки, согласование результатов заинтересованными сторонами производится только после завершения очередного этапа работы. В результате может оказаться, что разрабатываемая АИС не соответствует требованиям, и такие несоответствия могут возникать на любом этапе разработки.

2. Ошибки и не доработки на любом из этапов проявляются, как правило, на последующих этапов работ, что приводит к необходимости возврата – этот недостаток является одним из проявлений предыдущего. Поэтапная работа может привести к тому, что ошибки, допущенные на более ранних этапах, обнаружатся только на следующих стадиях. В результате проект возвращается на предыдущий этап, перерабатывается, и только затем передается в последующую работу. Это может послужить причиной срыва графика и усложнений взаимоотношений между группами разработчиков, выполняющих отдельные этапы. Самый плохой вариант, когда недоработки предыдущего этапа обнаруживаются не на следующем этапе, а позднее. Вообще работа может быть возвращена с любого этапа, на любой предыдущий этап, поэтому реальная схема модели, будет выглядеть по-другому.

3. Сложность параллельного введения работы по проекту. Связанно с необходимостью постоянного согласования различных частей проектов. Чем сильнее взаимосвязь отдельных частей проекта, тем чаще и тщательней должна выполняться синхронизация, тем сильнее зависят друг от друга групп разработчиков.

4. Чрезмерная информационная перенасыщенность каждого из этапов возникает вследствие сильной зависимости между различными группами разработчиков. Дело в том, что при внесении изменений в одну из частей проекта необходимо оповещать тех разработчиков, которые использовали её в своей работе. В результате разработчики должны постоянно знакомиться с изменениями и оценивать, как скажутся эти изменения на полученных результатах.

5. Сложность управления проектом в основном обусловлена строгой последовательностью стадии разработки и наличием сложных взаимосвязей между различными частями проекта. Это приводит к тому, что одни группы разработчиков должны ожидать результатов работы других команд, поэтому требуется административное вмешательство, для согласования сроков и состава передаваемой документации.

6. Высокий уровень риска и не надежность инвестиций. Чем сложней проект, тем дольше длится каждый этап разработки, и это приводит к большему количеству ошибок. Постоянные возвраты на предыдущие этапы, увеличивает время разработки, а также финансовые затраты. В результате этого данная разработка вообще не будет доведена до конца. По данным американской консалтинговой компании боле 31% проектов, заканчивается не удачей, 53% проектов заканчивается с перерасходом денежных средств почти в два раза, и только 16% проектов укладывается в срок и бюджет.