, , , , , , , , , ,

Flowcharts, Data Flow Diagrams, Swim Lane diagrams, Use Cases and other constructs have been used to reflect what a Business or Systems Analyst thinks the client is describing when they talk about Business Process and the use of information in the conduct of their business.

These diagrams have structure, syntax, and rules that have been described through the work of authors, vendors, and users throughout their popular years and are still being applied today; however my concern is that these techniques and their principles are being lost in the more pervasive information about AGILE, Iterative, and other quick fixes to some pretty old problems.

Other related types of drawings or ordered lists that I have seen used are: NASSI-SCHNEIDERMANN Diagrams, Functional Decomposition outlines, Warnier-Orr diagramming, Jackson Data Diagrams.  Although these had value in their day, they were not as pervasive as some of the others process and program design diagrams that were mentioned in the first paragraph here.

So, What’s the POINT?  I think that software needs to be an engineered product and these techniques and structured diagramming tools are, to me, a lot like Blue Prints for construction of buildings with electrical, plumbing, HVAC, Safety and Security viewpoints, each of which have similarities in the construction of Software.  And yet, the more recent Software design techniques are focused on RAPID, Iterative, AGILE development that implies to me that current solution development efforts want to skip over those planning, analysis, and design activities while they still expect usable results.

For one, I don’t think this is a healthy evolution for our automated business solutions future.

If you are interested in seeing sample diagrams or starting a thread of conversation about these topics, please send me an email at whendoyoustoplooking@gmail.com – thanx, bgbg