More Granularity Is the Key to More Productivity

I've waited a decade for someone else to write this article. It may have been done, but I have not seen it.

Despite object-oriented design and software development, software routines as well as part designs, tool designs, proces plans and tests are re-invented over and over again. They are not reused, because there is no effective way to find, sell or share them, and although a part of a design, plan or test may be what is needed, they are only accessible as a whole. Similarly, the labor and materials estimate of a new product cannot benefit from the past.

To this day, many companies still manage products according to drawings, which are nearly always derivatives from 3-D models. The drawings can only be interrogated by humans, so automation is limited. Solid models make it possible to associate labor, process plan elements, tooling, lubricants, other parts and their loads with a face feature, but the association has not occured.

The same is true of software development traditionally managed by functional requirements and technical specifications documents in Word files. They provide insufficient granularity to which to relate individual code elements. Once again, humans are required to bridge the gap. Once the principles involved disappear, all connectivity is lost. Unable to search for code using requirement criteria, it's no wonder there is so little code re-use.

It's long past time to abandon functional requirement documents, drawings and plans as the focus of product managment.

Me

I started programming in 1971 in RPG and later in Fortran, Basic, Pascal, Forth, 6800 Assembler, C and C++ using a variety of methodologies, including waterfall, raptid prototyping, Extreme Programming and Agil.

I was involved in solid modeling during CAM-I and IPAD. I developed the requirements for and managed the development of the first minicomputer-based CAD/CAM File Control System. I later managed the development of a corporate-wide CAD/CAM Database Management System that included a Parts and Task Information System and Global Access Facility, which accessed data from both the File Control System (models) and the Parts and Task Information System. That earned me the position of Process Architect for an Enterprise Integration Project.

The result of that experience was Enterprise Integration and Management. In it I made the case for more granularity in the management of aerospace products. The "features" of some solid modeling systems like Euclid-IS provided the granularity to associate analysis loads, process plans, tooling, tests, etc. with a face or hole of a part as well as provide accurate mass proproperties and spatial relationships within an assembly and assemblies within assemblies. Euclid had an accessible database management system that could be interfaced with robust relational or network data management systems provided the means of creating and manageing four interrelated hierarchies:


The surface features depicted above could just as easily be chunks of software assembling into a program assembling into the totality of software of an enterprise.

Wiloughby Templates and Total Quality Management (TQM) were in then. Later as an IT business analysis and project manager exploring IEEE, ISO, UML, Use Case, Scrum, Agile, PMP, PMI, JAR, JAD and yet-another-methodology that does not improve productivity, I surveyed all the popular requirements capture methods in 2006, and concluded that they all waste time generating lots of text and artifacts to which users must adapt, management does not read, and developers ignore, because they are maintained as files, which are of insufficient granularity to make quick and accurate queries for pertinent information, and difficult to relate. Entire specifications must be read, and entire diagrams must be examined to extract the bits of information pertinent to each participant during definition, design, programming and test. There is no connection between requirements, meta data, programs or tests that does not require human interpretation or intervention. That's when I realized that software development had the same problem as hardware development -- insufficient data management granularity.

In 2008 I worked with MS Team Studio. It is the first commercial tool of which I am aware to define software at the feature level. It is but a step in the right direction.

Concept

The only common denominator of all product types is the requirement -- the desired function. Described at a useful level of granularity, searching and finding a similar function will lead to the desired software, design, analysis, fixture, tool, process or test, providing the relationships among these deliverables and the task (labor) expended to provide the deliverable is maintained. The reverse is equally true.

Functional requirements are largely described as text. No extra work is required to provide an effective keyward set to help people find a past requirement similar to that currently required. The key is to maintain each function as a record in a database such that the entier set of functions can be found and exported as a conventional functional requirements document for those who want it. However, the document is not the control. It is merely a derivative of the database. The database is the control.

Previously I developed a database system that generates model-specific manuals from a generic product manual. The "custom manual" database can be extended with additional layouts into a requirements collection system that includes graphics and meta data. Export the found set as conventional functional requirements or technical specification documents. Additional layouts with software commands and meta data (variable) popups instead of formatting popups can replace error-prone typing as the primary software development method. Want a different language? Add another layout. Export the found set as a text file for compilation, execution and test. Compare each software function with the requirement directly related thereto by way of the relational database to determine if the requirements are in fact satisfied. Want to reuse software? Search for similar requirements to find related code.

I developed a database that generates model-specific manuals from a generic product manual, simply by entering the generic manual as one paragraph or sentence per record and using HTML popups to format the text. Then only the generic manual need be maintained. Each record was associated with one or more model number. Searching for records by model number, and exporting the found set results in an HTML file that is used as-is, or converted by scripts to Word, PDF, RTF or plain text for publication of the model-specific manual.

I put my total resume in the system, so I can easily derive subsets therefrom for specific job requirements (business analyst, project manager, technical writer, developer, designer). It is surprisingly efficient to use. Duplicating records copies a text style. Simply replace the text. A decimal system makes it easy to properly sequence records with a sort.

Managing requirements one feature per record in a database allows them to be related to code elements and tests also created as individual records to close the loop. Larger found sets result in larger feature, software and corresponding test sets. Different configurations are just variations on the search criteria and the resulting found sets. Software is just one subsystem in the larger product managed in the same manner.

When I developed a database to allow a client to derive manuals from a source manual, I was surprised at how easy it is to format the information using HTML popups, and effectively use styles by simply duplicating a record with the format you want, modifying its content and setting its decimal sequence number. Model, option, paragraph sequence and other fields made it easy to insert phrases (links, images, bold, italic, etc.) as parts of sentences and sentences (size, font, etc.) as parts of paragraphs (justification, etc.) -- the normal building block, which are also aggragated from cells and rows into tables. Searching for a model and options results in a found set, that when exported, results in a beautifully formatted derivative HTML file that is easily converted to Word, RTF, PDF, etc.

I extended it to handle multiple source documents to increase the scope of the relationships. After I put my overly large resume in the system as a source document, and derived thirteen resume subsets therefrom, I automated everything practical with scripts. It's made it easy for me to maintain a web site with links to sixty-five content and format derivatives of my resume for download by interested parties.

After studying all the current software development methodologies as of January 2007, I realized that simply adding C, Python, Visual Basic, etc. layouts with software command and meta data popups instead of HTML popups would allow the manual database to be a software writing tool as well as a formated text writing tool that would virtually eliminate typing and its errors.

At Providence Health Plans last month, I was on the first project to use the SCRUM process and the MS Team Studio system to facilitate software development. Although primitive, it was good to see more granular requirements, software and test management being used -- four years after I developed a system that would do it better.

I hope one day I'll have the time to re-write my Enterprise Integration and Management book and incorporate my latest findings, so it is influential as well as sellable.

I have since learned Solidworks and Alibre Design.