Isotope 28

Requitopia alpha now available!

An alpha version of Requitopia is now available! Visit the isotope28 website for more details and the links to the documents and installation files.

Enhanced MSF

Over the past year, we've been working with a company who's using the Microsoft Strategic Framework (MSF) for their development framework. We've easily adapted SEEM to their needs, but thought others might benefit from the enhancements we've provided to the MSF. We've authored a white paper on the topic and posted it as a resource on our web site. Have a look and let us know what you think!
http://www.isotope28.com/Isotope28/Resources.html

The Reverse Detective!

After more than 2 years of effort, and 10+ years of research, we've finally published The Reverse Detective! The first book in the series covers the gathering and modeling of requirements overlayed onto the metaphor of a detective invetigating a case. Included in the book is a case study of an Edgar Alan Poe story, "Murder on the Rue Morgue", and a case study of a tool that will help a detective perform their job. The accompanying CD-ROM contains the complete case study of the Poe story, and 5 or 6 revisions of the model for the detective's case tool. As the new Isotope28 web site comes on line, we will post the complete (final) model for those interested.

If anyone has any comments or questions, or erratta to report, this is a good place to do it!

Modeling with Mind Maps

The complexity and number of artifacts in all but a very simple SEEM model quickly exceed our ability to understand thier relationships to each other. SEEM provides a well-defined model for the relationships between the TYPES of artifacts, which is essentially a class diagram. However, as a project progresses, an object (artifact instance) diagram is very helpful. Furthermore, our attempts to represent the structure of the SEEM model within a directory hierarchy were quickly stymied by the limitations of the file system hierarchical depth in Microsoft Windows. In addition, manual navigation of hierarchies of directories to find specific artifacts becomes very tedious and confusing. This was not an effective technique, and Darwin suggests that another solution should be explored.

Enter the mind maps.

Reading a recent article in "Better Software", Robert Sabourin discussed the use of mind maps for helping with the generation of test cases, and even with software design in general. Mind maps have become an essential tool for developing, understanding, communicating, and maintaining our SEEM models. A brief discussion of the use of the tool, and some of the issues encountered are in order.

To begin, a tool for creating and maintaining the mind maps is essential. I've been using MindJet's Mindmap Manager (http://www.mindjet.com) on both the Mac and the PC. The software is not too expensive, and a free reader is available for those who want to read and navigate the model. There are also free tools available. Robert Sabourin suggests Freemind, which is a Java-based, open source tool. I'm downloading it now for evaluation.

Based on our usage of Mindjet's tool, the advantages of a mind map for a SEEM model are many:
- Displays a catalog of all available artifacts in the model, and many of their relationships to each other.
- Allows the reader to easily navigate and open the artifacts.
- Illustrates the completeness (or incompleteness) of the model.
- Allows the user to tag each artifact, tree or node with a status, priority, or other icon which facilitates the use of the model for prioritization, status, resource assignment, and management.
- Illustrates the dependencies for many of the mapped artifacts.
- Allows restructuring of the underlying filesystem without compromising the structure of the model.

Unfortunately, the relationships between artifacts are not always hierarchical, which is the only type of relationship mind maps can illustrate. For an example of hierarchical relationships, one context diagram begets many use cases, and one use case begets one or more sequence or activity diagrams. Moving forward, the relationships get cumbersome. A set of activity or sequence diagrams map into a set of participant's RC cards, but the relationship is not a one-to-many hierarchy, but a many-to-many relationship. This is not easy to represent in a mind map.

Also problematic are artifacts that represent collections of other artifacts, but outside the normal hierarchical structure. For example, a static relationship (class) diagram is an essential artifact, but where should it be represented in the hierarchy?

Both of these issues are current addressed by placing the common artifacts at the same level of the hiearchy as the root of the tree. While practical, it does nothing to add to the visual representation of the relationships in the model.

Another issue with our mapping technique is the illustration of the different phases of the modeling process. Currently we handle this by setting up each phase as a sub-topic of the main project, then hanging the artifacts for each phase under the associated sub-topic. Again, while practical, it does not show the critical relationship from one phase to the next.

If anyone has suggestions to improve our mapping techniques, please let us know!

Problem Analysis

As with all things, SEEM is about relentlessly applying the Darwin test to all aspects of the methodology. With this in mind, I'm always examining every aspect of the methodology for its effectiveness. Lately I've been thinking about our modeling of the problem domain.

Surely we can all agree that creating a reusable model of the problem solely in the problem domain has its advantages. However, the degree of ceremony that's applied, and the extent to which this model is completed is debatable. To whit: how far do we carry the model of the problem domain?

At issue is the understandability of the problem domain model, and the potential to abstract out any and all useful information. For example, if the problem domain model is too abstract no one will understand it thus rendering it useless. On the other hand, without a problem domain model at all, everyone is quickly swamped with technology details with the potential to ignore the problem entirely. From an understandability point of view, our experience interviewing problem domain experts indicates that it is nearly impossible for them to divorce themselves of the current implementation technology and discuss the problem in the abstract. Thus the input they provide must be filtered, organized and abstracted by the analyst. (In the rare case where an existing technology solution does not exist, this is not a problem!)

So how much of the problem do we model, and at what level of abstraction? Can we quickly jump into the technology domain so the business experts can express themselves in terms they know and love? Or do we first create a model in the solution domain and abstract out the problem domain model ourselves? What is the price we pay as analysts?

Data Modeling

The SEEM methodology does a terrific job of modeling the behaviors of a system, and supplies the associated data to go with thge behaviors. Unfortunately, only the data associated with, or driven by the behavior is included.
There is an entire class of data I'll call "tramp data" that comes along for the ride when defining behavior. For example, if you are interested in modeling a video rental system, the name of the person renting the video is crucial to the model, and provides the primary key. However, the data associated with the person, their address, zip code, etc., does not affect the behavior. Consequently, the SEEM model does not provide a clean method by which this data can be derived from the problem domain.
While much if the data can be inferred from the problem domain independant of the behavior, this appears to break traceability as there is no clear source of the information. The video store is a fairly trivial example. In contrast, there are many applications where the behavior is simplistic, but the data is very complex.
Where the problem domain requires a complex data model, how can we go about deriving the required data model? Any suggestions?

Greetings!

Welcome to the Weblog for ArchSynergy / Isotope28!
Let me begin with an introduction: My name is Tom Bullinger, and I'm the President and founder of ArchSynergy, Ltd. ArchSynergy has been in business about 5 years, and has been striving toward the improvement of software engineering as a discipline. Our most recent activities have centered on refocusing the business on the requirements gathering and modeling of software, and have prompted a few major changes.
The first major change is the adoption of a new company name to help with the refocused direction of the business. Moving forward, ArchSynergy will now be Isotope28.
The focus of Isotope28 is to help our clients figure out the correct requirements for their software projects.
This blog will chronicle our experiences with requirements gathering in various contexts, and provide a discussion forum for all related topics. Stay tuned for more information!