Modeling for Money!

One of the basic principles of Software Engineering is the creation of visual models to demonstrate the project team’s understanding of the discoveries we are collecting from the users who are driving our discussions.

The type of drawings were proscribed by several authors of the time but regardless of the style of the drawing, they all have a relatively consistent set of focal points:

  1. Process Definition where a step by step sequence of events was pictured with indications of the data or other resources being used for each process step.  The fundamental assumption was that each process step DID something to input to create its output.  For example: Calculate total line item cost, Apply local and country tax amounts, Add line item cost and taxes for line item total.
  2. Data Definition where a data subject or entity would describe all the details of each data element that was essential for that entry or entity to be “Complete”.  An entity would represent data that was necessary for the functional and operational aspects of the solution without unnecessary redundancy.  Examples are: Product Catalog, Customer Info, Order Details.
  3. State Transition diagrams are used to reflect what “State” each data entity is in when a process step starts and completes.  These “State Conditions” are very useful for managing the evolution of each data entity and preventing some illogical transitions from occurring.  Some examples: New Entry, Priced, Counted, Shipped.
  4. Event Diagrams are supplemental to the Process Diagrams and can initiate process steps depending on occurrences that happen outside of the planned application.  Examples: Customer Submits Order from Web Site, Customer Credit Card fails Authentication.

The Software Engineering Handbook

Information Technology (IT) has been moving towards a “Popcorn Culture” for many years where our Practitioners are regularly looking for a quick POP of a little progress in technology.  When I was growing up in the world of computer programming, we were taught that this work took planning, design, testing, and re-work before a product was “ready for prime time” and then be useful as a Production Program that is reliable, sustainable, and accurate.

I don’t expect that everyone in IT will read my stuff here and turn their lives around to re-acquaint themselves with the principles and techniques of Software Engineering (as I knew it) for designing business solutions; however, I am interested in recording what I believe are fundamentally sound practices for determining what to build and that have value to functioning organizations in today’s and tomorrow’s worlds.

Please let me know what you think about these writings and, if you think they are valuable, please subscribe to this feed, and leave me some comments, so you can get my latest opinions as they are published.

Thank you, Bill Gutches

PS: If you are interested in getting more info on this and other related topics, please send me an email to whendoyoustoplooking@gmail.com and I will gladly respond.