Assignment 10 (Due: February 10, 2012, before 01:00pm)

Assignment 10
With reference to assignments 8 and 9, what characteristics does an analyst (you) examine when evaluating DFD quality?

Data flow diagram is a graphical way of representing a data flow in a system. It is an effective way of overviewing a system in a very clear manner. In planning a system, DFD must be presented because by viewing the diagram, you can determine what is missing and what is to be removed in the system flow. In making a DFD, we make sure that the details are correct and every process has been evaluated to insure the quality and integrity of the DFD. In making DFD, we must also follow some guideline to follow and some characteristic that needs to be developed.

When I evaluate the data flow diagram quality, I evaluated first if the structure is match to the real system. When evaluating the DFD, by just viewing it as a general structure, you can see what it means because DFD is a diagram that explains the context of the system in a simple manner. I can say that it is very understandable when we look at it because DFD especially those context diagrams which is a part one of the DFD is being created for those people who are not so technical in nature. You need be analyzer and a good cretic so that you will know if the DFD is being built for a specific system and not for the foreign structures. In criticizing a DFD, we must be reminded that we need to see the actual structure before criticizing the DFD structure. That must be in the first of your list in evaluating and criticizing DFD.

In the DFD part, when examining it, you must first know the structure and every details of the diagram. You need to know first the function and limitation of the structure inside the diagram. To know the diagram first is the first step in examining the diagram. The structure is a very important aspect to be examined in the DFD. In the structure, you will know the basic functions inside the diagram and the limitation will be uncovered. You must examine the broadness of the structure and you must determine the range of it. Broadness is talking about how general the structure is and the range is the distance between the general aspects of the diagram to the more specific structure. As I understand the question, I formulated an answer with two points. The first point is the physical characteristic of the DFD and the second is the logical structure of DFD.

The first point is for the physical characteristic which is talking to the physical attribute of the diagram. When examining diagram, you must understand every symbols inside the diagram. Like the starting state, end state, all those process and other function inside the diagram which has a physical attribute. Physical attribute is what you see in the diagram and what everybody sees even thou they are non-technical people. Physical attribute is the first to be evaluated if I will be the analyst because physical attribute is the syntax of the structure. I can say that it is the syntax because if the symbol is not in the proper position then the diagram fails to serve its purpose because it does not follow what is proper. Like arithmetic function, if your syntax is incorrect then it will give you the wrong answer. In physical attribute syntax will be the first security for the correctness of the diagram. It must be evaluated to proceed in the next process.

The second point is the logical characteristic of the diagram. When we talk about the logical characteristic, we are pertaining to the logical structure which talks about how we understand the process in the diagram provided. If we are finish evaluating the physical structure, the next security feature is to evaluate the flow of the system, data and every object inside the diagram. The example of a wrong logical structure is when you have a data let say a student data then it will an input data to the admin division which is incorrect in nature. Student is not related to the admin because admin and student data is different. We can say that the correct interpretation of a logical structure is that the subject will be an input of the student which is enrolled to a different course. I must say that evaluating the characteristic of a logical structure of DFD is the difficult par. Logical Characteristic is not visible to the human eye but it will just be visible if you will analyze and understand the physical structure. In this level, the non-technical people will not be effective in this field. In the characteristic, it is more on understanding and not calculating. The said characteristic will be the life of the diagram and the physical structure will be the backbone. The logical will always be the brain of the diagram and we need criticize it carefully because the common problem of an analyst comes from this section.

The physical and logical characteristic must work together. This two are the one who made the diagram possible. In the human form, the logical characteristic will be the brain and veins or maybe the soul and the physical characteristic will be the bones and muscle. The physical characteristic will hold the structure and prevent it from collapsing and the logical characteristic will be the controller. The two are important and if something wrong with either of the two, the diagram will not work properly. For me, physical characteristic is almost visible for everyone because in this area, you have clear guidelines and you need a less effort and less thinking skill for this one. In the logical characteristic is a different story because you need to have more intellectual property which is the analization, critical thinking, good observation, and other property that require a large portion of the mind.

The composition of a physical structure is those who are physically very visible in human eyes like the actor, the process, the system. It is noticeable and if there is something wrong, you can figure it out easily. In the logical composition can’t be seen because they just exist inside the physical structure. They seem to be visible because the physical structure allow them to appear like they are present outside the diagram but in the reality, they just exist inside the diagram. In logical structure, you can correct them using the physical structure. You can manipulate them using the physical structure. It is somehow confusing but logical structure is just an imaginary variable for me. For me, it is an object with an object that’s why they are hard to detect because they leave inside the structure.
In examining diagram, you must not always look in the diagram itself because another way to examine a diagram is to examine your characteristic. You also need to examine the one who evaluated and make the diagram to evaluate the diagram itself and the thing that you need to examine is the characteristic of the evaluator which is you, I and them. Your characteristic must not always be in focus about how beautiful and organize a DFD is but you must be focus on how it is related to the system. As a starter analyst, I need to set my mind on the goals of the DFD. This means that I need to focus on what will be the function of the DFD and not how beautiful it is or how organized it will be. I must stick on how it is related and how it describes the object which is the system. Focus is also a good characteristic of an analyst when evaluating DFD because if you are focus enough, you can’t be destructed of how the other sees the diagram. You will not be affected of the comments of your co analyst but you can always use their words. If you are also focus, your decision will be more concrete and accurate hence accuracy is a very important thing that the analyst must have. For me, to be focus is an occurring event and my focus is dependent in every situation. Sometimes, I lose my focus when I am not interested of what I am doing. I also lose my focus if something is destructing my way of thinking like problem that I encountered during class hours or having trouble outside with my friends. I need to get rid of it when someone or something is destructing my way of thinking.

Another characteristic of an analyst must have when he/she will evaluate diagram is interest. In evaluation, analyst is not effective if they lose interest. If they don’t like the things that they are doing, the percentage of making the evaluation right will be going down. Interest is a powerful characteristic because if you will have lots and lots of interest in your field and the things that you do, you will make it sure that you will do it right. You will never allow yourself to lose focus and you will be happy of what you do. Interest push the analyst to their limitation and surpassing limitation is a key for progression. You will be more effective if you will always do the things above your limitation and is a sign of a good system analyst. Interest will not assure you of making your work done with one hundred percent accurate but it will help you to make your work done with all your best. Interests will always guild the analyst in a right track in evaluating DFD. Doing things without interest is not a characteristic of a good analyst in evaluating the diagram but it will just make the analyst to be like a robot because robots have no emotion and they are always be in their level as the programmer programed them. I do believe that interest must be included in the characteristic of a good analyst because if not, that analyst will not accomplish something or not satisfying the needs of the client. If you will be interested in evaluating the DFD, you will be more observant of every detail in the diagram. You will not be hasty to give your evaluation because as I said, you are interested and interested people will show interest to their work and give an extra effort in evaluating the diagram.

To be an observant in every details of the diagram is another characteristic of an analyst. This is important in evaluating the diagram because if you will be observant in every details of the diagram, you will discover if something is not right about the DFD structure. An observant characteristic will unlock those unseen error and it will provide the analyst a vision of correctness. Accuracy will not be a hindrance if an observant characteristic will flow inside the attitude of an analyst. A keen mind widens the perception of an analyst in examining the diagram and the wider the vision is, the more effective the diagram will be. Another advantage of a good observant is you will never see the diagram as a general concept or general system hence, you will see a variety of different structure and different interpretation. Seeing a different structure in a diagram will make your evaluation to be more flexible because you will not just evaluate it as a single structure but you will also consider those variety of interpretation that my come up during the evaluation time. If the analyst will observe that the diagram is in general form, by the power of the observant mind, he/she can turn the table and make it to be more specific and accurate in describing the system with the use of the proper diagram.

Correctness is a characteristic of a person which assures all things in accurate manner. Seeing and evaluating diagrams doesn’t mean that you will just observe the diagram itself. Before and after the diagram is being implemented, you must check the physical structure of it. To see is to believe and when evaluating a diagram, if the physical structure of the diagram is presented, you need to look at it and evaluate if the diagram provided is the diagram for the structure. In evaluating diagram, you must be correct always in your evaluation because your opinion is a crucial part of making a system. Correctness is a prevention of a further damage that may occur during the development of the system.

In systems analysis and design, there are a lot of tools used to understand fully the structure and the different processes of the system being studied. One of the tools used to recognize the structure of the system is by the use of visual diagrams. Visual diagrams help people to know the general overview of the system, which eventually would lead to the understanding of the whole system when presented with more types of the visual diagrams. There are many types of diagrams to model the systems. They may be diagrams that show the structure of the system or diagrams that depicts what happens in the system. There are also diagrams that depict the flow of data. One of them is the data flow diagram or DFD.
Data Flow Diagram
Data Flow Diagram or DFD is a structural diagram that illustrates the flow of data from external entities into the system, shows how the data moved from one process to another, as well as its logical storage (Ambler, 2009). Data Flow Diagram shows how the data is processed by a system in terms of inputs and outputs (SmartDraw). In short, DFD’s illustrates how the data flows and how it is handled by the system.
Data Flow Diagram Symbols
In Gane and Sarson notation of a Data Flow Diagram (Ambler, 2009), there are four symbols used to illustrate the flow of data.
• Squares for External Entities
Squares represent the external entities of the system. These external entities may be the source or the destination of the data. For example, in an enrolment system of a university, a student gives his or her basic information to the University for Them to have a record on him. Therefore, the student is a source of information and thus is drawn inside a square or a box.
External entities are named appropriately. Squares of the same name can be duplicated one or more times to avoid line crossing on the diagram. With this, the diagram would be much cleaner or organized well. In identifying an external entity, one must determine first the system boundary. The system boundary is the limitation of what the system is able to process. The external entities should be outside of the system being studied. External entities are usually beyond the area of influence of the system developer. Meaning, there are instances that some external entities could be omitted unintentionally. Thus, identifying external entities should be done carefully.
• Rounded Corner Rectangles for Processes
The rounded rectangles represent the processes of the system. Inside the rounded rectangle, there is a two-partitioned space or sometimes there are three. The top partition shows a number that depicts its process number or its order on the system. In the middle is the name of the process that is to be used. And on the bottom partition, it is written there the actor or the person involved on that particular process. It is him or her that receives the data and processes it. The processes we are talking about are the processes that take data as an input and do something to it; example is outputting it or storing it to a database.
Processes show that there is a change or transformation of data happening. So when there is a transformation, then it is obvious that there is an input data and an output data. Naming of the process should also be done rightfully. In naming the process, it should consist of a verb and an object of the verb. There is no subject on the name of the process and the word “process” should not be present on the process name. Each process should also represent only one function or action. So if there is an “and” on the name, then there are already two or more processes or functions. That process should be separated then.
On a system, there could be leveling of processes. With leveled processes, there are some processes that are sub-processes of a process. So to identify them easily and clearly, numbering the process is allowed. For the sub-process, one could identify them by using a decimal notation. For example, a main process has 3 sub-processes. So the main process, assuming it is the first process, would be 1 and the sub-processes would be 3.1, 3.2, and 3.3.
The arrangement of processes in a data flow diagram is generally from top to bottom and left to right. This is done to have a uniformity of the diagrams. It would also help to read and understand efficiently the flow of the data.
• Open-ended Rectangles for Data Stores
These open-ended rectangles are the data stores or storages. When we mean data stores, it could be physical or logical. Logical data stores are the databases or the XML files of the system while the physical data stores are the filing cabinets or the stacks of papers. Data stores are important because it has the summary of all the information gathered and to be used by the system.
• Arrows for Data Flows
Arrows represent the direction of the data flow. It shows where the data comes from and where the data goes into. It connects the three other shapes mentioned earlier. The data that we refer in the system may be the electronic data or the physical items such as the documents and papers.
When there are two or more processes that output data that flows to the same destination, then the arrows could be joined. This also means that when same data goes to two or more separate destinations, then the arrow could be forked or divided into multiple arrows going to multiple paths.
One thing to mind about the arrow or the data flow is that it should represent data only and not the control. To show the control of data, one can do that by using another type of diagrams. For in data flow diagram, it only shows how the data flows in the system.
In naming the arrows or data flow, it should be done by labeling it with the specific data that is passed either as an input or as an output. The name should not contain the word “data” for it is obvious already that the arrow represents a data.

[/url]
Figure 1. Symbols on a Data Flow Diagram or DFD

Constructing Data Flow Diagram (DFD)
To construct a quality data flow diagram, a procedure should be followed so that we could be ascertained that the diagram we are making is correct and understandable even by a person that does not know a data flow diagram.
1. Identify and list external entities.
The first thing to do, and one of the most crucial parts in constructing a data flow diagram, is to identify all of the external entities. As what have mentioned previously about external entities, these are the objects that are beyond the system boundary. They are usually the source of data that goes into the system.
2. Identify and list input and output data.
The next step is to list down all the input data from the external entities to the system and all the output data from the system to the external entities.
3. Create the context diagram.
After identifying the external entities and the different input and output data, a context diagram could now be drawn. A context diagram is a diagram that shows the flow of data between the system and the external entities. The system is on the center and surrounding it are the external entities. The system is represented as one process that receives data from the external entities and outputs data to the external entities.
4. Identify business functions.
Now that we have the context diagram, we could now delve deeper on the specifics functions and actions on the system. So we have to list down all the processes of the system.
5. Identify data connections between business functions.
As we are in knowledge that processes are done sequentially, we now have to identify the correct sequence of the processes. We also have to determine the data that flows between them.
6. Confirm data distribution and reception.
Next is to confirm that the data from the external entities goes into the system and is received by the correct process that needs the data.
7. Trace and record the data flows of the system.
Tracing and recording the data is done to ensure that the data flow is correct and there is no data that strayed to different process.
8. Connect diagram segments.
If there would be segmented diagrams, then we should find the connection between those diagrams. If possible, there should be no segmented processes on the system. All processes should be connected to each other.
9. Verify data flow source and destination.
We should now verify that in every process, the data that goes in must go out, even if there is no transformation of data that happened. In this step, we should check if there is an existing diagramming mistake such as a black hole, grey hole, or a miracle.
Black holes are processes that have input flows but do not produce output flows. Grey holes, on the other hand, are processes that produce output that could not possibly be produced given a certain input. And lastly, a miracle pertains to process that does not have any input but was able to produce an output flow.
10. Simplify and redraw the diagram.
After checking that there are no errors on the diagram, we could now simplify the diagram and redraw it to finalize.
11. Repeat step 1 if needed.
If still not sure on the finished diagram, we could go back to step 1 and verify for any changes that occurred in the new diagram that did not appear on the previous diagram.
Characteristics of a High Quality DFD
A high quality Data Flow Diagram should be:
• Accurate
A DFD’s accuracy is measured in terms of the number of the diagramming mistakes present such as the black holes, grey holes, and miracles. A high-quality DFD should not have any of these mistakes. To avoid the mistakes, one should follow carefully the guidelines on how to construct a data flow diagram.
• Readable
A Data Flow Diagram is readable when it is not too complex. Too much complexity could result to hard time in tracing the flow of data. Following the rule of arranging the processes from top to bottom and left to right would really help to decrease the complexity of the diagram. Numbering of the processes would also increase the readability of the DFD. Proper naming of the components of the system should also be done rightly.

Melissa B. Carpio
BSCS 3



The previous assignments we had in our subject were related to diagrams, particularly the activity diagram and the different types of data flow diagram. In assignment 8 and 9, we were tasked to design activity diagram and data flow diagram for the pre-enrollment system of USEP. Here in assignment 10, we are tasked to discuss the characteristics of how an analyst examine when evaluating Data Flow Diagram quality. Before I discuss what characteristics an analyst examines when evaluating Data Flow Diagram (DFD) quality based on the assignment 8 and 9, let us first understand what a DFD is and how is it important in the preliminary phase in a certain project.


Understanding Data Flow Diagram…

A Data Flow Diagram (DFD) is graphical representation that shows the process, flow of data, and other external entities that works within the system. DFDs transform information from input to output in the system. By the name itself, data flow diagram, it consists of different symbols that have specific usage in order to identify the flow of the data. The most commonly used symbols are the arrows, which represent the data flow; the rectangular box, which represents the external entities, the source or the destination of the data; the rounded squares, which represent the process of data, from input to output. Some points are needed to be considered when dealing with data flow diagrams, where the information being inputted came from and where would the information go after being processed; what would happen to the data as it enters in the system and what would be the possible outcome of it; and where would the output go after the process. There are different levels of dataflow diagram, the Level 0 diagram or the context diagram and the Level 1 data flow diagram. The Level 0 diagram or the context diagram shows the direct flow of data from the source to its destination. It depicts a single process of the system with different source of data. The Level 1 data flow diagram shows the system’s preliminary processes, the data stores, sources, and destinations of data linked by data flows.

Even if data flow diagrams are useful to the analysts when it comes to planning n making a system or handling a project, there are still pros and cons in dealing with DFDs.

Pros...
* DFDs give further understanding on the underlying system and sub-systems.
* It basically gives the over-all summary of the system.
* It serves as one of the blueprints of the project, thus making it an important file.
* It serves as guide to other members of the team since developing a system is not part of the work of an analyst.
* Since DFD is a graphical representation of data flow, it would be easy for the team to trace errors when handling the system.

Cons…
* When a client desires to have a complicated system, the first problem would be making a complicated data flow diagram also to ensure the proper flow of data in the system.
* Some data flow diagrams that are designed may not be followed thoroughly because in actual designing of the system, it could be interpreted as a complex system.
* DFDs that may not be designed clearly can confuse the other team in understanding the flow of the system.


Data Flow Diagrams: Systems Analysts’ helpful tool

The complexity of a certain system can be visualized with the use of the data flow diagrams. It is a very helpful tool for the systems analysts especially in the preliminary phase in planning to create a system. For me, data flow diagrams could be very complicated when in terms of the number of systems included, the external entities related to the system and the flow of each data from the source to the destination. But on the helpful side of data flow diagram, the analysts can visualize the flow of the data in a system. He can anticipate the problems that may arise as the flow of system is analyzed. The system would be at risk if the systems analyst would not deal with the data flow diagram first before going to design the system. Every planned system of the systems analyst must have DFDs to support their planned system.


On Evaluating Data Flow Diagram quality…
Now on the main purpose of this assignment, what characteristics does an analyst examine when evaluating data flow diagram quality? To answer this question, here are some of what I did and anticipate in order for my data flow diagram to be understood (hopefully…) by others.

Data Flow Diagram must be readable. According to our interview with Sir Rex Bugcalao, the work of a systems analyst is to design a system that is fit to what the client wants. The designing includes creating a data flow diagram of the system. Data flow diagrams are essential in designing a system since it is the basis for the flow of the system. In order to attain the principal use of the DFDs, it should be readable enough to understand the data flow of the system even if the one looking at the diagram is not an analyst or a part of the team, it should be understandable enough so that there would be no hassle in the part of other team members and for the future developers of the system.

Minimal Complexity in DFDs. Most complex systems come from complex plan on the data flow diagram since it is the basis in designing the system. Making a data flow diagram would really take time and understanding to include all possibilities that the system may execute and perform. Too much information and possibilities that the team considers would be a burden in their part because it could lead to misunderstanding since a lot of information must be dealt with. In order for this not to happen, the analyst will just deal with the levels of DFDs, deliver the diagram clearly and not to commit misunderstanding at the start of the preliminary phase.

Consistency of the DFDs. The DFD is an essential tool in creating the system needed by the client. Any form of inconsistencies in the DFD can result to a dilemma in developing the system. First problem would occur on the members of the team in developing the system. The plan would start from the systems analyst, which includes the making of the data flow diagram and other diagrams that depicts the system. In order for the members to start what they supposed to do in the system, they first look at the DFDs made by the analyst to know the flow of the system. The members should be critical enough in understanding the flow of the system since they are the ones who will develop the said system. If one of the entities does not correspond to the DFD designed, it could create inconsistency in the planned system and the actual system. Second problem may occur when after the development of the system; the client tends to change some of the details in the expected system. The designed DFD now does not jive from the expected system of the client. This will cost time for the systems analyst since everything is set but there arrived changes in the plan.

Inconsistencies inside the DFD can be identified easily by merely looking at the structure of the diagram. Some of the common consistency errors are pointed by Satzinger and others.

* The different approach on the data flow content between the physical process and the internal process of the system or the process decomposition. For example, an enrollment data flow that appears on a level-1 diagram, but not seen on the level-0 diagram. That would create a consistency violation on the DFD.
* The input data that does not correspond to the output data could lead to inconsistency in delivering the data inside the system.
* The output data that is not expected from the given input data is also considered as inconsistency in the flow of data in the system.

Understanding Black holes, Grey holes, and Miracles. There are several diagramming mistakes that may occur in creating a DFD. These mistakes should be critically examined by the analysts and it should be primarily considered to ensure that the designed DFD is capable of delivering the expected system needed by the client. Black holes and miracles are commonly mistakes that can be evaluated easily. Black hole is a situation where in the processing step has an input flow but there is no matching output flow. For me, it is called black hole since the process of the input flow leads to an unidentified outcome. Miracle is another situation where in the processing step may derive an output flow but no corresponding input flow. Same as the black hole, it is called miracle since there is no specified input flow but there arise an output flow of data, which creates a question, where could this output flow came from without having a corresponding input flow? Lastly is the grey hole, a situation where in the processing step may haw an output but is not adjacent to the input, it may be that the output may be greater than the sum of its inputs.


Source:
http://www.hit.ac.il/staff/leonidm/information-systems/ch24.html
http://it.toolbox.com/blogs/enterprise-solutions/data-flow-diagrams-dfds-14573
http://faculty.babson.edu/dewire/Readings/dfdmistk.htm

In this chapter I will discuss the characteristics of an analyst in evaluating the Data Flow Diagram. But before getting to the main point of this assessment let us know first what a Data Flow Diagram is because not all of us know the true meaning of it.

Data Flow Diagram from the name itself it is the flow of information that is represented diagrammatically. It is sometimes understand by the other as steps of the system. It is a guideline to the others on how to approach the phases in each system or what is next after finishing the last phase. Data Flow Diagram is basically used in the designing phase in building a system. It is a system modeling tool in structured analysis and design.

To understand this tool deeper they are notations in this tool in my reference there are 5 notations in DFD to show the passage of the data through the system by using basic constructs.

• Data Flow – it shows the flow of the data represented by the arrow line with arrow head. It can move from external entity to process, from process to another process and from process to an external entity.
• Processes – these are transformations which change the incoming data flow to outgoing data flow. The name of the process must describe what may happen to the data when it passes through process. It is represented by circular boxes.
• Data/Stores – this is depository of the data or we can say the database. The data/store is represented by parallel lines and between those lines is the name of the data.
• External Entities – it represents the external process of the regular flow. It is in the outside of the system boundaries.
• Resource Store – it represents the flow of the material in the system than the data.

After knowing the basic notations of the Data Flow Diagram we can’t make an efficient Data Flow Diagram if we don’t know the rules in creating one. There are basic rules that must be followed in creating Data Flow Diagram. The rules are classified in two parts according to arifinfo. The two parts of the rules are in drawing and naming in the diagram.

Drawing
• Each process must have input and output. There should not be a process that have no input or output.
• Each store (data storage) has input and output
• It is possible the presence of data storage read-only (read-only)
• There can be no flow of data between stores (storage)
• There should be no flow of data between entities
• The diagram should be balanced at all levels
• The flow of data in and out of context = data flow diagram and out of the diagram 0
• All diagrams parent / child must be balanced
• At each level of the diagram must have a data store

Naming in the Diagram
• All elements must be named
• Use a specific name and meaning
• Data streams are named after the stream of data records, forms, and orders
• Flows that have not been given the name represents a complete record
• Datastore named after all data, records, forms, orders recorded
• The process must be numbered in a hierarchical
• 1.2.4 is a sub process from 1.2
• External entities are named according to what is represented, people, organizations, and other systems.

These rules are given by the arisinfo just basic rules in creating the Data Flow Diagram so that the result of the Data Flow Diagram is organized and every user can understand it. After the rules I had done a design in my previous assessment in that assessment we have made 3 types of the Data Flow Diagram. Knowing the types of the Data Flow Diagram let us understand each function of the flows of the data because there are many types in creating Data Flow Diagram. I had used 3 types of DFD the first type is the Context Diagram, then Physical Diagram and the Logical Diagram. First let us discuss the Context Diagram.

Context Diagram – the highest level in the data flow diagram is this and it is contain only one process that representing the entire system. The diagram does not contain any data stores and the process is will pass on the external entities as well the major data flow.

Physical Diagram – are the technical blueprints for the system construction and implementation. This is the done after crating the logical diagram. It serves as the guide in constructing new system.

Logical Diagram – It will show us how the business operates and it describes the event that will take place, data that will require and how the business will operate.

These are the simple meaning of the 3 types of Data Flow Diagram. Each type has a purpose in building it. Each diagram is use base on the needs of the system on how we will design the system. The next in line is let discuss about the guidelines in creating the Data Flow Diagram. This guideline is based on the article of Jagdish Grangolly.

• No more than 7 – 9 processes in each DFD – for my opinion in this matter I think he include this so that the system that the system analyst or designer is creating is not too long to finish all the process. If there are processes that are redundant in the system it can be merged to the other processes so that the processes are lessen.
• Data flows must begin, end, or both begin & end with a process – this statement is understandable to us because it is so rude to make a Data Flow Diagram that is hanging or no end process. All systems have their beginning and ending process.
• Loops are not allowed – loops in the Data Flow Diagram make the diagram unorganized. If there are processes need to be back to the previous process it is safe to build a new process that conveys the looping process and pack it up with the next process that the process will go on next to.
• Naming Conventions – the author said that naming process we should use strong verbs for the data flows, data stores and external entities we should use for naming are nouns. I think for naming the processes and the other entities in this way make the diagram more organized and easy to understand.
• Data Flows must not be split – For my understanding in this guideline is that when the data is pass to the next process it is not be split to the other processes. It should give only one output and it will direct it to the next process of the diagram.

These are only five of the guidelines that the author wrote in his article. The author mention lots of guidelines but I only pick five that I have understand fully the rest are technically. Following guidelines in making the Data Flow Diagram makes the diagram more understandable and more organized. But let us know the advantages in using Data Flow Diagram. In the article that I have read the author point out only three advantages. And these three advantages are:

• It is a simplified but powerful graphic technique
• It enables representing data with different levels of details.
• It helps defining boundaries of the system

By using Data Flow Diagram set the systems boundaries and the flow of the information that is passing in each processes. Designing the flow of the data will help the developer understand the system and set their work to the needs of the system and the flow of the system. Data Flow Diagram is the backbone of the system because it serve as the blueprint of the developer to come up a better system. Data Flow Diagram is one of the requirements in creating a new system this will not be forgotten in creating a new system.

Now let us get to the main topic of this assessment. The characteristics that the analyst examines in evaluating the Data Flow Diagram are first the flows of the data the analyst must know where the data or the information will after the process. The analyst must be a critical thinker so that the analyst must know the possible risk and make alternatives throughout the risk that he/she found out. The analyst can understand the business flow of the system and the needs of the end user so that he/she can meet the wants of the end user. The analyst must examine the organization of the Data Flow Diagram so that the implementation of the system is well organized too. It is hard to implement when the Data Flow Diagram is not well organized because the flow of the information or data is will not be organized too. The analyst must follow his/her guideline in creating a Data Flow Diagram or must have a guideline to follow so that the flow of the data is well organized. And lastly the analyst must have a background or knowledge in business so that he/she can understand the needs and wants of the end user because when a system analyst is put to work he/she is not only focus on building the system the client needs but to understand the best alternatives that the client will accept.

References:
https://docs.google.com/viewer?a=v&q=cache:FFRxJwIUifMJ:me.emu.edu.tr/ie447/CIMLectureNotes2011.pdf+physical+data+flow+diagram&hl=tl&gl=ph&pid=bl&srcid=ADGEEShjLqCiQvTGoI4QOAHWJLe3e9Cnq2Kk3RargHqtF3nWO63poravErMJmAodpCKOLglCycgvSWxvXoQZAVKSSCPOwJe6IJi4BB_GK-TOEfcdweoD4JZHGSG99lQe6iPCaRmVRv5f&sig=AHIEtbTju2U80s0PCCOejc1XYPoVQf34Gw
http://www.jscgroup.com/physical-data-flow.html
http://www.albany.edu/acc/courses/acc681.fall00/681book/node31.html
http://www.blurtit.com/q808726.html
http://arifinfo.com/2011/06/18/rules-in-creating-data-flow-diagram/
http://www.xamplified.com/data-flow-diagram/

As an introduction to the assignment ten, base on the assignment eight and nine we are task to make an UML Unified Modeling Diagram-different diagrams that can illustrate a process or system, in our case we are task to illustrate the pre-enrollment of University of Southeastern Philippines. In assignment eight we are task to develop an activity diagram and a fully developed description for a use case. Activity Diagrams are usually used to a business process model, for modeling the logic captured by a single use case of a business or a system, it is also for modeling the detailed logic of a business rule or the rules of the system how it works. Creating activity diagrams are very useful in describing the flow control of the target system. It is also helpful in determining the use cases and the business processes of a company or a system that a company may use. With the assignment nine we are task to create at least 3 different types of Data flow diagram of USEP's pre-enrollment system. First we defined what data flow diagram is all about. Data flow diagram is a graphical representation of data on how the process goes in the system or business. According to Scott W. Ambler data flow diagram shows the flow of the data from external entities into the system, how the data moved from one process to another as well as its logical storage. Data flow diagram can also be used for the visualization of data processing. A Data flow diagram provides no information about the timing of processes, or about whether processes will operate in sequence or in parallel. It is therefore quite different from a flowchart, which shows the flow of control through an algorithm, allowing a reader to determine what operations will be performed, in what order, and under what circumstances, but not what kinds of data will be input to and output from the system, nor where the data will come from and go to, nor where the data will be stored. Also according to Hoffer, George and Valacich there are two defined data flow diagrams, includes context diagram and level-O diagrams. To differentiate, context diagram is a data flow diagram (DFD) of the scope of an organizational system that shows the system boundaries external entities that interact with the system and the major information flows between the entities and the system. On the other hand, level-O diagram is a data flow diagram (DFD) that simply represents a system’s major processes, data flows and data stores at a high level detail.
The data flow diagram has a purpose and it provide the meaning between users and systems developers. And it diagrams are first graphical, eliminating thousands of words; second is logical representations, modeling WHAT a system does, rather than physical models showing HOW it does it; third is hierarchical, showing systems at any level of detail; and allow the user to understand review the process.
There are characteristics examined in evaluating the data flow diagram. First is Remember, also referred to as recognition or recall. Be able to remember or recognize terminologies, definitions, facts, ideas, materials, patterns, sequences, methodologies and principles. Second is to Understand. Will be able to read and understand descriptions, communications, reports, tables, diagrams, directions and regulations. Third is to Apply. Be able to apply the ideas, procedures, methods, formulas, principles, theories and to the related situation that can be apply on the diagram. Fourth is Analyze. To be able to break down information into its constituent parts and recognize the parts’ relationship to one another and how they are organized; understand the data’s from a complex process. The fifth one is to Evaluate. To be able to make judgments regarding the value of proposed ideas, solutions, methodologies, and many more by using the proper standards to estimate accuracy, effectiveness, economic benefits, and many more. The last one is to Create. Be able to identify which data or information from a complex set is appropriate to examine further or from which its supported conclusions can be drawn.
Data flow diagram has the following symbols: Process flow diagrams. It has the following entities, process number, where the activity is happening and its process name. Data flow datagram. It symbolizes the transformation of data, there must be data flowing into/out of the process, process can have several inputs to it or output to it and process with no out becomes a null process. Data store Symbol. Consist of the following entities, data store number and name of data store. The function of data store is to designate the storage of data in a DFD diagram. Rules of Data store-First rule is that the data flow diagram data store do not by level but they may reappear incase needed and secondly that the symbol and the numbering remain the same. Data flow symbol. Data flow symbol may appear in different shape and they signify the movement of data. They do not signify the movement of people, goods. Doubles an arrow signifies that activities occur at the same time which is wrong and Data flow in is never equal to data flow out. Extended entity symbol. Extended entity is sources and destination of data. This means that source is the origin and destination is the sink of data.

In connection with our previous assignment, we were asked about the characteristics does we, as analysts, examine when evaluating Data Flow Diagram quality. But before anything else, I would like to discuss first what is a data flow diagram, how to create DFD, and different types of DFD.

Purpose

A data flow diagram is a logical model of the flow of data through a system that shows how the system’s boundaries, processes, and data entities are logically related

Strengths, weaknesses, and limitations

A data flow diagram is an excellent tool for summarizing and organizing detailed information about a system’s boundaries, processes, and data entities, providing the analyst with a logical map of the system. Documenting the system’s boundaries by drawing a context diagram helps the analyst, the user, and the responsible managers visualize alternative high-level logical system designs. The elements of a data flow diagram lead directly into physical design, with processes suggesting programs and procedures, data flows suggesting composites, and data stores suggesting data entities, files, and databases.

Creating a data flow diagram is a process driven task. Consequently, it is relatively easy to overlook key data elements and composites. Balancing a data flow diagram verifies the model’s internal consistency, but does not necessarily reveal missing elements. Attempting to balance a significant logical model without appropriate software (such as CASE software) is at best difficult and can be misleading. Beginners and users often confuse data flow diagrams with process flowcharts.

When to use Data Flow Diagram

The DFD is an excellent communication tool for analysts to model processes and functional requirements. One of the primary tools of the structured analysis efforts of the 1970's it was developed and enhanced by the likes of Yourdon, McMenamin, Palmer, Gane and Sarson. It is still considered one of the best modeling techniques for eliciting and representing the processing requirements of a system.

Used effectively, it is a useful and easy to understand modeling tool. It has broad application and usability across most software development projects. It is easily integrated with data modeling, workflow modeling tools, and textual specs. Together with these, it provides analysts and developers with solid models and specs. Alone, however, it has limited usability. It is simple and easy to understand by users and can be easily extended and refined with further specification into a physical version for the design and development teams.

The different versions are Context Diagrams (Level 0), Partitioned Diagrams (single process only -- one level), Functionally decomposed, leveled sets of Data Flow Diagrams.

Principle for Creating Data Flow Diagrams

Therefore, the principle for creating a DFD is that one system may be disintegrated into subsystems, which in turn can be disintegrated into subsystems at a much lower level, and so on and so forth. Every subsystem in a DFD represents a process. In this process or activity the input data is processed. Processes cannot be decomposed after reaching a certain lower level. Each process in a DFD characterises an entire system. In a DFD system, data is introduced into the system from the external environment. Once entered the data flows between processes. And then the processed data is produced as an output or a result.

Create a Data Flow Diagram

Data flow diagrams can be used to provide a clear representation of any business function. The technique starts with an overall picture of the business and continues by analyzing each of the functional areas of interest. This analysis can be carried out to precisely the level of detail required. The technique exploits a method called top-down expansion to conduct the analysis in a targeted way.