There have been quite a few development posts in our blog as of late, so I thought I’d share some current activities from our products and services front.

In the past month, we welcomed three new customers to our IRIS Product Suite and Content Bridge for VSTS, including a large Canadian Federal government agency. Two of the customers were specifically looking for a solution to bring RUP or RUP-inspired methodology into VSTS for process enactment. After evaluating their requirements, we selected the right tool from our product family and provided our expertise in this area to deliver the needed solutions for them.

As VSTS continues to gain maturity as an ALM tool, we have noticed growing interest in processes and process integration within the development environment to facilitate its enactment. Organizations who have adopted TFS initially for centralized source control and automated build capabilities are now ready for more. After having deployed and migrated existing projects to VSTS, many are looking into bringing their own processes into the tool to benefit from process guidance and work item tracking in their daily development activities.

However, creating process templates for proprietary processes remains a challenge. In this regard, it is a pity that a process tool, such as RMC, does not provide cross-platform support to generate process templates that can be used in a (competitor) enactment platform.

I believe that a well-rounded process tool should not only satisfy the modeling needs of process authors, but also provide the necessary support to help project teams deploy and implement processes in a chosen enactment tool, whichever it may be.

For those who are interested in seeing an RUP process template live in action in VSTS, here is a recording of a webinar that we hosted with Microsoft last year. In this webinar, I used an RUP Process Template for Small Projects as an example to create a project in VSTS.

In an earlier post, I referred  to the Work Item Tracking iPhone app we are currently working on. The development of this app was motivated by our heavy reliance on Team Foundation Server’s (TFS) Work Item Tracking for internal projects. Using a web browser, our project teams (in Toronto and Bangkok) and customers have a real-time detailed view of  their projects. We felt having the same level of project visibility  via a mobile device would be very useful.

We wanted the Work Item Tracking app to work with any TFS without requiring installation of additional server module. Consequently, the app has to rely on web services to communicate with TFS server. This isn’t as simple as you may think. Microsoft considers work item tracking web services as too complex for third part development, and doesn’t publish the APIs.  Instead Microsoft provides a client component, which wraps the web services, and provides a .Net Object Model API. Fortunately, our team has been able to discover the required work item web services APIs.

Currently I am working on the module that gets a list of projects and work item types for each project from a TFS. I will include screen captures of this module in a future post.

Recently I was part of the FDA 21 Code of Federal Regulations Part 11 (Part 11) audit of one of our custom software development projects. Part 11 audit is mandatory for any pharmaceutical system that uses electronic records and signatures in lieu of paper records. Our audit went surprisingly smoothly, and overall a positive experience for the team, reaffirming my beliefs about the benefits of established development processes and tools. This post briefly covers what contributed to the success of this audit.

Part 11 requires a software development process to be defined and followed. The process should have specific requirements, such as reviews of all the key milestones (e.g. System Requirements), and a well defined Validation phase (functional testing).

One of our internal product development processes was a good starting point for the definition of the process required for this customer project. As all our processes are stored in IRIS Process Author (IPA) in a reusable form, at the outset of the project, we were able to easily make the required adjustments to the selected base process to better suit the project. The process was then shared with the project team in a published form—in the project portal. During the audit, the external auditors carefully reviewed the details of this process and were fully satisfied with its coverage.

I was also required to demonstrate to the external auditors that our team was aware and followed the process. We use Microsoft Visual Studio Team Foundation Server (VSTS) as the development tool. IPA can generate VSTS process templates. In doing so, each activity of the process becomes a work item. In addition, all the process information such as description, steps, and roles, are captured as work items ensuring that every member of the team has access to process information when they need it. Hence the project team was steeped in the process being enacted. This showed the external auditors that the process was fully internalized by the project team and would not be abandoned at times of stress.

VSTS was also used for planning and managing issues, risks, and tasks, a single repository for all project artifacts. As VSTS is tightly integrated with MS Project, project managers were able to generate schedules and track the team’s progress.

In one of my sessions with the auditors, I did not have printouts for all issues and defects with me. When the auditors asked for evidence for certain scenarios, I was able to use VSTS (through web interface), and generate excel spreadsheet for the requested scenarios on the spot. This drove home for me the importance of having a central repository that instantly provide access to all project artifacts, which can be used as direct evidence during the audit process.

I believe process and tools are like two wings of a bird. To fly this bird needs both. Having a well-defined process in place is a great first step but unless the team has the tools that seamlessly incorporate the process into their daily work, the process is not internalized. High performance teams such as ours value being process-centric and disciplined, as long as processes are not a drag on their daily work. The integration of processes with tools not only helps with a positive audit experience, it also results in a motivated and disciplined development organization.

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

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.