| "Documentation is an inherent part of the
| |
| | documentation as an inherent part of the
|
| design process." - Bryce's Law
| |
| | design process.
|
| INTRODUCTION
| |
| | Today, documentation of any kind is
|
| I recently overheard a Business Analyst
| |
| | considered a taboo (particularly among
|
| say there was more to systems
| |
| | the Agile Methodology people). Small
|
| architecture than drawing boxes and
| |
| | wonder the IT Industry is experiencing
|
| arrows on a piece of paper. This may be
| |
| | the same type of problems today that we
|
| true to a degree, but the ultimate
| |
| | experienced 35 years ago in terms of
|
| deliverable of any engineering
| |
| | managing design complexity.
|
| architectural practice is a set of
| |
| | BLUEPRINTING
|
| drawings from which to build a product.
| |
| | It is a myth that one type of diagramming
|
| Architects and engineers do not spend all
| |
| | technique can be used for all development
|
| of their time drawing diagrams; for
| |
| | work. This would be like suggesting to
|
| example, they have to specify
| |
| | use a wiring diagram to represent a floor
|
| requirements and analyze such things as
| |
| | plan. Different needs, different
|
| the stress of components to determine the
| |
| | graphics, different purposes. There are
|
| suitability of materials for use in
| |
| | actually four types of graphics to be
|
| design. But aside from this, the end
| |
| | used to the different levels of system
|
| result of engineering or architecture,
| |
| | design. This implies a blueprinting
|
| their deliverable, is a set of drawings,
| |
| | approach with various levels of
|
| be it a blueprint, a floor plan, wiring
| |
| | abstraction, from general to specific.
|
| diagram, plumbing, or a set of
| |
| | As we have discussed in the past, the
|
| flowcharts.
| |
| | "PRIDE"-Information Systems Engineering
|
| Such drawings basically consist of boxes
| |
| | Methodology (ISEM) looks at a system as a
|
| and arrows. Boxes (be it squares,
| |
| | product that can be engineered and
|
| rectangles, polygons, circles, etc.)
| |
| | manufactured like any other product and,
|
| represent tangible objects and lines
| |
| | as such, defines four levels of detail in
|
| represent relationships between such
| |
| | a system's hierarchy:
|
| objects. Flowcharts are similar; here,
| |
| | LEVEL 1 SYSTEM
|
| boxes represent specific types of
| |
| | LEVEL 2 SUB-SYSTEMS (Business Processes)
|
| processes or decisions or objects such as
| |
| | LEVEL 3 PROCEDURES (Administrative and
|
| inputs/outputs/files, and lines represent
| |
| | Computer)
|
| dependencies between them (comes from
| |
| | LEVEL 4 PROGRAMS (for Computer
|
| goes to).
| |
| | Procedures) OPERATIONS (for
|
| Although drawings typically consist of
| |
| | Administrative Procedures)
|
| geometric shapes, it is not uncommon to
| |
| | Four different levels, four different
|
| include tables or indices to represent
| |
| | graphics used:
|
| decisions or to provide a
| |
| | LEVEL 1 SYSTEM CONCEPT DIAGRAM -
|
| cross-reference. Nonetheless, boxes and
| |
| | represents a freeform architectural
|
| lines represent the principal means to
| |
| | rendering of the overall system.
|
| visualize and communicate a design
| |
| | LEVEL 2 SYSTEM FLOWCHART - defines the
|
| regardless of the structure to be built,
| |
| | SUB-SYSTEMS of the System.
|
| and have been used since time immemorial.
| |
| | LEVEL 3 SUB-SYSTEM FLOWCHART - defines
|
| In addition to diagramming techniques,
| |
| | the PROCEDURES in a Sub-System (aka
|
| engineers and architects have found it
| |
| | "Process Diagram").
|
| useful to develop models and prototypes
| |
| | LEVEL 4
|
| to evaluate the overall physical aspects
| |
| | COMPUTER PROCEDURE FLOWCHART - defines
|
| of their design. These are useful but
| |
| | the PROGRAMS in a Computer Procedure.
|
| let us not forget they are all ultimately
| |
| | Each level provides the specifications
|
| based on a design of some kind (boxes and
| |
| | for the next (this is also known as
|
| lines). From the models and prototypes,
| |
| | "stepwise refinement"). With the
|
| designs can be adjusted as required.
| |
| | exception of the System Concept Diagram,
|
| I guess what I'm driving at is that
| |
| | all of the flowcharts make use of ANSI
|
| despite all of this peripheral activity,
| |
| | standard symbols. As to the internal
|
| and to refute my Business Analyst friend,
| |
| | processing logic of a program, since
|
| the principal thrust of the engineer or
| |
| | there are many ways to skin a cat, the
|
| architect is to produce and maintain a
| |
| | software structure diagram du jour is
|
| reliable set of drawings. It all comes
| |
| | used, hopefully a standard one. However,
|
| down to boxes and lines. Interestingly,
| |
| | a graphic may not be necessary to express
|
| today's analysts and programmers think
| |
| | the processing logic of a program.
|
| drawings are "old-hat" or passé. I
| |
| | Instead, specifications may be
|
| don't care whether you draw it with
| |
| | interpreted by a program generator of
|
| pencil and paper or by computer,
| |
| | some kind. Its a "fielder's choice."
|
| documentation is an inherent part of the
| |
| | CONCLUSION
|
| design process. Failure to recognize
| |
| | Until such time as we can master the
|
| this is to deny reality.
| |
| | Vulcan "mind meld," whereby we can
|
| In terms of the Information Systems
| |
| | transfer knowledge telepathically, there
|
| industry, flowcharts have been used for
| |
| | will always be a need for documentation.
|
| years, well before the introduction of
| |
| | Its an inherent part of the design
|
| the commercial computer in business.
| |
| | process and the principal deliverable
|
| Originally they included process
| |
| | produced by engineers and architects.
|
| diagrams; later they were used by
| |
| | Don't deny it, accept it.
|
| programmers as a convenient means to
| |
| | I am definitely not one for excessive
|
| document program logic. Such flowcharts
| |
| | documentation thereby becoming a
|
| typically made use of ANSI standard
| |
| | burdensome task. Instead, documentation
|
| flowcharting symbols. But as the
| |
| | should be a natural byproduct of the
|
| Structured Programming movement
| |
| | design process. Just as blueprinting is
|
| flourished in the late 1970's, ANSI
| |
| | an inherent part of the design process to
|
| symbols were considered archaic, and many
| |
| | architects and engineers, so should
|
| new types of diagramming techniques
| |
| | flowcharting be to system developers.
|
| emerged, including Bubble Diagrams, Data
| |
| | And you shouldn't have to be a rocket
|
| Structure Diagrams, E/R Diagrams, HIPO,
| |
| | scientist to draw a flowchart, keep it
|
| VTOC, etc. (anybody remember
| |
| | simple and try to use standard techniques
|
| Nassi-Schneiderman Charts?). I could
| |
| | for consistency instead of reinventing
|
| argue the pros and cons of the various
| |
| | graphics every five minutes. As for me,
|
| techniques but that is not the point.
| |
| | I have no problem with ANSI standards; it
|
| What is important is that all of these
| |
| | works.
|
| diagramming techniques acknowledged
| |
| |
|
