Добавлю свои 5 копеек в обсуждение.
Нельзя рассматривать аналитическую модель, проектную модель как результаты фаз. Результатом фаз RUP является определенное целевое их состояние (скажем, "готова на 25%", "готова на 100%"). Кстати, анализ и проектирование -- это процессы в RUPе, не стадии, т. е. другое измерение.
Если к чему привязывать эти модели, то к ролям. Аналитическую модель делает аналитик. Проектную модель -- проектировщик.
Разница между моделями четче всего проявляется при сравнении классов анализа с проектными классами. Если первые -- результат "начального подхода" к проблеме -- ее разложение на 3 полки ("граница", "управление", "сущность"), то вторые отражают архитектуру.
Позволю пару цитат
===
Модель анализа включает основные классы, необходимые для реализации выделенных вариантов использования, а также возможные связи между классами. Выделяемые классы разбиваются на три разновидности — граничные, управляющие и классы-сущности. Эти классы представляют собой набор начальных абстракций, в терминах которых представляется работа системы. Они являются понятиями, с помощью которых достаточно удобно объяснять себе и другим происходящее внутри системы, не слишком вдаваясь в детали.
===
Модель проектирования является детализацией и специализацией модели анализа. Она также состоит из классов, но более четко определенных, с более точным и детальным распределением обязанностей чем у классов анализа. Проектные классы должны быть специализированы для конкретной используемой платформы. Каждая такая платформа может включать несколько операционных систем; используемые языки программирования; интерфейсы и классы конкретных компонентных сред, таких как J2EE, .NET, COM или CORBA; интерфейсы выбранных для использования СУБД, например, Oracle или MS SQL Server; используемые библиотеки разработки пользовательского интерфейса, такие как swing или swt в Java, MFC или gtk; интерфейсы взаимодействующих внешних систем и пр.
===
Изложение всего с позиций RUPа, конечно же.
Классификация моделей разработки ПО