The Object Oriented Life Cycle Model
The object-oriented life-cycle model
The usual division of a software project into phases remains intact with the use of object-oriented techniques.
The requirements analysis stage strives to achieve an understanding of the client’s application domain.
The tasks that a software solution must address emerge in the course of requirements analysis.
The requirements analysis phase remains completely independent of an implementation technique that might be applied later.
In the system specification phase the requirements definition describes what the software product must do, but not how this goal is to be achieved.
One point of divergence from conventional phase models arises because implementation with object-oriented programming is marked by the assembly of already existing components.
The advantages of object-oriented life-cycle model:
• Design no longer be carried out independently of the later implementation because during the design phase we must consider which components are available for the solution of the problem. Design and implementation become more closely associated, and even the choice of a different programming language can lead to completely different program structures.
• The duration of the implementation phase is reduced. In particular, (sub)products become available much earlier to allow testing of the correctness of the design. Incorrect decisions can be recognized and corrected earlier. This makes for closer feedback coupling of the design and implementation phases.
• The class library containing the reusable components must be continuously maintained. Saving at the implementation end is partially lost as they are reinvested in this maintenance. A new job title emerges, the class librarian, who is responsible for ensuring the efficient usability of the class library.
• During the test phase, the function of not only the new product but also of the reused components is tested. Any deficiencies in the latter must be documented exactly. The resulting modifications must be handled centrally in the class library to ensure that they impact on other projects, both current and future.
• Newly created classes must be tested for their general usability. If there is a chance that a component could be used in other projects as well, it must be included in the class library and documented accordingly. This also means that the new class must be announced and made accessible to other programmers who might profit from it. This places new requirements on the in-house communication structures.
The class library serves as a tool that extends beyond the scope of an individual project because classes provided by one project can increase productivity in subsequent projects.
The actual software life cycle recurs when new requirements arise in the company that initiate a new requirements analysis stage.
Posted in Computer Science, Information Technology, Software Engineering, Software Engineering | 