Using a process model to do analysis
Results Management System Example
Choosing the aspects of a system to include in a model
The sample DFD I drew in the lecture to show the results management system is only one of a large number of possible ways of representing the process elements of this system. In the same way that two people could write different, but equally correct text-based descriptions of how the information processing is done, so also could two people draw somewhat different, but equally correct process models of this system.
The differences between different people’s models will come from two things:
· they use different methods of representing/describing it;
· they focus on different aspects of the system in their description.
This is exactly the same as would occur in any situation describing/modelling any object. For example, if I set two people the task of drawing/describing a house, I would be amazed if they produced identical descriptions. The differences would come from the same factors I have listed above. An example of the first type of difference would be that one might draw the house from the front and the other might show a side-on view; an example of the second kind would be that one might include details of the materials used in construction (timber walls, tiled roof) while the other might focus on their colour/appearance (blue painted walls, red roof).
Note that neither of these would be more or less accurate than the other, but the decision as to which of them was more useful would depend on the circumstances in which they were being used. For example, suppose you were employing builders to build an extension to a house, and your description was being done to tell the builders what you wanted. For the builder dealing with the structural details of the renovation, the house description which included details of the building construction materials would be of greater use than the one describing the colours. However, for the painter/decorator trying to choose a colour scheme for the painting of the extension, the house description which included details of the colour scheme would be of greater value.
Good analysts choose the features to include in their model according to which aspects of the system they wish to highlight.
The following three examples, from the tute exercise try to demonstrate this point. In each case, I consider examples of information which I have chosen to omit from the initial basic system model which I developed in lecture 7, but which could be chosen and added to my system description if circumstances required it. I will first deal with each example separately in terms of its effect on my original solution, and will later look at the combined effect of all these changes, and how it might affect my diagram.
Example 1: Sourcing the students file
In my original answer, I showed the results being stored in a file called ‘students’, but did not show the source of that file. This would be appropriate if, for example, I wanted to focus on the processes which deal only with the way in which marks are calculated and disseminated. If this were the case, I might be happy to take the existence of the ‘students’ file as given and not worry about showing how it was originally created. But what if I do want to show this? The system description says that it is provided to the unit leader from the Student Records System. Using the same method I used for the original construction of the DFD, I can develop an action-process table entry as follows:
Action
/ Logical Process / Input(s) / Output(s)Unit leader is sent a class list from the Student Records System / · Download unit enrolments / · Student enrolments / · Unit enrolments
This gives me the following data flow fragment:
The source of the ‘student enrolments’ flow is the Student Records System, and the ‘unit enrolments’ flow is stored in the ‘students’ file. From this it is easy to add this fragment into the original DFD model. (See Example 1 DFD)
Example 2: Describing the processing of Withheld results
This is a slightly more complicated situation which deals with some details of information processing. I chose to leave out of my original model any consideration of the details of the process by which WH results are finalised. A reason why I may have done this could be because WH results are relatively unusual events which require their own special processing, and I may have wished to focus only on the main sequence of information processing which handles the ‘normal’ results.
What if I decided to make my model more complete by including the information processing of WH results? My list of actions (see step 3 of original solution) contained the following three information processes which related to the processing of WH results:
Faculty Office monitors all WH results
Faculty Office notifies unit leaders of WH grades
Unit leader completes Change of Result form
Following the same steps as were set out in the original answer, I can convert these actions to logical processes as follows:
Action
/ Logical Process / Input(s) / Output(s)Faculty Office monitors all WH results / · Monitor WH results / · Submitted student results / · Student WH results
Faculty Office notifies unit leaders of WH grades / · Notify WH results / · Submitted student results / · Outstanding WH results
Unit leader completes Change of Result form / · Amend WH result / · Student WH result
· Other assessment results
· Extra assessment result / · Student revised result
A brief inspection of these suggests that the first two are so closely linked as to make it simpler to combine them into a single process – I can’t see that there is any good purpose having them as separate, so I finish with two data flow fragments as follows:
I now need to fit these into my original diagram. From a quick inspection of these flows, and thinking about their place in the overall processing, we can see that the ‘submitted results’ flow must come from the Student Records System and the ‘student revised result’ flow must flow to there. The ‘Extra assessment result’ must be provided by the Lecturer, and the ‘other assessment results’ would be stored with all the initial results in the ‘students’ file. The details of students with WH results would have to be stored in order to be sent to the lecturers, so we can assume a file of WH students for the other flows relating to WH students.
Given these assumptions, we can now fit these two fragments into the original DFD as shown in Example 2 DFD.
Example 3: Detailing the ‘assignment results’ data flow
Example 1 related to adding details about a data store and Example 2 related to adding details about extra information processes. This example relates to adding more details about a data flow, using the ‘assignment results’ data flow to illustrate.
The original model showed ‘assignment results’ as an input data flow coming direct from tutors to the ‘calculate results’ process. The system description does not actually describe how this happens, so this model is a reasonable representation of what the description says. I may have kept these details out of the system (as I have also done for exam marks) because I am concerned with showing what happens to the results overall, rather than describing what happens to the assignment and exam mark components.
What if I do want to include some details about how assignment results are handled? If you stop to think about how the process of calculating the results will be done in a class with many students and many tutors, you would quickly realise that the way in which each tutor provides their assignment results to this process is an important issue for the system.
If you asked about what really happens, you would find the following: First, a list of students enrolled in each tutorial is created from Allocate+, and then these tute class lists are given to each tutor. As assignment work is handed in, tutors mark it and record the results for each student on their class list. At the end of semester, the tutors provide to the lecturer a copy of their tute list with the assignment results for all their students. The lecturer then can combine these assignment results with the exam marks to calculate the final results for each student.
Using our usual Action-Process table, this give us the following:
Action
/ Logical Process / Input(s) / Output(s)Tute lists for each tutorial class are generated from Allocate+ / · Record tute classes / · Tutorial enrolments / · Tute class
Tutors record assignment results for each student in their tutorial class / · Record assignment results / · Assignment results / · Student assignment results
Assignment results for each tutorial class are given to lecturers to calculate overall mark / · Calculate result / · Student assignment results
· Student exam result / · Calculated result
This gives me two new data flow fragments for the first two processes, while the third one “calculate result’ is already in the original solution. The new fragments for the top two processes are as follows:
I can say with confidence that the source of the ‘tutorial enrolments’ data flow is the Allocate+ system, and the source of the ‘assignment results’ flow is the tutor. The output flows from these processes go to the same data store. (Note that the tutors may physically keep two separate files – their original class list from Allocate+, and a copy in which they record the assignment results, but in terms of a logical DFD, I need only one data store). This data store then becomes the source of the assignment results flow into the ‘Calculate result’ process.
These data flow fragments can now easily be fitted into my previous solution (see Example 3 DFD).
Combined effect
For simplicity’s sake, I have considered each of these modifications separately, but what happens if I combine them all into one diagram? I have done this with a bit of minor re-organisation, and at a reduced scale to fit it all onto page (see Example 4 DFD).
Looking at this solution, the diagram now starts to get very messy and hard to read. My original solution with 6 processes fitted within the general guideline of no more than 5-7 processes in a diagram, but now I am up to 11 processes. I have managed to keep it down to only one crossed data flow line, but with this many processes it is hard to take it all in. This means it is time to consider the use of partitioning, which I will cover in a separate document (see Partitioning Example).
Conclusion: Deciding what to include in a DFD
I hope this example further illustrates firstly the sort of thinking you need to use when analysing a system and constructing a DFD, and secondly that a DFD is a system description which can be added to and modified to highlight or omit selected aspects of a system.
The additions I have shown here are all aspects of the information processing of results, which I did not include in my original solution. This does not mean that my original solution was wrong; it was just a selective simplified version of the processing. No model can show everything, so every model you develop is a selective simplified picture of the real world system. The art of good analysis is knowing how to choose:
· the method of description which best suits your analytical purpose, and
· within that method, the system features which are of greatest importance and need to be highlighted in the model.
Note that as you draw a system model, questions begin to arise about different aspects of it. Part of the purpose of modelling is to raise these questions, so you can clarify exactly what happens and what parts of it need further explanation.