Анализ.
На этапе анализа происх. первые встречи разработчиков и будущих пользователей сис-мы, котор., исходя из особенностей поставл. задачи пытаются найти м/у собой общ. язык.
Целью анализа д. б. описание задачи. Описание д. б. полным, последовательным, доступным для чтения и обзора различными заинтересованными сторонами, позволяет проводить сравнение с реальными условиями.
Продукт анализа часто используется затем для описания основной функции сис-мы.
Разграничим задачи анализа и проектирования. При анализе мы пытаемся моделировать окруж. мир, идентифицируя классы и объекты, образующий словарь объектной области, а при ООП мы разрабатываем абстракции и механизмы, обеспечивающие поведение, которое требует эта модель.
Проектирование.
Начало проектирования д. б. не слишком ранним и не слишком поздним. Можно предложить такую стратегию разработки, которую наз. «немного анализа немного проектирования». В этой стратегии каждый шаг проектирования направляет каждый шаг анализа на выявление тех аспектов сис-мы, которые важны для получения решения.
Когда прекращать процесс проектирования? Это важный вопрос, поскольку существует опасность перегрузки системы. Следует предлагать только ключевые абстракции и важные механизмы, достаточные для реализации и откладывать на более поздний период те аспекты решения, которые оказывают незначительное влияние на видимые аспекты поведения системы.
Эволюция системы.
Эволюция системы в жизн. цикле разработки ОО ПО совмещает традиционные этапы, включающие составление программ, их тестирование и интеграция. Поэтому, при ООП мы никогда не сталкиваемся с отдельным этапом интеграции в системе. Вместо этого процесс разработки превращается в постепенное составление ряда прототипов, которые затем входят в конечную реализацию.
Практика показала, что в процессе эволюции системы в ней могут произойти след. изменения:
1) Дополнение нового класса
2) Изменение реализации класса
3) Реорганизация структуры класса
4) Изменение интерфейса класса
Чтобы избежать ошибок при эволюции разрабатываемой системы нужно соблюдать два правила:
1) Следить за созданием устойчивого интерфейса
2) Ограничивать доступ проектным решениям, которые могут меняться.
Модификация.
Программа, котор. реально используется, обязательно должна изменяться. Иначе она будет все менее и менее пригодна для использования (закон непрерывного изменения). Когда программа изменяется, ее структура становится более сложной, если при этом не предпринимаются активные усилия с целью предотвратить осложнения.
Управление проектом.
При ООП существует необходимость в 4 типах специалистов:
1) архитекторы систем
2) проектировщики классов
3) специалисты, реализующие внутр. строение классов
4) программисты-прикладники.
Такое распеределение труда формирует задачу подбора кадров. Управление ¬– это активный процесс.
Оценка прогресса разработки.
Эффективный способ оценки продуктивности дает опыт постоянной интеграции. В этом случае прогресс измеряется количеством и качеством законченных и работающих классов, если это логическое проектирование или модулей, если это физическое. Другой путь оценки состояния работ ¬– оценка устойчивости ключевых интерфейсов (т.е как часто они изменяются).
Продукты ООП – это диаграммы классов, модулей, процессов и объектные диаграммы в надлежащим образм оформленных документах.
Выбор продукта.
С точки зрения конечного пользователя системы выпуск продукта – это получение ряда последовательно улучшающихся прототипов системы. С т. зр. работников организации выпуск продукта – это отбор из ряда прототипов наиболее удачных.
Контроль качества.
На ранних стадиях разработки контроль в основном охватывает область статических и динамических свойств ключевых абстракций и механизмов системы, отраженных в диаграмме классов и объектов. Позднее контроль охватывает гл. обр. физический проект системы, отраженный в диаграмме модулей и процессов. С проблемой контроля тесно связана проблема тестирования. Применение ООП не меняет обычную практику тестирования. Изменяется лишь объем тестируемых модулей.
Инструментальная поддержка.
Можно выделить 6 разл. типов инстрементальных средств, оказывающихся полезными при ООП. 1-ым инструментом явл. графические системы со встроенными элементами нотации. 2-ым инструментом явл. инструмент просмотра структуры класса и модульной архитектуры системы. 3-ий важнейший инструмент – это пошаговый транслятор. К 4-му инструменту можно отнести наличие отладчиков, понимающих семантику классов и объектов. 5-ый инструмент – это инструмент контроля за версиями. 6-ой инструмент – это библиотека классов.
Может понадобиться также инструментальный редактор – для создания проблемно-ориентированных и модернизации существующих инструментов под определенный проект.

Достоинства ООП.
1.Поддержка повторного использова¬нияотдельных составляющих ПО.
2.Использование выразительных сред-ств объектных и объектно — ориентированных языков.
3. Создание более открытых систем.
4. Снижение риска при разработке.
5. Активизация позновательной способности человека.
Недостатки ООП.
1. Ухудшение характеристик. Существует определенная плата за посылку сообщения от одного объекта к другому, выражающаяся в некотором ухудшении быстродействия. Обращение к методу может заниметь в 1,75 – 2,5 раза больше, чем обращение к обычной программе.
2. Недостаток, связанный с динамическим размещением и уничтожением объектов.

Несмотря на перечисленные недостатки ООП явл-ся более удобным.