Object Oriented Approach
The object oriented approach makes the process modeling quite simpler in nature by constructing the objects which represents real life features. It also brings forth data abstraction and encapsulation techniques. In comparison to other process models the organization’s data is given more importance with relation to its storage and security. The ability is also enhanced with the use of other object oriented features such as inheritance and polymorphism (Booch, 2003). The reusability of the data and business processes is the prime feature of object oriented methods which makes it quite strong in comparison to other methods.
In waterfall emphasis was more in modeling organizations processes, information engineering focuses on modeling organization’s data whereas object oriented methods envelope both the data and processes into wrappings called objects. Keeping data and processes together into a single unit would make handling of process modeling quite well in nature. The OOD concept depicts the entire design document into a real world entity and all the correct implications of the design would be enveloped in the same (Hoffer, 2002).
The RAD methodology is quite suitable for building the system. However if RAD is combined with object oriented approaches (OOD) it becomes a strong process model for compliance.
1. Conceptual model in UML
Figure 2: Use Case Diagram of the Ikea Business
2. Implementation Cut over strategy defines the strategies and decision for the system installation. Once a system has been developed and tested, it must be installed and placed into operation. Installing a system and making it operational is complex as there are many conflict constraints.
Some of important issues when planning installation are to be considered like cost, customer relations, employee relations, logistical complexity, and overall exposure to risk (Silvia, 2000). Some of the most important issues to be considered when planning installation include incurring costs of operation both systems in parallel, detecting and correct the errors in the new system, potentially disrupting the company and its IS operation and training personnel and familiarizing customers with new products. Different approaches to installation represent different trade-offs.
The most commonly used installation approaches are:
1. Direct installation; in a direct installation the new system is installed and quickly made operational and any overlapping system are then turned off. This is also called as immediate cut over. The primary advantage of direct installation is it simplicity; the primary disadvantage of this is its risk. Because legacy systems are not operated in parallel, there is no backup in the event that the new system fails. This installation is typically used under the new system is not replacing a legacy system or downtime of days or weeks can be tolerated.
2. Parallel installation: In this the new system is implemented and run in parallel with the new one but not completely implemented at a stance. The old system is kept in place and slowly replaced. The cost factors are high but efficiency is derived from it. 3. Phased installation: The system is installed and get into operation in a series of steps and phases. Each phase is well observed before and after implementation. The new system is not operating completely at this time but is replacing the old system in phases. It is time consuming but very effective in the long run.
Our installation strategy for the stock control system would be the phased approach. It marks the continuity of the present business and also taking into account the changes the new system is about to begin. The business requires to flow and cannot be halted for installation of the system; therefore phased installation is the most suitable.
3. Risks and roadblocks in the design process There are various forms and dimensions of risk which can come around in the design process, implementation and final working of the system.
Users failed to present absolute requirements.
2. Clients were not drawn in the growth process.
3. The plan had scarce or no resources that were crucial for its achievement.
4. Planning had loopholes.
5. The project’s span had become out-of-date due to transformation in business surroundings.
6. The project players were officially unskilled (Cooke-Davies, 2003, 225-8).
The various factors in the process of development would make a difference if taken seriously and done professionally in nature. a. Identifying the realities of an organization
Communication must be quite swift with all the stakeholders of the system so that the ground level people get to know, feel and take part in the system building program. Various stakeholders of the system would bring out a clear definition of the system which would be quite distinguishable than others. Encouraging the stakeholders to define and correlate the differences between their present work and proposed change due to the involvement of information system, would pave the way for success. Exposing the stakeholders with rich pictures and real life models which is self explanatory for understanding the requirements.
Improving the IS and IT capabilities The relation between the level of thoughts between the stakeholders and the technical design experts must flow in the same direction so that they are able to interpret the business scenario much better. The involvement of domain experts would be a great idea for success. The technical base of the software vendors must be considerably high in nature so that everything the technology can do must be well known in advance to envelope greater depth of the involment of business functions. c. To be clear with ‘what’ and ‘how’ of the system This step is one of the most determining steps in the development stage.
You may also be interested in Service Oriented Strategy
Unless one is sure of what needs o be done and how to do it, the entire information system becomes an unexplored space with full of bugs. The identification of the exact requirements which needs to be implemented and the appropriate technology required for getting the job done is must for long term success. Another set of risks is the security risks. The security issues are the primary issues which an organization must take care to protect their data which is king to any organization. In particular as the system implements payment system, security is very much required as that would ensure safe communication with financial information.
The following are the identified issues and their correct implementation process:
a. Login/Access Issues: Every customer would be asked to sign up with the company before any services are provided. That would ensure safety of transactions made with the company. It could be similar to Pay Pal, where a person can get verified by giving his Credit card number.
b. Back up: Periodic backups can be taken of the database in magnetic tapes so that data remains safe and is not lost. The saved data also ensures continuity of business and good recoverability options.
c. Anti virus software: The system needs to be protected against all vulnerabilities and threats like viruses. Good anti-virus software would ensure that the system is well protected and operations will not halt for any external threat.
4. Conclusion The system development and design activities undertaken for Ikea business would pave the path for its success to cater to all dimensions of customers with a variety of tastes. They require capitalizing on their resources and make sure that optimum utilization of resources is taken into account as objective is to cater to the various customers with low prices of products.
Engineering principles were a necessity in the complexity/diversity surrounding online activity. Legal and ethical issues are vital to security conscious users.
References / Bibliography
Booch, Grady (2003). Object-Oriented Analysis and Design with Applications, 2nd Edition, Addison-Wesley Professional. Boehm, B. (1988), “A Spiral Model of Software Development and Enhancement,” IEEE Computer 21, 5, 61-72. Cooke-Davies, T. (2002). The “real” success factors on projects. International Journal of Project Management 20, 85-190.