System Elements-Data Roles in System Development - End Users Systems Development Life Cycle – Feasibility CMGT 555 / Systems Analysis and Development
Week 1 Paper GMGT 555- A BBB � PAGE �1�
System Elements-Data
Roles in System Development - End Users
Systems Development Life Cycle - Feasibility
CMGT 555 / Systems Analysis and Development
Darrell Broyles
University Of Phoenix
December 2, 2006
�
System Elements-Data
The design of a system varies in response to the expected audience for the perticulare application. Some systems are intended for back rooms, some for the front office, and some are for the general public. They are designed for technical users, others for end users. Some are intended to work standalone in real-time control applications, others for an environment of timesharing and pervasive networking. (Raymond, 2003, chap. 3) What has to be defined is the kind of system and the requirements.
Every system has elements but none are as important as the input of data . This data can ultimately have an effect on the desired outcome . Each system requires users to enter data in a particular format. If this data is not entered correctly the system is unable to recognize the input as valid data. This is frequently the case with time and date fields. In this situation an error handling process is needed, users will perriodically make input errors. Design considerations are often focused on the wrong issues, to much time is spent on formulating the desired error message and where it must be displayed in the process.
Frequently system programmers will design a system that provides instructions built into the application, thus providing the correct input format. So the users can understand exactly how they should enter the data. However, even this does not always help, users still make input errors, and developers complain about their "stupid" users. (Waloszek, 2000)
One must think that this way of thinking is wrong. The problem truly is not with the users. The problem is the design of the system, thus forcing users to act in a "system-friendly " way. (Waloszek, 2000) Requiring users to enter data
System Elements-Data
Roles in System Development - End Users
Systems Development Life Cycle - Feasibility
CMGT 555 / Systems Analysis and Development
Darrell Broyles
University Of Phoenix
December 2, 2006
�
System Elements-Data
The design of a system varies in response to the expected audience for the perticulare application. Some systems are intended for back rooms, some for the front office, and some are for the general public. They are designed for technical users, others for end users. Some are intended to work standalone in real-time control applications, others for an environment of timesharing and pervasive networking. (Raymond, 2003, chap. 3) What has to be defined is the kind of system and the requirements.
Every system has elements but none are as important as the input of data . This data can ultimately have an effect on the desired outcome . Each system requires users to enter data in a particular format. If this data is not entered correctly the system is unable to recognize the input as valid data. This is frequently the case with time and date fields. In this situation an error handling process is needed, users will perriodically make input errors. Design considerations are often focused on the wrong issues, to much time is spent on formulating the desired error message and where it must be displayed in the process.
Frequently system programmers will design a system that provides instructions built into the application, thus providing the correct input format. So the users can understand exactly how they should enter the data. However, even this does not always help, users still make input errors, and developers complain about their "stupid" users. (Waloszek, 2000)
One must think that this way of thinking is wrong. The problem truly is not with the users. The problem is the design of the system, thus forcing users to act in a "system-friendly " way. (Waloszek, 2000) Requiring users to enter data
References: (Ferneley E H 2007 Covert End User Development a Study of Sucess)Ferneley , E. H. (2007). Covert End User Development a Study of Success. _Journal of Organizational and End User Computing, 19_(1), 62-72. (Hawkins J L 1996 Develop with End-User Tools?)Hawkins, J. L. (1996). Develop with End-User Tools? _Advisor Media, ,_ . Retrieved November 29, 2006, from Advisor Media, Inc Web Site: http://advisor.com/doc/05137 (Maston J 2001905 Cooperative Feasibility Study Process.)Maston, J. (2001, September 5). The Cooperative Feasibility Study Process. _USDA-Cooperative Services, 1,_ . Retrieved 12/01/2006, from Georgia Cooperative Council database. (Raymond E S 2003 Elements of Operating-System Style)Raymond, E. S. (2003). The Elements of Operating-System Style [Electronic version]. In E. Raymond (Ed.), _The Art of Unix Programming_ (1st ed., Rev., p. ). : Thyrsus Enterprises. (University Of Wisconsin Center For Cooperatives 20010829 Conducting a Feasibility Study.)University of Wisconsin Center For Cooperatives. (2001, August 29). Conducting a Feasibility Study. _, ,_ . Retrieved 12/01/2006, from database. (Waloszek G 20000901 Don 't Let Users Suffer from System Weaknesses)Waloszek, G. (2000, September 1). _Don 't Let Users Suffer from System Weaknesses_. Retrieved December 1, 2006, from SAP Design Guide Web Site: http://www.sapdesignguild.org/community/design/sys_weak.asp