With these properties in place, we can use another automated tool to check on the project's progress whenever we like. I've put together a simple example of such a tool, named FB4CodingProgress, which is shown in Listings 4-6. When this tool is run in the root directory, it produces an HTML file with the report shown in Figure 2.

For each circuit, we get a list of templates (fuses), and if the fuse has been coded (or coded and tested) a note is shown along with the date from the Fusedoc. Any nested directories are indented in the report. At the end of each directory's (circuit's) section, there is a set of totals for the directory showing percentages coded and tested, and a grand total section appears at the bottom of the report. We are able to grab an instant status report for the coding and testing of the project, without even bothering any of the coding staff.

So, finally, on to the last question, "What was done?" We want to answer this question with system documentation. This is typically one of the most overlooked parts of application development, usually because we coders don't put much emphasis on documentation. However, using techniques we've already seen, we can take the pain out of creating documentation for the code that exists in our finished application.

Once again, we're relying on a tool to take the pain out of the process. This time, it's a tool called FusedocMiner, which is somewhat like FB4CodingProgress, but not nearly as specialized. All it does is cruise through a directory tree, pull out all the Fusedocs, and apply an XSL stylesheet to each one. The code is shown in Listing 7. The default XSL stylesheet (Listing 8) produces HTML that, along with the default CSS stylesheet (Listing 9), renders some nice documentation ready for printing, as shown in Figure 3. When printed, each template gets its own page in the documentation, so it makes a nice bound document for delivery to the customer.

Unfortunately, there's not enough space in this article to dissect the XSL stylesheets used in FusedocMiner and FB4CodingProgress. They are both fairly simple examples of XSL, and I hope they'll serve as good starting points if you haven't already explored XSL. Both the XSL stylesheets and the CSS stylesheets are provided so you can modify them to suit your local project management needs.

This article is really just a quick overview of the sorts of things that are possible in terms of project management when a structured and consistent process is used for development. One last time, I'll repeat that, although the examples used in this article are based on Fusedoc, there's no requirement to use Fusebox or the Fusebox Lifecycle Process when using Fusedoc; I just happen to have a lot of Fusebox-based examples lying around. Even if you want to use your own XML-based template documentation standard, all the techniques would remain the same. It's important not to lose the point of the management techniques in the irrelevant fact that the samples use Fusedoc.

With a bit of thought and a few tools, it's possible to have very good project management with minimal tedium and, even more importantly, low impact on team members' time. All the tools I've shown in this article are available for free download at www.GrokFusebox.com, in the Grok's Goodies section. As with all my tools, they're free for use and modification. Use them to feed your own ideas and let me know how you've made them better.