There is thought-provoking article in the September/October 2011 edition of IEE Software by Robert L. Glass and Iris Vessey on the above topic.Â In short, the authors believe that the software engineering fields "desperately" (their word) need:
- a taxonomy of application domains
- a taxonomy of solution approaches
- a mapping between the two
OKÂ - a quick refresher - what's a taxonomy? Basically, a classification of members of a group arranged in a hierarchical structure.Â SoÂ one taxonomy of application domains might classify applications into embedded systems, scientific applications, business applications, etc.Â A taxonomy of solution approaches might classify solutions by SDLC (e.g. agile, waterfall). code architecture (e.g. object-oriented or not), data management (flat file, tables, etc).Â The goal of the mapping would be to associate "best" (or maybe just "useful") solution approaches for particular application domains. This all seems like good and relatively straightforward, if slightly controversial, stuff.Â Except it turns out that the authors have been struggling for some time with the very first bullet point: a taxonomy of application domains.Â Or perhaps more pertinently, a taxonomy that is generally acceptable or applicable. Now from an academic viewpoint, I can see that a universal approach is desirable but it occurred to me that this line of thinking can be immediately beneficial in individual software development organizations.Â In the absence of globally applicable taxonomies and mappings, what are your organizations taxonomies and mappings? Think of theÂ taxonomies-mappings packageÂ as a blue print for the best way to start each new development project.Â A sort of guide and boundary definition for the development team.Â I suggest that within the border of a simple organization, however, complex, this could be both achievable and useful.