This will be an evolving post providing summary info about software development topics of interest to me. I will include links to papers written by me, but most of the others are IEEE or ACM journal articles that cannot be freely distributed. I will strive to provide links to the abstracts where possible.
The process of building software systems involves many different activities, but it seems to me that the rubber meets the road with the architecture. This coarse, componetized view of the system is where the requirements first run into an objective measure. Yet it is the architecture itself that must be evaluated with respect to the requirements. The artifacts produced by the architect often anchor communication between the stakeholders on a project, and they will serve as the entry point for team members to begin understanding the system.
I will add some more detail on each of these aspects soon: Systems Engineering Process Activities (SEPA), ATAM, Evaluating, Software Development Process/Lifecycle, Tool for Communication
My graduate work focused on a couple of key architectural components - the construction of a Domain Object Model (this is akin to the Domain Reference Architecture in the SEPA process) from a set of requirements elicitation interviews, and the evaluation of that model against standards of completeness and correctness.
Thesis: Establishing the Completeness and Correctness of a Domain Object Model
Another very interesting subject area for me was Data Mining. Here I used tools like Weka (now absorbed into the open-source Pentaho suite) to extract novel, actionable knowledge from data warehouses. I had an opportunity there to collaborate on an interesting case-study using convenience store data.
KDD (Knowledge Discovery in Databases)/Data Mining: Knowledge Mining Convenience Store Sales Data
Software testing generates a great deal of zealous discussion among developers. 100% code coverage, black box, white box, mutation detection, unit, functional, acceptance, test driven development (TDD), integration, system - all of these aspects of testing software must be stacked up against the businesss value delivered. What we need is a good return on investment for the time and effort spent writing, executing, and maintaining the tests. My ideas on the subject have evolved quite a bit over the years. One interesting project I worked on involved implementing the Korat unit testing algorithm with a GUI to allow incremental improvement of the key evaluation routine. Interestingly enough, I later came across a commercial product (Agitar) that did a very nice job with a similar solution. There is no Korat in the mix (as far as I know), but it does a nice job of allowing the developer to manage the state-space explosion problem nonetheless.
Verification and Validation of Software Systems: Korat Visual Finitization Editor
More to come…
