The people of a traditional data processing system (hence “the system”) plays an important part. This subsection describes the various types of people involved in the design, implementation and deployment of a data processing system.
The client(s) of a DP system refers to the organization(s) who will be using the system. A DP system may serve multiple clients. For example, an air quality monitoring system serves the Air Resources Board and industries that potentially generate air pollutants.
For each client of a DP system, there is a set of goals to accomplish. For example, in the case of a air pollution DP system, the Air Resources Board (ARB) has a goal of improved effectiveness to monitor air pollution and identify sources of pollutants.
Besides the goals, a client also specifies a set of functions that a DP system must accomplish. These functions help accomplish the goals mentioned earlier. Getting back to our example, the ARB can specify a set of functions, such as the following:
Ultimately, the clients are the bosses of a DP system, as the clients determine whether a system is “right” or not. However, a client most likely does not have the technical knowledge to fully spell out the specifications of a DP system.
The systems analysts of a DP is the glue of all the involved parties of a DP system. This is accomplished by communication and documentation.
In the initial phase of a DP development project, systems analysts communicate with the clients to identify the goals and core required functions of the DP system. As a result, one of the products is the specifications of the proposed system. This specification becomes the “blue print” of the proposed system.
The blue print of a DP system is often expressed in text and diagrams. Flow charts, activity diagrams, state diagrams are examples of diagrams.
Besides authoring the systems specification, systems analysts also ensures all parties communicate effectively for the DP system to be developed and maintained effectively.
The developers are also called programmers or coders. This team writes the code of a DP system in various programming languages. The developers take the system specifications from the systems analysts and implement the system according to those specifications.
As a system is developed, QA personnel tests the system according to the system specifications. Note that QA personnel are separated from developers to ensure all aspects of the systems are tested. Developers tend to think of the “right ways” of using a DP system, and test the system using the methods. QA personnel, on the other hand, tests how a system behave according to specifications for all cases, especially the “wrong ways”.
Technical writers take the systems specifications and write manuals and other documents for the clients. In the past, most manuals and documents are written for paper-based distribution. However, most modern documents are written for web-based distribution. The shift of media enables the use of hyperlinks and multimedia presentations.
System administrators is a team that maintains a DP system and keep it operational. They perform functions such as software patches, routine backup, emergency restoration, hardware maintenance, security monitoring and etc.
The help desk team provides end user/client support. They assist users to use a DP system, and take feedback from end users. In other words, after a DP system is deployed, the help desk team is the frontline to interface with end users.
The information collected by the help desk is often entered into an “incident” database. This database, in return, is monitored by other teams in a DP system. For example, systems analysts can monitor the number of incidents related to a confusing feature, and decide to improve the system by changing a few user interfaces. Developers, on the other hand, monitor for defect reports. If an incident is classified as a defect (by technical management), then it is assigned to the developers to resolve.