Category: Information Technology

Data Flow Diagrams Alone?

 

Data Flow Diagrams Alone?

That’s like cake without the ice cream, it’s just not right!


So the question has been asked “What are the weaknesses of using data flow diagrams as a modeling tool?” and my response to that question is an avalanche of probing questions.

  • What constitutes a weakness?
  • From what perspective are we viewing the item in question?
  • Is that item really intended to be used in the manner we are trying to use it?
  • Is the item’s intended use even applicable to what we are doing at the moment?

I find questions of weakness extremely interesting because the definition of weakness is always tied to the perspective of the one pointing out the supposed weaknesses. In addition, the perspective of that individual is always affected by whether or not they actually understand the intended use of the item they are calling weak. Even if the individual has a full understanding of the item and its use, have they actually stopped to consider whether or not the item and its associated use are even appropriate for the situation in which they are trying to use it?

Most of the time when I find myself defining something as weak it is because I either, do not understand fully its intended use, I am trying to use it for an unintended use, or I have not stopped to consider if I am even using the right tool for the job at hand. Rarely do we find a truly multipurpose tool in our belt, we usually need a toolbox to get the job done. We get the job done by using each tool as it was intended.

This brings us to data flow diagrams and their intended use. Simply put they are designed to allow us to visually represent all of the data inputs and data outputs of the various processes within our systems and at various levels of granularity (processes, sub-processes, etc…). Thats it, that’s all they are designed to do and when looking at them from their intended use (that perspective) I really cannot identify any weaknesses nor any real need for a replacement.

Now if I looked at them as though they were the only diagrams I was allowed to create for my new systems, from a perspective that they were the one defining system document, can I find some weaknesses? You bet!  They are as follows.

DFDs do not provide:

  • implementation details
  • distinction between manual or automated processes
  • chronological order of process execution
  • timing of processes
  • flow of control
  • specifics linking the inputs to the outputs of the processes
  • non-functional requirements
  • user interface requirements
  • business rules
  • data relationships and the business constraints on that data

In programming we have a mantra which every good developer instinctively follows “Each method must do one thing and do that one thing well and thats all it should do.” The beauty of this statement is that it applies to pretty much everything in life, including analysis and design.

Data flow diagrams do the job of identifying the data input and data outputs of our system’s processes and they do it well, as they should. In that light each of the “weaknesses” identified above has its own modeling/diagramming methodology which effectively captures and records the information needed within its context.

In systems design we cannot rely on a single modeling approach to capture everything a system is or will be. This is because our systems are complex, layered, and partitioned into various complex pieces each of which belong to different disciplines guided by different methodologies.

What makes things difficult is the fact that all the pieces of our systems overlap and intertwine which, of course, causes the modeling methodologies to mix. As analysts I have found we attempt to force a single methodology to be the one glove fits all solution for modeling these extremely complex systems. This simply will not do.

I do not design my code utilizing the same modeling paradigms as a data modeler designs a database nor does the UX designer design her user interfaces using the same modeling paradigms as I. But through our joint efforts and the combination of our modeling methodologies, we build complex, amazing systems.

Sources/References

1. Kendall, K.E. (2011). Systems Analysis and Design.
Pearson Education, Inc., publishing as Prentice Hall

Data Flow Diagrams: Logical & Physical Working Together

Data Flow Diagrams: Logical & Physical Working Together


Data flow diagrams can be quite useful when utilized within the systems development lifecycle because they assist the analyst in gaining comprehensive views of a system’s processes, inputs, outputs, data stores, and external entities at varying elevations.

Data flow diagrams are put together through a top-down method starting from a bird’s-eye-view, then gradually decreasing the altitude, thus narrowing our view of the system. By narrowing our view we are in effect slowly moving from a macro view of the system to an ever increasing micro view of the system’s process and subprocesses. It is through this process that an analyst can eventually document and describe a system down to its most primitive processes, creating a very specific set of instructions which can eventually be translated into a working system.

As with most every man-made creation it is paramount we start at a logical level, a level at which we can focus on the design of our creation rather than the actual physical manifestation. Once our creation has been completely conceptualized we can then focus on how we intend to physically create it.

For this reason data flow diagrams are separated into two types, the logical or conceptual and the physical.

The Logical Diagram

As hinted at above, the logical data flow diagram is kept at what is called the conceptual level or a level at which we are only considering the concepts making up our system, not its physical embodiment. By remaining at a conceptual level we are better able to focus on entities, processes, data, and data stores in an attempt to identify them all and verify they are documented as accurately as possible.

The reason this is important is that once the physical aspect of something is introduced we tend to give it more focus and attention. This is because we are physical beings and we like dealing with what is real; we can see it, touch it, and work with it with our bare hands. At the moment the physical is introduced we are no longer concerned with the design, or not as much as we should be.

While are are in the conceptual space our diagrams will focus more on the following important aspects of design:

  • The business and how it operates
  • The business events
  • The data involved in those events
  • The data created by those events


The conceptual space also provides us with specific advantages:

  • Better communication with users
  • A more stable system
  • Better business understanding
  • Design flexibility
  • More effective maintenance
  • Elimination of redundancies
  • Easier creation of the physical model due to our understanding of the logical model to start

The Physical Diagram

Once we have great grasp on the concept of a new system we are better prepared to decide on its physical implementation. With this knowledge we can create what is called the physical data flow diagram.

In this diagram our focus changes from the conceptual to the actual way in which we will develop the system. With this change in focus we begin to consider the items we will need such as the hardware, software, files, and resources.

When at the physical level we need to focus on the following items:

  • How the system will be implemented
  • Hardware, software, files, and people involved in the system
  • Business triggers which spawn activities
  • Actual data inputs required by those activities
  • Actual data outputs created by those activities
  • Data repositories to house said data
  • Data structures to store structured data


The physical level also provides us with several advantages:

  • Clarified processes base on partitions such as manual vs. automated
  • Processes are described in more detail than in logical for ease of development
  • Processes are sequenced
  • Temporary data stores are identified
  • Data stores actually named and technologies selected
  • Process controls are identified
  • CRUD operations identified

Order of Operation

These two types of data flow diagrams are extremely useful alone or in combination with one another. This efficacy is greatly enhanced when they are utilized within a very specific sequence as outlined below.

  • Logical data flow diagram of current system (one to be replaced)
    • Provides a clear understanding of the current system
    • Provides a good starting point for replacement system
  • Logical data flow diagram of proposed system
  • Physical data flow diagram for system implementation


In the above order, each data flow diagram helps to enhance each subsequent one. When used together the resulting system will provide a much better solution to the business needs.

Sources/References

1. Kendall, K.E. (2011). Systems Analysis and Design.
 Pearson Education, Inc., publishing as Prentice Hall

Mandatory Skills of a JAD Facilitator

Mandatory Skills of a JAD Facilitator

As with anyone leading a group of people, whether it be small, large, or monolithic, it is extremely important that they posses a very specific skill set. This skill set needs to be optimized for guiding, directing, and maintaining a group’s natural ebb and flow as it works together to accomplish its goals.
JAD Facilitators have a large responsibility and a great impact on the success of a JAD workshop. It is their responsibility to make sure that the workshop sticks to the schedule and agenda and that those involved are comfortable and confident in the proceedings. In order to accomplish this, they must be leaders.
Although the leader’s skilllist can be rather large and varied based on the industry, culture, or company there are some very important skills which are a must no matter what.

Lead by Example

All facilitators must provide an example to the participants. She should exemplify the values, disposition, and demeanorwhich is necessary to effectively accomplish the workshop goals.

Confidence

Facilitators need to exude confidence in their mission in order to help participants acquire and maintain a proper level of confidence throughout the workshop. Confidence in the mission is extremely important, as it is the key to whether or not a workshop will be successful.

Organized

Due to the fact that all workshops are on a string schedule and must follow a tight agenda, the facilitator needs to be well organized and posses the ability to keep the workshop participants on schedule and within the agenda at all times.

Effective Communication

Because the facilitator is the focal point of the workshop and the gateway for all participants, it is mandatory that the facilitator have the ability to not only communicate but communicate at such a level that no matter the disposition of the individual with whom they are communicating, it is done well.

Mediator

No matter how well planned and executed a workshop may be, humans are involved. When humans are involved there will always be conflicts and usually more than just a few. It is extremely important that a facilitator posses the ability to not only spot the beginnings of a conflict, but also be able to jump right in and help to control it. Without an outside source to help the individuals involved in the conflict come to a peaceful resolution, the majority of these conflicts end up in misunderstanding, hurt feelings, or potential physical violence. 

Understanding Population Sampling

 

Sampling Understood

Sampling theory states that by utilizing a systematic approach to selecting elements of a specific population one can, within a reasonable margin of error, collect data that pertains to the population as a whole.vThrough the use of sampling we successfully bypass the need to examine the entire population in question. Within the sampling theory two forms of sampling have been identified as follows:

Random Sampling (Probability Sampling)

This form of sampling provides that every element in a population has at least some chance of being selected as part of the sample and that this probability can be accurately calculated using some mathematical formula (Sampling, n.d.).

Nonrandom Sampling (Non-probability Sampling)
 This form of sampling stipulates that there will be elements within the population which will not be selected at all, in other words there is no way to accurately determine the probability that an element will be selected from the population for the sampling (Sampling, n.d.). The majority of the time this is due to the fact that the sampling is being done based on assumptions or bias. By introducing a personal bias or by making assumptions as to what should be in the sample population, one has removed the ability to get results which are common across the entire population being sampled.

 

In Contest

Depending on your point of view there are benefits to either form of sampling, if there were not we would most likely not have 2 types. But when it comes to data and trying to find out what is really going on throughout a population, making the sample as random as possible is in my opinion the better path. This is due to the fact that spreading the research across the population in a random manner, utilizing a probability equation to decide on the sample population, you are more likely to get data which truly spans all types of elements which exist throughout the population.
 
In contrast when utilizing sampling which is not random you are immediately introducing assumptions and biases into the data which affects, in my opinion, the validity of the data itself as well as the statistical outcomes calculated from that data. I raise this as an issue because this question of validity is a real source of pain to everyone utilizing the statistics gatheredfrom that data to identify truths within the population.
Case-in-point, every automobile manufacturer which sells trucksin this country, states in their commercials that they are the consumer’s number one pick. But how can this be, number one is number one and there can only be one number one. This is because they do not use random samples, they use bias samples which provides data that supports a conclusion they have already made. Instead of a true desire to understand the population they are simply trying to make what they believe the truth.

The Good Questionnaire

The Good Questionnaire

Questionnaires or surveys as they are more commonly referred to, can be a great method for fact finding and information gathering. Questionnaires are also versatile and dynamic in nature. Versatile in that they can be used no matter the industry, company, language, or culture a potential project may arise, due to the fact that everyone has had exposure to them from an early age. They are dynamic because questionnaires can have any number of questions and those questions can be created in ways that gather opinions, facts, statistical data, etc..
For an effective questionnaire to be formulated its construction must contain the following elements:

Properly Formulated Questions

Depending on the data requirements for your analysis you may choose to formulate your questions in one of two ways, or perhaps utilize combinations of both within your questionnaire.
Open-ended: commonly used to gather detailed information, opinions, or suggestions pertaining to the questionnaire’s topic(s). These questions allow the users to expound on their answer and usually require a sentence or more to fully answer. It is because of these text answer that these forms of questions are hard to parse and require quite a bit of time to read through and analyze to properly obtain useful data.
Closed: commonly used to gather data which can be statistically analyzed due to the fact that the answers to the questions are either yes/no or are limited to a very specific set of possibilities such as multiple choice.

Word Choice and Terminology

No matter where communication takes place there is one overarching requirement to making that communication effective and that is making sure the word choice and terminology of that communication matches that of the target audience. In order for a questionnaire to be effective you must take the time to observe the target audience in order to become familiar with how they communicate and utilize this when creating questionnaires.

Proper Scales

Scaling questions allow you to add dimension to a question by applying units of value to the questions possible answers. When utilizing scales you must validate that those scales are going to provide you with the accurate and reliable data you are looking for.

Question Order

When constructing your questionnaire it is important to think about the order in which your questions flow throughout the questionnaire. This is due to the fact that the individuals answering those questions can truly be affected by the ordering. Some negative affects can be boredom if questions unimportant to them are first, or question bias if two questions which affect each other are placed next to each other.

Get it done, Joint Application Development

Get it done, Joint Application Development

As with any and all meetings we hold in a corporate environment, they have to be organized and structured in such a way that things get decided and then get done. We have all suffered through meetings where someone who likes to hear themselves talk, spends an hour and a half of our life to accomplish absolutely nothing. Not only did they not accomplish what the meeting was supposedly intended to but by utilizing an hour of my life have rendered me absolutely useless as well, sometimes for as much as an hour after their meeting when I am trying to reconstitute my dehydrated brain.

Being that I detest wasting my own time and that of others, any and all joint application development (hereafter known as JAD) workshops must hereby adhere to the following guideline in order to obtain managerial approval.

Our JAD Workshop Guideline

Step 1. Project Fit

Above all else you must determine if your project is JAD worthy. Does it possess the attributes required in order to effectively benefit from this form of requirements gathering. In order to tell I have listed below several key question you must ask yourself.

  • Does this project require enhanced user participation?
  • Does the project schedule or budget require an expedited fact finding method?
  • Does the project schedule or budget require expedited development
  • Is this project relatively small?
  • Is the system being discussed focussed and narrow in scope (both breadth and depth)?


If you were able to answer yes to at least 3 or more of these questions your project is most likely a good fit for a JAD workshop. You may continue to step 2.

Step 2. Length of Workshop and Agenda

JAD workshops usually take anywhere from 1 day to as long as it takes to get the design solidified. Due to this, it is your responsibility to come up with a solid workshop schedule and length. A length must be identified and set in stone before approaching any of your intended participants as they will all need to know the timeframe they will need to allot in their busy schedules.

You must also create an agenda which is to be strictly followed and managed in order to make sure that the time allotted for this workshop is utilized as efficiently and effectively as possible. No one should leave the workshop feeling as though their time has been wasted as this will affect their overall confidence and support of the system once development has begun, as well as their eventual acceptance of the system once released.

Step 3. Identify Your Domain Experts and Sponsors

Before any work can commence a decision must be made as to what levels within the organization are to be included in the workshop. Once you have identified the levels you then need to locate one or more individuals from each level who have the availability to participate, interest in the system, and in depth knowledge of exactly what the system needs to do for them, their peers, and their departments.

It is also critical that you obtain an executive sponsor for your workshop. This must be someone with enough influence and power to make final decisions and create strategies which will stand the test of time (once the workshop has concluded).

Typical Actors Involved

  • Domain Expert Users – those with specific knowledge pertaining to the domain in which the system will run or control
  • IT Specialists – Analyst, Architect (note takers)
  • Executive Sponsor – High enough in the organization to make decisions and create strategies which will stand after the workshop
  • Session Leader – non-bias individual with excellent communication skills
  • Observers – IT members assigned to the team such as developers (silent note takers)

Step 4. Finding a Xen Local

Once the JAD workshop, its schedule, and agenda have been approved it is time to identify a location which will be conducive to group work and collaboration. The location must also be located off the corporate campus in order to minimize potential interruptions. By having the workshop off campus it also reduces the participants constant focus on their daily responsibilities and duties and the paperwork piling up on their desks as they are assisting in your workshop.

Step 5. “Let them eat cake” or Keep them Fed

When a meeting lasts only a few hours its participants begin to feel burdened with its content. Adding a little food to those meetings pacifies and creates an atmosphere of reward for the efforts provided by the participants. Plus we all know low blood sugar leads to less brain activity and poor moods which are a detriment to everything you are trying to accomplish with your workshop.

JAD sessions tend to last all day and may continue for several days in a row. It is extremely important that you plan for, care for, and provide for your participants as best you can within reason (you can’t break the budget on twinkies).

Conclusion

This guideline is provided as a service to you by those experienced in joint application development. If you will hold fast to this guideline while developing your JAD workshop you will have a higher likelihood for the successful outcome you are looking for.


Sources/References

1. Kendall, K.E. (2011). Systems Analysis and Design.
       Pearson Education, Inc., publishing as Prentice Hall

2. Joint Application Design, (n.d.). In Wikipedia’s online encyclopedia
      Retrieved from http://en.wikipedia.org/wiki/Joint_application_design

3. Domain Expert, (n.d.). In Wikipedia’s online encyclopedia
      Retrieved from http://en.wikipedia.org/wiki/Domain_expert