The Mindjet Labs

Hands-on MindManager
Welcome to The Mindjet Labs Sign in | Join | Help
in Search

The Organizational Irritant

MindManager in Software Development - Creating Tables From Topics - Part 1

One of the things I've done with MindManager is write software requirements as Use Case behavior descriptions.  Since I wanted to generate another post about creating Map document Notes tables from Topics, it makes some sense to write a Use Case describing what this MindManager MakeTable macro should do.

This is an example of step one in a three part software development formula - first understand what it is the software should do, then make a solution work, and then make it work better.

As I got started, I realized the Use Case would make more sense in context.  So I adopted table generation as a sample software development problem.  The first installment, demonstrating the use of MindManager in creating use cases, is in the attached zip file, together with background information about requirements capture with Use Cases.  The same content is found in two formats - compiled HTML Help and as a Word document.  The .compiled HTML Help file contains a Use Case Map Template, this template is also posted in the Downloads section of this site.

Here's an excerpt from the attached sample:

This material is an example of the use of MindManager in software development. The subject at hand is the creation of tables within MindManager Topic Notes in the context of an interactive user session.

As a sample problem, table generation is complex enough to warrant a solution, small enough to easily understand, yet big enough that work in the areas of Requirements, Architecture, Design, Test, Implementation and Delivery need not be overly contrived. The first part of the story covers table creation requirements through a Use Case and some Policy and Practice statements. Subsequent parts will deal with other development activities.

There is something appealing about using the MindManager product to develop and document an extension behavior for the product. If nothing else, we have a clearly defined application domain for the effort.

An unstated assumption runs throughout this material, we'll mention it here and then leave it be. There is a big difference between performing software development and managing software development. This material is not meant to endorse a single development method or process. If a waterfall process, or a spiral process, or an iterative method, or another variation on the agile development theme floats your boat, go for it. My view is that good ideas (and good people) breed other good ideas (and grow more good people) as long as management doesn't go out of its way to shoot itself in the foot. The material presented here, using the sample problem as a basis of discussion, are things I regard as good ideas in software development. However, like any other tool or technique it is possible to use these things incorrectly. "By their works shall ye know them" says the Bible, and this applies to techniques, people, teams, technologies and organizations as well.

In the end, software development is about how people can use their time, talent and the available technology to produce something useful, possibly valuable and perhaps even beautiful. If the ride is also exhilarating, fun and satisfying, then you are fortunate as well as gifted. But I also believe that neckties are commonly used in corporate culture to hide the marks left by sphincters, so what do I know?

Assuming I can maintain the momentum, I plan on expanding this sample with additional content.  Where I see the opportunity, I'll point out how MindManager supports software development activity.

In fact, I'll do that now.  The compiled HTML Help file in the attached zip file was created with a modified version of the most excellent HTML Help Builder.  I brazenly steal the map template in that download, including it in the sample content attached to this post.  I made several modifications to the 1.0.7 version of the HTML Help Builder - one to style the Topic Hyperlinks in box with a pale yellow background, a second to omit hidden Map Topics from the generated HTML output, and a third to remove  the '*' character from subheadings in the help pages.  I plan to forward these changes to MichaelS for possible inclusion in some future HTML Help Builder revision at his discretion.

Without MindManager, I wouldn't have bothered to create the HTML Help form of the MakeTable sample.  By using a MindManager Map to create, organize and refine the content,  it is straightforward to publish in several formats - Word, web and HTML Help - repurposing the content for different uses.

Published Sunday, March 04, 2007 10:05 PM by dethomas
Attachment(s): TableCreation_Part1.zip

Comments

 

russellnorlund said:

Would it be fairly straightforward to show traceability from the use cases to other requirement categories e.g. features, business rules, glossary terms etc
April 30, 2007 7:18 AM
 

dethomas said:

This is an interesting question.  Traceability is one of those things with a couple of simple cases, and a number of more complex corner cases.  

The short answer is that the degree of straightforwardness declines as the size and kind of linkage grows.  But yes, a straightforward approach can yield good results, within reason.

In the simplest case, we could place a text marker on a Use Case map topic.  The text marker names the business rule, glossary term, whatever data items it is that we wish to use to organize the map topics.  In my experience, this seems to work best with a small number of text markers, say 5 groups of 5 markers each.  As ana alternative, a hyperlinks could be used on Map Topics, or in Topic Notes, to reference some external data through a file: or http: URL.

But this text marker/hyperlink approach, while useful, breaks down if we try to scale it up to handle larger numbers, say 10's or 100's of associations or connections in a given Map document.  The number of connections becomes difficult to navigate and maintain manually.

For example, I'd expect a given business rule to spawn a number of requirements, perhaps spanning several related features in a software system. The requirements for those features could be captured by a number of use case or specification documents.  To be useful in the large, I think we would want to handle a number of related-but-different cases.

Off the cuff, we have a many-to-many situation.  One business rule might influence several use case behavior descriptions and several imperative system requirements.  In a similar sense, a given use case scenario (or supplemental requirement in a use case) might be constrained or directed by several business rules.

My inclination would be to capture both sides, business rules/features/drivers on one hand and use case/system requirements on the other, and maintain traceability though a third kind of data structure, a sort of associational table that has an entry for each association between a requirement and a driver.  If both sides of the association are available programatically, say though an object model, it would be relatively straightforward to write MindManager Add-in code that supported the user in maintaining traceability.  

One variation of this approach assumes both sides of the association, the requirements and the business rules, are captured in MindManager maps.  However, given an appropriate access method, say an object model or XML markup fragments, just the associations that compose the traceability data structure would be in a MindMap.  The requirements on one hand and the drivers on the other could be carried by some external system or data store.

April 30, 2007 8:36 AM
Anonymous comments are disabled

About dethomas

So who is this dethomas guy anyway? Here's a capsule bullet point summary:
  • Midwestern white boy, ex-busboy, stock-clerk, grinder, welder and English major, now laboring lo these many years in the fields of awkward stone that characterize software development.
  • 20+ years of software development experience - CPM/Apple/Unix/DOS during the Reagan years, embedded systems before the term was common, Windows development since the first Clinton administration.
  • Mechanical engineering undergrad degree, showing that early success in thermodynamics is not necessarily a good thing. But the Apollo workstations running UNIX were cool.
  • Engineering master's degree with a control systems emphasis, demonstrating that publishing in IEEE Transactions is cool, but not necessarily a good thing.
  • Employed by an industrial electronics company as a principal engineer. Distinguished by several innovation awards, several software patents, and for once having used the word "Byzantine" in a requirements specification.
  • Learned FORTRAN on punch cards, learned Pascal, BASIC and APL to do numerical analysis in several fields of engineering, learned assembly, C, C++ and Java to write software for several embedded systems, custom applications and shrink-wrapped software products.
  • Has considerable exposure to a variety of technologies, including networking, databases, graphics libraries, linear programming, compilers, non-linear control systems, real-time operating systems, fuzzy logic, neural networks, UML, .Net, XML, OPC, WSI, WSDL and WWF. (On that last one, WWF, dethomas is convinced he did time in high school with a guy who went on to success in the Mexican pro wrestling circuit under the name "el Queso Grande.")
  • Wide exposure to Microsoft Windows products and operating system editions as both user and developer, relative indifference to web technology and the dot com boom until the dust settled.
  • Has a cable modem, but no cable TV service. Which is a philosophical statement of sorts. Television is bad for you, the Internet is not. Or at least not yet.