Application of Object Orientation
It is often said that OO stands closer to the real world as opposed to the techniques predating OO. If we want to apply OO in the implementation of a software system we have to close the gap between real world objects and objects in the implementation. Therefor it is logical to apply OO in the earlier phases of software development.

Analysis (OOA)

Object-oriented analysis often results in designing the system. This is largely due to trying to define a class hierarchy for data. With this, objects are represented as data and so the fundamentals of OO are not obeyed.

Actually, in analysis OO is of no use for describing the software system. Should OO be used for describing what the software system has to do, we are actually designing the software system. However, OO can be used for describing the interaction of the software system with its environment. The software system itself is an object in its environment.

Design (OOD)

In most cases, the design concentrates around the development of class hierarchies. Moreover, these class hierarchies are expressed directly in an object-oriented programming language or in a language on a too low level of abstraction. Instead it should focus on abstraction. Developing abstract models of the system, each a refinement of the other. Object-orientation is extremely usefull in this, since it enables abstraction from internal behaviour and implementation.

Analysis & Design (OOAD)

Analysis and design are overlapping phases because some design decision reveal a need for further analysis or analysis depend on how certain parts of the system can be implemented. But most of all, design experiments can give information on incomplete or vague requirements.

Programming (OOP)

There is no particular programming language needed to obey the fundamentals of OO when programming. However, it is convenient to program in an object-oriented style in a language that supports OO.

Maintenance

Application of OO in all phases of software development makes maintenance of the software easier. It is easier to see at which level of abstraction certain design decisions have been made. Also, it is easier to see at which level changes have to be incorporated into the design and which parts of the software are affected by these changes.