Interesting article on risk management in software development

In keeping with our agile development, I came across M. Jorgensen's article (direct link to pdf).

Abstract
Software professionals are, on average, over-optimistic about the required effort usage and the success probability of software development projects. This paper hypothesizes that common risk analysis processes may contribute to this over-optimism and over-confidence. Evidence from four experiments with software professionals, together with research in other domains, supports this hypothesis. The results of the experiments imply that in some situations more risk analysis leads to over-optimism and over-confidence, instead of the intended improvement of realism. Possible explanations of this counter-intuitive finding relate to results from cognitive science on “illusion-of-control,” “cognitive accessibility,”, “the peak-end rule” and “risk as feeling.”. The results suggest that it matters how risk analysis and effort estimation processes are combined. An approach is presented that is designed to avoid an increase in optimism and confidence with more risk analysis.

Tracker cleanup

I worked on the sourceforge.net trackers to help track the changes being made for the current production releases (Grid Publisher and Quicksilver). I added the following groups to help track which product release (and code branch) the Bug or Feature Request belongs within:

• AMDS-1.0-Initial release of AMDS services


• QS-1.0-Initial release of Quicksilver


• QS-1.x-bug fixes and additional FRs for next release of Quicksilver


• GV-1.0-Initial release of the Grid Viewer


• GP-1.0-Initial release of the Grid Publisher

These changes should make it easier for us to communicate what changes and fixes go into specific releases.

PHGrid Calendar

I've updated the PHGrid Calendar on the wiki. With the overall objective of demonstrating pilot AMDS services through the Grid by PHIN there are a lot of items across several of the dates, targeting to be demo ready by July 15. I've marked the key deliverables with the creative term "Milestone". You'll notice there are 9 Milestones between now and July 15. For each Milestone (and the Milestones only) I have placed a short description of the deliverable. This calendar is a living entity, and will be updated to reflect important collaboration and deliverable activities.

Updated programming playground rules

I updated the initial blog posting from June 5, 2008 and updated based on additional developments and moved it over to the wiki for easier updating. This will be the place where the NCPHI Lab's and eventually the PHGrid's programming conventions and policies are captured:

• Use Sourceforge Subversion site to store changes - All changes are checked into the Subversion site on the sourceforge project. Only security related changes (passwords, etc) are not checked in, and these are factored out into a property or configuration file.


• Everything builds - Maven is used to build (compile and package) and deploy changes. This will allow for changes to be made on different desktops without spending time trying to manually configure a new environment. This also means that if the build breaks then the developer who broke it needs to fix it as soon as possible.


• Follow the Sun Code Conventions for Java. These are old, but still applicable for what we're trying to do. We picked this sort of as a default and this can change based on feedback and practice, but we want some uniform style to the project.


• Document code- document code to improve clarity. Use javadocs where necessary. This is not documentation for documentation's sake, but enough so that someone coming across the code will be able to follow. This doesn't absolve a programmer from clean, concise coding but should improve on the clarity of a source file.


• Write a Use Case first- the first step to development should be to make a post on this blog describing the use case. Nothing too formal, just a description of the steps, who will perform them, alternate flows and error handing. This will provide a way to capture the requirements before any code is written.


• Next write a Test Case before coding- after the use case is posted and there's some sort of agreement, then a test case is written while the coding is performed. This speeds up development by institutionalizing testing in a standard manner.


• Each project will have a separate folder in the sourceforge root with a Maven pom.xml file for the build (including dependencies).


• All properties are stored in a configuration file to allow for projects to be easily built for various target environments. Actual values are not checked into sourceforge as these property values are likely sensitive (server names, passwords, etc.). For example a project named foo would build based on the properties stored in foo.properties. The file checked into SVN would be named foo.properties.template and contain descriptions for each of the properties, but not values. When a developer is building, they will take the proeprties file as configured for an environment, rename it to foo.properties and run their build. It is likely that you will have foo-dev.properties, foo-training.properties, foo-staging.properties, foo-production.properties (none checked into SVN) and choose a properties file based on where your deployment is targeted.


• All changes are tracked using the SourceForge tracker for Bugs and Feature Requests. This is done to project project transparency to all our changes and prioritization of changes.


• Every Friday, the current project state is built to the training node (ncphi.phgrid.net) so that the community can see progress and comment. Eventually, our CM processes will be run nightly and deployed more frequently than once a week.


• Each evening, before leaving each developer ensures that their changes adhere to these rules and checks them into SVN.

Project Mgmt Update

A lot of moving parts, so at the suggestion of the team, thought it'd be good to note the important happenings:

1. A PH Grid Charter draft has been produced and is currently in review by program staff.

2. A draft PH Grid Project schedule is being drawn up now, with the first draft nailed down by Friday COB.

3. We are preparing for a Poison Control visit tomorrow (nice work on the demo, Peter), where we will have a tour of the lab, and discuss two major topics. A) future enhancements to the Poi Con web service and B) Poi Con web service security requirements

4. We are working with ESRI, the NCPHI lab, and South Carolina to get the PH-DGINet nodes, services, and demos working as they were post-PHIN. Some changes to all the environments have led to poor communication handoffs on my end.

5. We have received feedback on the proposed AMDS, and we will be working internally by the end of the week to discuss next steps.

6. Tom Savel and I have discussed how best to recruit and provide nodes (be them DGINet or Globus) to state and local health agencies. Right now, a multi-prong approach including possible regional collaborative coordination, HIE recruiting, GIS community recruiting, and program priorities is recommended. If you have any ideas or any interest in having a node (especially if you are a public health department or some of your best friends are public health departments), please let me know.

7. A draft PH Grid security policies document and conceptual architecture has been produced. Please let us know if you're interested in seeing either.

8. Next week: AMIA demos

Tracking Changes

The phgrid sourceforge project is now configured to use sourceforge tracking to track changes to the PHGrid projects. So far, there are two active trackers: Feature Requests and Bugs.

The group has been very active in developing out services and demo apps, now that activity will be even more transparent by tracking the changes as they are submitted, prioritized, assigned, developed and tested.

The sourceforge tracker has rather obvious limitations (fixed workflow, no assigned tester field, on and on) but it's free. Any suggestions are appreciated.

This can also be used by the community to suggest new features, services or bugfixes.

To support this tracking, I'm recapping our development workflow below (which is available as a pretty graphic on the wiki):

1. User Enter Feature/Bug with description (with or without use case)


2. Admin Prioritize/Assign change


3. Developer creates (or updates if use case exists) and posts use case, use case is reviewed


4. Developer codes change in new branch with automated unit testing (JUnit, etc)


5. Developer assigns change to tester (other than developer)


6. Tester reviews code and either approves (go to #7) or notes required changes (go to #3)


7. Developer committs change to trunk/release


8. Admin closes Feature/Bug

Lab (Re)Engagement

Tom Savel, Dan and I met yesterday with the NCPHI Lab management team to review the resources needed for the three Proof of Concept projects. The lab management team approved the activities and are working on allocating and configuring the additional resources for the 3 PoCs.

This means that we can begin to reinvestigate using VM appliances for distribution as PHGrid nodes. In the past, an exception was made to allow a single VM appliance to be used, but now the lab team is able to support using VM appliances for additional nodes.

Related to the lab engagement is that the WS-RM portions of the Secure Reliable Grid Messaging PoC will not be posted directly to the blog/sourceforge/wiki until they are approved by the Gautam Kesarinath, the NCPHI project steward responsible for the WS-RM portion of the PoC.

Project Management update

We held the a project kickoff meeting for the CDC and Contractor resources who will be working on the Secure Reliable Grid Messaging PoC. We'll be meeting over the following few days to get together a set of detailed requirements and tasks based on the project charter. Following from this will be timelines and resources on the tasks so we can establish more fine grained expectations.

I met with Tom Brinks this afternoon and we started working on a work breakdown structure to define the functional areas within the project. We'll post a draft on the wiki as soon as something digital exists.

Status Reporting

In order to better track the three proof of concept projects, I'll be posting status reports to this blog weekly by close of business each Friday. These status reports will be fully compliant with the CDC Unified Process.

This should provide a good level of transparency to the community as to how the PHRGrid projects are progressing. This is also more testing as to how open source development can be used on projects.