Topic 6 Computer Professionals
This topic will not only be of interest to ICT students, but also computing students may find it helpful. It will also help students as a background to their project work.
Who are the Professionals?
Most people who work in commercial or scientific environments use computers to a greater or lesser degree to aid them in their jobs. They are computer users. Computer professionals have occupations that exist because computers exist. The main divisions of computer professional jobs are:
Business systems staff including systems analysts and database administrators
Programming staff including project leaders, analyst programmers and programmers
Operations staff including operators, systems programmers, technical support and network controllers
Data entry and data preparation staff.
The Work of a Systems Analyst
(a) Identification of the problem. The systems development manager will be informed of the problem.
(b) Feasibility Study to assess the desirability or otherwise of a computer based solution.
(c) Systems investigations will follow, including discussions with departmental managers to obtain a clearer view of the requirements, and interviews with key members of staff whose views will help to determine the final outcome.
The situation may well be one of three common scenarios:
Computerisation of an existing manual system
Updating of a computerised system
No system exists, or a new system is being set up.
| Describe how the following actions are done in a manual and a computerized information retrieval system | ||
|
Action |
Manual |
Computer |
|
|
|
|
|
Data processing |
|
|
|
Data Storage |
|
|
|
Writing a report |
|
|
Justification of the initial investigation. Is it worth the time and money?
Analysis of the problem. What is required of the new system? Can any improvements be made to existing systems? Can problem areas be eliminated? Is a new system value effective?
Design of the new system.
Implementation when the new system is designed and tested.
Let us look at a flow chart that summarises the the feasibility study:

The feasibility study looks at areas like:
Does the current system work? Is there a real need for Computerisation?
How complex is the current system? How much time and effort are needed to set up a new one? Are there staff available to do the work?
Is the project technically feasible?
Can the company afford to carry out the project? Does the problem justify such a solution?
The report will cover:
Strengths and weaknesses of the current system
What additional functions can be offered to the users
What improvements will result.
The new system can be developed in-house, using the company’s own staff or contracted staff.
The system can be purchased as a package from an outside supplier.
The system can be adapted from the existing computer systems within the company.
Option
|
Advantages
|
Disadvantages
|
|
In house development |
Solution is tailor-made to the problem |
Can be very expensive and time consuming |
|
Purchasing a package |
Cheap to purchase and immediately available |
Package may not be entirely suitable for the purpose |
|
Adaptation of existing systems |
Little or no purchase of new equipment, solution will fit in with existing requirements |
Existing systems may be well suited to existing functions and not easily adapted |
In reality, many commercial packages have the flexibility to be adapted to a limited extent, although this may not go far enough. However in-house solutions may well not be that adaptable for any future changes. Whatever solution is decided on, an in-depth analysis is needed.
Let us suppose that the in-house solution is preferred. Now the analysis is carried out. The analyst carries out a detailed study of the current system to look at its workings, its data flows and volumes, and problem areas. This can be gleaned from:
Current documentation, such as stock records, invoices, etc.,
Interviews with staff.
The analyst prepares a theoretical model and the users confirm that this is the way the system currently runs. This model is refined to a logical specification and any new requirements are added at this stage. The analyst now has a specification of requirements which:
Outlines the details of the new system, including the workings of the current system and improvements
Illustrates the outputs expected of the new system, its flexibility and services.
Illustrates how the services will be delivered and how problems will be eliminated.
Has been agreed by the users to be a fair and accurate description of the requirement.
Has addressed all issues raised in the study.
![]() |
Circles to represent processes that turn input to output, e.g. sales details to bonuses.
Flow lines showing the flow of data between departments, or operations on the data.
Square boxes to represent sources and destinations of data.
Frames to represent files.
These conventions allow the analyst to show the flow of data, the actions on it, and the outputs. The analyst draws up a logical design of the system for his own use and for display to interested users.
Question 7 What features of a data flow diagram make it helpful? ANSWER
So far, the analyst has drawn up a theoretical model on paper with no reference to a computer so far. Now it’s time to see how the proposals will be implemented with a computer. The analyst has at his disposal many planning tools to design and display the physical configuration.
A systems flowchart has conventional symbols to represent various peripheral devices and processes.
![]() |
This is a selection of a few of the symbols. There are others for communication lines, off-line storage, magnetic tape, etc. They are available on templates or in computer graphics packages.
The amount of design detail required from an analyst varies quite considerably. In some cases the system has to be designed right down to individual processes, leaving programmers to translate the design into a programming language. In other cases, the analysis is a high level overview leaving the programmers a lot of scope with the details of the design. However, whatever methodology is used, the system design will always include:
Specification as to the order and type of operations within individual programs within the system.
Selection of an appropriate data organisation method, e.g. sequential, indexed, etc.
Design of VDU screen layouts and printed reports
Validation of data and error handling
Security against unauthorised access and ensuring backing up procedures.
Detailed decisions about the type and number of programs.
Batch or on-line processing
Finally the new system is installed and set up. It is thoroughly tested and run alongside the old for a period of time. Staff are trained in its use. If it’s working properly, the old system is then replaced completely with the new, which is said to be live. If the systems analyst has done his job properly, the computer will quietly do its job. If not the computer will sit there, happy as Larry, churning out error after error, making the staff long for the good old days of the manual system.
The Database Administrator
Both systems analysts and database administrators (DBA) have much in common in the way that they have considerable business experience. However their functions are completely different. The analyst is not concerned with how a program processes data, rather what the data used for in different applications. Like the systems analyst, the database administrator is not too concerned with the mundane processing of data; the database itself does that. Instead he is looking at how applications view and use data in a way that is specific to a company’s requirements.
The DBA is responsible for the company database and its rules for data display, printing, validating, security, etc. The rules are determined by the use and application of the data, not its physical storage. So the DBA is responsible for:
Designing and setting up the database.
Using various utilities for database maintenance
Imposing the standards and procedures applicable to the storage of data
Liaison with analysts and programmers to add new applications to the database
Establishment of relations between data items, users, and applications programs.
In effect he is responsible for the database management system (DBMS) which is the complete collection of software that controls access to and updating of the data. The DBA can use a data dictionary to help him to map out the application of the database, by defining size, type, and validation of data and its place within the application.
The entire database application is kept as a distinct entity, designed by the DBA in consultation with the systems analyst. Data is regarded by the business not just as a load of unrelated items, but a whole that is used by the business. It is vital that it is kept in a logical way. This would be much more difficult without the expertise of the DBA.
The Work of the Programmer
The programmer is the one who turns the designs of the analyst into software to be used with the new system. His job is to design and code the list of instructions that tell the computer what to do. Sometimes a programmer may well take on the job of a systems analyst, in which case he is an analyst programmer. Normally the programmer works as part of a project team under the supervision of a project leader, who will allocate parts of the project to the members of the team. The project leader will be responsible for the whole suite of programs, with the individual programmers working on individual programs or sub-systems.
Sometimes methodologies dictate that the analysts produce a design so detailed that the programmers just do the coding in the appropriate language. Other methodologies leave the detailed planning to the programmers who use program design methodologies to produce logical steps for each action in the program. Whatever the methodology, there are some common factors:
Programs are split up into small manageable modules, each of which performs a discrete function, as far as possible.
The modules are executed in order defined by a control procedure.
Programs are designed top-down or bottom-up.
When programs are designed bottom-up, the programmer identifies all the individual actions that need to be done, and places these into self-contained modules. The higher levels in the program are then designed, and these execute the modules in the correct order. These higher levels are placed in the final structure at the appropriate place.
In the top-down approach, the problem is defined at the highest level, and worked on through successively lower levels, each stage being refined more and more until the detailed solution is arrived at.
Program designs are often represented as a tree like structure read in a top-down manner. As we go down the tree, each level is an expansion of the box in the previous level. An example of a structure chart (or structure diagram) is shown below.

The * in the corner of the main process loop box means a repetition, i.e. many records are to be processed. The o shows a choice, one or the other, but not both, and indicates only one option path alone can be followed.
We should also note that at each branch at each level, the order of processing goes from left to right. This means that in the initial process the open files command must come before the print report headings command is used. We can see that each box is expanded at a lower level to give more detail. We might consider that the box print record details needs further expansion. Is it information of all the record, or just some fields? This process continues until the programmer decides that sufficient detail is provided. This is called functional decomposition.
The structure chart shows how a program can be modularised. The topmost level can be regarded as being the main control procedure in the finished program, and this can be broken down into three separate parts or procedures. The programmer works on each as a separate unit that will be put together as a complete program, and he must know how it will be put together. It’s like breaking down the power unit of a car to engine, gearbox, differential, and drive shafts. It would be no good if the engine could not fit onto the gearbox.
Do initial process
Do main process loop until file has ended
Do final process
End program
Open files
Print report headings
Refinement 3.1 - Main Process Loop
Read a record from the data file
If at end of file, then display “END-OF FILE” message
Else
Do process record
End if…
And so on…
Each instruction is written in a form of structured English called pseudo-code, which does not relay on the syntax of any particular language; it is language independent. Therefore the systems analyst who designed the specification does not necessarily need to know the language it’s going to be programmed in. The analyst and the programmer can discuss the application using the pseudo-code and can iron out any problems at this stage.
This kind of planning allows problems to be identified at an early stage before everything is put onto computer and tested. Sorting out problems (debugging) once they are in the computer is most very tedious.
Question 11 What is the difference between pseudo-code and lines of a computer program such as Visual Basic? ANSWER
Now
go on to Role of Computer Staff