Introduction
The most important things to consider when considering object-oriented are how the system will be used and the availability of resources to operate under the new system. Factors to consider in this area include whether or not to reuse some or all of the parts in the system, how the size and complex processes of the system will be managed, whether or not to develop a product platform for the long-run, the kinds of improvements to be integrated into the software development process, whether adequate explicit attention can be devoted to any issues that occur in real-time, whether the company has the ability to verify analysis through simulating the models, the availability of training and technical documentation of the products, and the ability to implement any other transitioning process (from analysis to design) which may be included in such a proposal (Lee 1999).
In addition to this, there are still more general and conceptual things which can be considered for the utmost caution. Whether OO is the proper tool for the project, if it adequately addresses the problems the project expects to encounter, whether it assists in meeting the technical objectives of the project, if there will be support for the training, whether the demand exists to the extent of usefulness, whether it meets business objectives, if there is an existing method for analysis (and if it works,) and if it helps staff to reach their objectives (Lee 1999).
Object Orientation. Risks
There are many risks involved in making a move to object orientation. If OO is not the best choice, the system will thus not be as effective. The whole system could become disorganised, chaotic, and counterproductive if proper planning and analysis is not performed to ensure the effectiveness of the object-oriented system. Essentially, OO permeates all aspects of a business, and since it is so far reaching, there are nearly infinite risks in a failed conversion. Risk management is commonly implemented to avoid such catastrophe, though as processes continue to develop the risks seem less immediate and apparent (Hantos 2005).
Risk management
Risk management is an all-purpose solution to the numerous risks that are involved. In most cases, however, the end result is an analysis procedure that lets engineers measure the pros and cons of a variety of requirements, while giving consideration also to the capability to satisfy more than one list of requirements (Lee 1999). Generally, while risk management is recognised as an essential component of all project management, it is organised within companies to wholly consider and prevent risk. A good risk management system plans and implements risk management, manages the project risk profile, performs risk analysis, performs risk monitoring, performs risk treatment, and evaluates risk management processes (Hantos 2005).
The cost
The cost should actually be reduced in successful implementation because the increased portability of cost eliminates the need for identical code to be placed in multiple locations in most cases. However, one could consider the case that there is a cost incurred through operating a buffer. In this case the cost would be proportional to the quantity of buffer faults.
Benefits
There are many benefits possible through OO. One immediate conceptual benefit is that OO is a more natural thought process; it is naturally more user-friendly. Also, the processes of such systems are independent of specific database applications which may be running continually. Furthermore, the data of OO databases can be integrated into more complex information and media such as image files, video files, and a variety of other multimedia processes. Other benefits include reusability, reliability, and stability (Chatterjee 2005). OO relationships are also represented explicitly while having increased access to information, which results in an improvement in data access performance in general. Users can also create their own processes for data access, representation, and manipulation.
As mentioned, savings from successful implementation could be expected because the increased portability of cost eliminates the need for identical code to be placed in multiple locations
Conclusion
I would recommend the practical approach be used as it gives focus to many areas without being risky in unequal distribution of efforts and resources. While many problems can arise even in the implementation process it is best to divide the implementation into practical categories and proceed according to circumstance. This also allows for a number of variables to take place without the worry of the implementation process getting in the way. There are many steps even in a practical approach. The steps as I have found to be best in implementation involve assessing the applicability of OO, gaining management support, initiating analysis, and sustaining analysis.
These can be better described through the number of smaller sub-processes which include presenting the assessment, demonstrating the benefits, establishing realistic expectations, presenting the plan, creating a productive analysis environment, documenting standards and meeting guidelines, training employees, create and review models, leveraging available analysis experience, distinguishing between analysis and design, maintaining chart and subsystem interfaces, demonstrating tangible progress, and calibrating and maintaining the plan. Such an approach considers many aspects, yet remains a practical and effective way of approaching the implementation process. Risk management should also be established to some fashion as it is such an important preventative measure, however it may not be deemed efficient to have it fully functioning at all times (and rather only temporarily) in such early stages.
References
Chatterjee, J 2003, ‘Introduction to RDBMS, OODBMS and ORDBMS’, Database.
Hantos, P 2005, ‘Inherent Risks in Object-Oriented Development’, Crosstalk.
Lee, M 1999, ‘Object-Oriented Analysis in the Real World’, Methods & Tools.