CIS 510 Discussion Response

profileCollegeman
CIS510DiscussionResponseReqs.docx

CIS510 discussion post responses.

"New Enterprise Resource Planning (ERP) System "  Please respond to the following:

· You are preparing to meet with your end users to discuss possible strategies for converting their old ERP system to a new one. Propose two or three alternative strategies, and explore related examples of situations for which each approach would be preferred and required.

· Outline the most common assumptions that developers usually make while documenting the initial use case realization. Determine whether there are negative consequences from such assumptions. Provide a rationale for your response.

JS’s post states the following:Top of Form

When meeting with personal to discuss any possible strategies for converting from an old Enterprise Resource Planning system (ERP) to an updated or new one; it is critical to understand the changes or modifications that will take place and what those changes are being developed to do or what issues the new ERP system will overcome. This requires that current system be evaluated and critiqued on the system’s ability to remain in a performable status, its functions must be easily accommodating in terms of use and all of the other required components must also be reviewed for it accessibility in terms of being user-friendly. This process not only takes time but it ensures that the new system will be able to excel in its performance, its new functionality, and remain user-friendly in terms of it’s capability with the systems software and components.

As with any organizational modifications all operational challenges must be overcome to secure the successful implementation of the system. This means that management must create appreciate approaches for their purchased/ membership and or ownership of the new system. Because an ERP shift is significant because the new system may require weekly updates and or upgrades until all of the new enhancements or updates to the system are perfected which most likely can result in very frustrated employees. To avoid these issues an organization must opt-out to build their own ERP to fit their systematic needs more effectively. This option is fairly expensive because the IT department must ensure that each system can work collaborating with the existing software and network equipment.

If the organizations is fairly small it may be more cost effective to implement an already action system but they in turn must also make sure that they spend an sufficient amount of time with training their staff on the systems purpose and how to navigate the system seamlessly; to avoid issues with the business risk associated with such can lead an organization resolve any issues that lack a clarified definition to the old systems functionality requirements. But this may result in systematic downtime that is very costly all on its own. So an organizations must phase out the updates and upgrades maybe during business closures or when the time allots to ensure they can remain operative during such transitions. But until the old system has been completely integrated; the new system should not go-live until any key business requirements and functions are fully developed and tested. Because doing so without ensuring that each key component of the system is operational is risky. This requires that the system changes must be managed in a flexible and strategic manner. This includes making the old ERP more functional until each of the new systems iterative approach have been perfected. This most likely will result in the evolutionary business alterations which can create a internal shift that must be

•Outline the most common assumptions that developers usually make while documenting the initial use case realization. Determine whether there are negative consequences from such assumptions. Provide a rationale for your response.

The most common assumption that developers tend to make while documenting the initial use case realization is the class Identification, the use cases outline behavior, and the realizing the systems response in the sequence diagram. Each of these case realizations can be negative if each approach is not designed and developed to overcome any issues with the systems use and it implementable use.

With the class identification which requires some use of techniques such as noun/verb analysis and class-responsibility-collaboration cards, teams of analyst which is used to start the system model. Issues with such result from the lack of clarity on where/how to start modeling the behavior and if the modeled will definitely satisfy the user’s needs. This requires several scrutinized evaluations; to ensure that the sequence diagrams realize (show) the behavior outlined in the use cases and assign behavior to classes in the class diagram.

With the use cases the developer must describe actor actions and system responses efficiently. This will ensure that the system responses are written for how the system is to act under user each specific situation/ stimulation. This will aid drive the creation of a dynamic behavior model more effectively.

With the response in the sequence diagram it should be easy to follow if it is defined sequence of operations have defined classes fully in each system response step. In such a use case the sequences will evolve into more detailed design models but it should still result in the same use case realization occurrence. The exact method names, parameters, return types, exception handling, etc.. should not alter the end goal of the system. This will ensure that all modeling is exact and covers all operational objective processes.All of which can be very difficult to overcome if done otherwise.

https://www.intertech.com/Blog/the-forgotten-step-use-case-realization/

GO’s post states the following:Top of Form

Enterprise Resource Planning systems are systems that handle multiple activities that are part of a business (logistics, customer service, manufacturing, etc.). (Butterfield, A. Ngondi, G. & Kerr, A. , 2016) Because of the level of integration and the complexity of such systems, it may not be cost-effective to develop a completely new system. One alternative strategy is to reuse existing systems by modifying specific components or databases. This would be adding new tables to the database or software modules that add additional functionality. Another alternative strategy is replacing specific components and importing old data into them. This may be creating a new database and importing old data into it. (Satzinger, 2016)

For the first alternative strategy, it keeps ERP intact (both in terms of data and structure) and adds to it. This allows the system to grow organically and adds functionality to it. This cuts down on costs and man-hours needed for training staff since they already have familiarity with the current system. Integration into current systems will be less problematic, as well.

For the second alternative strategy, it is preferred when too many changes are needed, the system is patched to the point that it needs to be replaced or outdated and needs to be replaced (for security reasons or no longer can handle the workload). The overall structure is the same but specific components are replaced. This will cost more in man-hours, and financial cost but could reduce overhead in maintaining a system that would otherwise be a collection of fixes.

One of the common assumptions developers might make in use-case-development is that those they need to talk to are available when they are needed. Different departments may work on different time tables (regular meetings, work schedules, lunch breaks, different time zones, etc.) and may not be accessible all the time. If these factors are not taken into account, then it could slow down the project by days or even weeks. Developing an agreed-upon interview schedule by all stakeholders is important to keep the workflow stable. (Satzinger, 2016)

Butterfield, A. Ngondi, G. & Kerr, A. (2016) Enterprise Resource Planning. A Dictionary of Computer Science, 7th Ed. Oxford University Press. Retrieved from https://www-oxfordreference-com.libdatab.strayer.edu/view/10.1093/acref/9780199688975.001.0001/acref-9780199688975-e-6651?rskey=FP6U8b&result=2

Satzinger, J. (2016) Systems Analysis and Design in a Changing World, 7e. [Strayer University Bookshelf]. Retrieved from https://strayer.vitalsource.com/#/books/9781305465268/