One of the items in our AD111 presentation that got a lot of attention was the
CoCoMo II analysis of existing Notes applications. I'll explain what it is and how to run your own analysis:
CoCoMo stands for
COnstructive
COst
MOdel, first published in 1981 by
Dr. Barry Boehm of the Center for Systems and Software Engineering of the
University of Southern California and later refined in version 2 (you can read all about it
on their website). In a nutshell: If you know how much lines of code you need, how complex the task is and how experienced your developers as a team are, then CoCoMo II can determine how long it will take to develop a software, both in calendar as well as person month. So you will know your staffing requirements and by adding your average hourly cost the total project price. The number your get out of such an CoCoMo II analysis is easy to communicate to business users:
"
Rewriting/migrating application A costs X dollars, needs Y developers and will be ready in Z month, backed by 30 years of research in software development efforts"
(then lean back and wait for the howling). When deciding about the fate of a Notes application a CoCoMo analysis can provide a much more accurate account than the 4 bucket approach certain migration tools try to sell you (bucket 1: standard IBM templates, bucket 2: lightly modified, bucket 3: highly modified, bucket 4: to be retired -- shame on you for your lack of control if bucket 4 contains a single database).
You can make a few simple assumptions: Migrating the application to a different platform will need at least the same amount of code. This is already generous since you can write fully functional applications in Notes with
almost no code and you have
hierarchical and solid
access protection build into Notes which can be
complicated to reproduce with other databases (read: needing lots of extra code). XPage enabling on the other hand will need less than half of the original lines of code. We don't have solid statistics but the effort is typically between 5-35%. The more apps you have, the less the percentage since XPages components are primed for reuse.
The big question: how to get the SLOC (source lines of code) count for a Notes application that you can then fill into the
online CoCoMo II calculator? Enter
DXL and
DXLMagic. The process has 4 steps:
- Extract your database as one DXL file. You can do that using the DXLMagic GUI, the command line or the DXL Exporter wizard. To setup DXLMagic to run from the command line check this post (where you actually should/could use the Java runtime of the Notes client) and the section about DXL in the DomDoc Redbook. This is the step that takes the most time, so be patient. You only need to do that once for every database since the exported DXL doesn't get modified. I also recommend to only export local NSF/NTF to avoid network congestion
- Run the DocumentDesignTags task for DXLMagic. It takes as file name or a directory name as parameter. What it does: checks for its configuration file
com.ibm.sg.dxlmagic.DocumentDesignTags.properties in the current directory and creates it with default settings if missing. Then parses all the tags inside the given DXL or for each DXL file in the given directory and subdirectories. For each DXL file one .metrics file gets created. In that file the number of tags found are listed as well as line of code counts for everything inside a <code> tag. The properties file helps to classify code entries (e.g. UI Code, DBCode)
- Run the DocumentDesignMetrics task for DXLMagic. It picks up all .metrics files in a given directory including subdirectories and creates one file that contains one row for each file found. The
com.ibm.sg.dxlmagic.DocumentDesignMetrics.properties file contains the list of tags you want to see in the output file. If missing the properties file gets created with default entries
- Open the result from step 3 in your favorite spreadsheet and add row and column sums. The grand total is the magic number. One could argue "a form is graphically created, that isn't LoC", but counting the paragraphs and fields is a good approximation for that. Some developers argue: a field definition should have a factor > 1 since it takes more time to code a field that to do a "Create - Field" in Domino Designer. Our experience shows the approximation is pretty good. But feel free to experiment
I use the following 2 command files (actually their Linux equivalents) to do the work (presuming your Notes install is in C:\Notes, and your output goes to C:\Work)
exportnsf.cmd
@echo off
REM Export Utility for NSF
ECHO Exporting %1
SET DYLD_LIBRARY_PATH=C:\Notes\
SET LD_LIBRARY_PATH=C:\Notes\
SET OLDPath=%PATH%
SET OLDClassPath=%CLASSPATH%
SET PATH=C:\Notes\;%PATH%
SET CLASSPATH=.;C:\Notes\jvm\lib\ext\*;%CLASSPATH%
java -Xmx2048m com.ibm.sg.dxlmagic.DesignExporter C:\Work %1
SET PATH=%OLDPath%
SET CLASSPATH=%OLDClassPath%
SET OLDPath=
SET OLDClassPath=
exit
Using this command file I can export nsf/ntf easily, e.g.:
exportnsf crm\customers.nsf. Once all databases are exported I run a second batch file:
documentnsf.cmd
@echo off
REM Document Utility for DXL
ECHO Documenting C:\Work
SET OLDPath=%PATH%
SET OLDClassPath=%CLASSPATH%
SET PATH=C:\Notes\;%PATH%
SET CLASSPATH=.;C:\Notes\jvm\lib\ext\*;%CLASSPATH%
java -Xmx1024m com.ibm.sg.dxlmagic.DocumentDesignTags C:\Work
java -Xmx1024m com.ibm.sg.dxlmagic.DocumentDesignMetrics C:\Work C:\Work\Report.csv
SET PATH=%OLDPath%
SET CLASSPATH=%OLDClassPath%
SET OLDPath=
SET OLDClassPath=
exit
This will result in the file C:\Work\Report.csv you can open in your
favorite spreadsheet to add the final totals. For detail setting this up on Linux or Mac, please check the Redbook. I wonder if we should build that into Domino Designer an optionally allow to post statistics to IBM on that. As usual: YMMV
(a bit hard to digest at times) and Clean Code: A Handbook of Agile Software Craftsmanship
.