This is the first in a series mini-posts on technical and architectural aspects of process asset repository systems. In this post I will introduce the process object engine sub-system.

Deployment of a process asset repository system is critical for any organization striving to advance from project-level process management—CMMI Level 2 maturity–to organizational wide process management that facilitates application of the organization’s best practices and lesson learned across all of its projects—CMMI Level 3 maturity.  Process asset repository system is an enterprise class application that manages all aspects—creation, storage, collaboration, consumption, appraisal–of the organizational process improvement needs.

Abstracted from the users, process object engine forms the core of process asset repository system. Other parts of the system, as well as, external applications interact with the process object engine through a set of web-services APIs. Process object engine provides the necessary infrastructure services including persistence, transaction support and change control.

Moreover, the organization’s process assets are granularly captured using an object model.  Process object model is an interesting topic and I will talk more about in future posts.

I just finished reading a white paper titled “Automating Processes for CMMI Maturity Level 3 and Beyond”. This paper argues that by using business process management (BPM) technologies you can achieve CMMI Maturity Level 3.
It is misleading and an over simplifing to state that BPM tools assist organizations in achieving CMMI Level 3.  Among other things, CMMI Level 3 requires implementation of Organizational Process Definition (OPD) and Organizational Process Focus (OPF) process areas. Both substantial organization wide undertakings and not addressed by BPM tools.
At best, BPM tools may help with some of the practices of CMMI Level 2 process areas, but they fall far short of satisfying even the CMMI Level 2 maturity or capability. As an example, these tools do not address Configuration Management (CM) process area at all. The best automation systems for CMMI Level 2 are ALM and process enactment tools.

I am working on a white paper about process asset repository systems. I should have an early draft of the paper by next week and will post it here soon.

I was trying to run a load test using Visual Studio Team Test Edition yesterday for a large data set and came across an error that said:

Error occurred running test. (Computer LOADTESTMACHINE) Could not access the load test results repository: The load test results repository is out of space. Allocate more space to the repository (if possible), or delete results of older load test runs.

Visual Studio dumps test results in a local instance of MS SQL Server Express and it was easy enough to guess that this was due to SQL Server Express exceeding the db size cap of 4GB (non-Express editions don’t have this cap). I have been running largish load tests on this machine for 8-9 months now and it made sense that I would run out of space.

I went looking for a solution and saw that Microsoft devs have suggested in forums and in blog posts that the DB be cleaned up via SQL to delete test results older than a time period of your choice.

Two things surprised me:

• There is no UI option to manage this in Visual Studio. Before I ran the sql commands, I tried deleting old test results via the “Test Results” window in VS. This apparently deletes exported test results - I am not sure what else it does but it didn’t seem to clean up the DB for the test results. So this means that if you want to clean up your DB when you run into these kind of issues, you need to talk dirty to SQL Server directly. Feels unclean. I Would like to know if I am missing something because this seems like something that shouldn’t require testers even going near a SQL Script.
• I tried and could not find any formal guidance or documentation on msdn to address this issue, even in Practices & Patterns. I may have missed it totally so I hope somebody corrects me if this is actually there. This would be a pretty common scenario I would think so it deserves better than users needing to search blogs and the forums for an answer.

The script I ran is included with this post. A few things to keep in mind:

1. This script cleans up only Load Test Results
2. If you are using a typical installation of Visual Studio Team Test Edition, you need to run this against the db named “LoadTest” on the locally installed instance of MS SQL Server Express installed during Visual Studio installation.
3. Change the value of the @DaysToKeep variable to a suitable value in days. I have set it to 30 days in the script so that results older than 30 days are deleted.
   --@DaysToKeep - indicates the number of previous days records to keep. For example "30" indicates that I want to delete test results older than 30 days
DECLARE @DaysToKeep int
Set @DaysToKeep = 30
4. This script may take a very long time to run - think in terms of hours rather than minutes. It took about 2-2.5 hours in my case. So, don’t abort the execution because you think the script is stuck.

The script (rename to .sql):
deleteoldloadtestresults.txt

Application Lifecycle Management (ALM) is often wrongly thought to only cover only the Software Development Life cycle (SDLC). David Chappell’s excellent and concise whitepaper focuses on this misconception and explains how ALM is more than just the development of the application though that is certainly an important part of it.

ALM is broken down into the Governance, Development and Operations aspects. More importantly Chappell continues the point I had made briefly in my previous post - that there are ALM tools out there which are largely concentrated on the development aspect but their true value can be achieved by integrating them with tools that cover other aspects of ALM - eg: CRM.

To quote the whitepaper:

The three aspects of ALM—governance, development, and operations—are tightly connected to one another. Doing all three well is a requirement for any organization that aspires to maximize the business value of custom software. But this isn’t an easy goal to achieve. Each of the three is challenging to get
right on its own, and so getting the combination right is even more challenging. The right tools can make this easier. A number of vendors today provide tools that are horizontally integrated, i.e., tools that work together well on one of the three lines. For example, Microsoft’s Visual Studio Team System brings together a range of tools supporting several aspects of the development process. Yet tools should be integrated not just horizontally but vertically as well, helping organizations make connections across the three lines. For instance, project management tools should be connected to development tools, which in turn should have connections to the tools used for operations.

These connections are beginning to appear. Visual Studio Team System, for example, can connect with Microsoft’s Project Server to help project managers get up-to-date information on what developers are doing. There’s still plenty of room for improvement, however, and no vendor today offers a set of ALM tools with full vertical integration across all three lines. Tools should be integrated not just horizontally but vertically too.

Read the complete white paper here.

For the last month, we have been working on an automated self-appraisal method. This effort was motivated by the need of our customers who, while realizing the necessity of appraisal for process improvement, find existing appraisal methods expensive and time consuming. These organizations have concluded that regular self-appraisals would enhance their internal process improvement programs.

Automation of appraisal method significantly reduces the cost and duration of appraisals. The other benefits of automation include objectivity, consistency, and accessibility. Objectivity is critical to any appraisal process. By definition appraisals must be objective and unbiased. Consistency across appraisals makes incremental process improvement meaningful. Accessibility democratizes the appraisal process by allowing people involved in the organization’s process improvement initiative to assess their processes, at any time, in a self-serve manner.

This appraisal method meets a subset of Appraisal Requirements for CMMI (ARC) V1.2. Although ARC defines the requirements considered essential to appraisal method intended for use with CMMI models, not all appraisal methods are expected to be fully ARC-compliant. We selected the relevant subset of ARC with the largest benefit for the effort. In future posts, I discuss these requirements in more details.

We are building the first iteration of the appraisal method on top of IRIS Process Author.

IBM Rational team launched EPF more than five years ago with a premise of creating an open source like community for software development processes and methodologies. Unfortunately, from the beginning, the Rational team was not willing to give up control and EPF has been only open in name than in reality. I would say, 99% of the contribution so far has been from IBM. Initially EPF was supposed to be a kernel based methodology. Plug-ins were to be added to the kernel as to satisfy the requirements of development project environments. This takes an additive adoption of methodology rather than RUP’s trimming approach. After few years of taking this approach, suddenly EPF changed direction and took a practice based approach. Now it seems that the IBM Rational team has abandoned EPF and has moved to their latest story: Measured Capability Improvement Framework (MCIF). I don’t know much about MCIF right now, but intent to research it.

My point is that this is an irresponsible behavior by respected methodologies, it confuses the potential adaptors and the grater market. I rather have IBM methodologies (content team) keep a low profile and let the badly need Jazz (very impressive IBM tool to rival VSTS) based tools flourish.

I have been reading Payman’s posts over the past week and the No new Methodology Please; Let’s focus on Tools post in particular stuck with me because it focuses on something I have been thinking about too. His post talks about the noise in the processes domain where there is a lot of focus on coming up with unnecessarily niche processes rather than focus on actually making processes useful by developing tools that make employing existing mature processes practical.

While Payman’s post focuses on processes, it struck me that even where tools go, often companies employ ALM tools with a narrow focus without fully grasping how they can be fully leveraged and what capabilities these tools pack. Over the last year, we have helped design and deploy solutions based on Microsoft Visual studio Team System (VSTS) for a few customers. One of the key needs that kept leaping out at us from all these engagements is that most customers wanted a way to implement requirements traceability – and they were not always aware that most ALM tools already have the capability to implement end-to-end Requirements Management – in particular traceability.

VSTS for example provides advanced linking capabilities that can be leveraged to allow tracking execution of a requirement from beginning to end (and backwards as well). A number of tools have come up around VSTS to satisfy other aspects of traceability such as the ability to track and link requirements within documents – document traceability.  Traceability has always been this much sought after goal – which many companies have been attempting to address in their tools for many years. Now, the tools exist but most of us are not aware how to leverage them or even that the capability exists.

Over the following few weeks, I am thinking of putting up a series of blog posts focusing on Traceability to think through for myself and others who are interested in Traceability – how to leverage tools – with particular focus on VSTS since I am most familiar with it. A recent solution we implemented for a customer involved integrating VSTS with their CRM solution so that the solution was now truly end-to-end : Right from the time the requirement came in from the customer. In a future post, I hope to outline the lessons we learnt from this particular implementation and also step back to examine the broader implications and advantages of implementing such integrations.

We are also discussing the possibility of perhaps even having a series of webinars that focus on various aspects of Traceability based on our experience over many projects over the years and  how we can leverage VSTS for the purpose.

Watch this space.