New Whitepaper: Agile and High Assurance

Finally.

For those who have been following the High Assurance and Regulated Environments series, I am pleased to announce the completion and publication of the whitepaper: Agile Software Development with Verification and Validation in High Assurance and Regulated Environments.

(Click on the image below to download a copy.)

This document was the result of a year-long research project and collaboration with a number of other experts in the field. I’d like to particularly thank Craig Langenfeld of Rally, who persistently moved the project forward and built all the examples, and Michael Messier, VP for Software R&D at Omnyx, who provided in-depth domain expertise and helpful reviews along the way.

Advertisement

HIgh Assurance Series Update

I haven’t posted much in this category lately as I’ve been busy drafting and redrafting the new whitepaper: Agile Software Development with Verification and Validation in High Assurance and Regulated Environments.

(Ok, I’ve been goofing off some, too.) But finally, Craig Langenfeld and I finished the final draft and it’s now in Rally’s hands for release. (Note: the body of the whitepaper is solely method guidance and is tool agnostic; but Craig has provided 8-10 screenshots of using Rally’s app in the Appendix. As I have mentioned, it’s foolish to attempt enterprise agility, much less high assurance agility, without proper tooling of some sort. Pick your vendor, but pick a competent tool).

I’d expect the whitepaper will be released by Rally next week at Agile 2011, and as soon as it is, I’ll post a copy here, too. I’ll be presenting at Agile 2011 on Wednesday, though not on this topic. My presentation topic will be Advanced Practices in Enterprise Agility: Five Keys to building the Lean|Agile Enterprise. I’ll post that briefing here this weekend.

In the meantime, those tooling high assurance will want to take a look at Craig’s latest post HIgh Assurance Agile Software Development Traceability Matrix Examples which illustrates traceability options inherent in a well formed, and tooled, requirements hierarchy.

Tooling for User Story Verification, Part 2

Note: This post is a continuation of the series on Agile in High Assurance and Regulated Environments.

In the last post in this series, Tooling to Automate User Story Verification, I pointed to a post, Tools to Automate User Story Verification – Part 1: Rally and Quality Center, by my collaborator Craig Langenfeld, wherein he describes how HP Quality Center can be used to perform Verification Testing on User Stories that are planned, tracked, and managed within Rally. That post describes one of the three potential user story-level verification paths that I described in an earlier post, Software Verification and Validation in High Assurance Agile Development: SRS and User Story Verification, illustrated below as follows.

High Assurance User Story Traceability Paths

This user-story to story-acceptance-test  verification/traceability path is probably the most critical verification step, as it illustrates that the story has been tested and accepted into the baseline via the story acceptance test. For many in high assurance, that’s as far as they need to go with verification at the story level. However, if the risk analysis determines that certain pieces of code are extremely  critical for safety and efficacy, then one or both of the other two paths:

• user-story to code-that-implements-the-story, and
• user-story to unit-tests-that-tests-the-code-that-implements-the-story,

may also be necessary.

In this new post, Tools to Automate User Story Verification – Part 2: Incorporating SCM, Craig shows how to link the user story to a changeset in the SCM system, in this case, Subversion. And since its likely that the source file will be revised a number of times through the course of an iteration, Craig illustrates how, with the addition of a small custom program provided by Barry Mullen , “an Iteration Diff Report App can be used to pull all those revisions together and, in the case of viewvc users, create a link to the diff for all changes. This is useful for conducting code and/or security audits of the code changed for that iteration.”

This part completes the user-story-verification-via-tooling part of our high assurance story.

However, the second part of the post illustrates another important step, which is an in-sprint validation step. Since, the inclusion of the new story into the baseline changes the behavior of the system, it is necessary to assure that the whole system still works as intended.  To help make this a largely automated function, Craig shows how an  an integration from the agile project management tool (in this case Rally) to the automated build system (in this case Hudson) monitors the build health during the course of the iteration, thereby assuring that all the build verification tests (new and old) still pass when the new story is added to the baseline.

In the next post in this series, we’ll look at tooling to support the higher level traceability path, from the feature in the Product Requirements Document to the User Stories in the Software Requirements Specification, (or equivalent repository).

Tooling to Automate User Story Verification

In a recent post, I noted that Craig Langenfeld, my co-contributor on the Agile in High-Assurance and Regulated Environments series, was beginning to describe how tooling can be used to automate (or semi-automate) much of the formal verification activities we’ll need to assure that a) our software works exactly as intended, and b) leaving a traceability-audit trail for the device history records as called out by the company’s quality management system (QMS).

In earlier posts in this series, I described an important sub-thread, which is the verification of user stories in the course of each iteration. I pointed that in order to assure that each new user story works as intended, we’ll want to verify it via three traceability paths:

• User story to code – path to the SCM record that illustrates when and where the code was changed to implement the story
• User story to code-level unit test (the “white box” test which helps assure the new code works to its internal (code level) specifications
• User Story to Story acceptance tests (black box testing of the user story to make sure the system functions as intended)

Craig has recently published his first two posts on this important sub-thread in our larger verification and validation picture. In his first post he describes two things:

1)   How built in story to task relationships increase the rigor and traceability of the TASKS we’ll use to define|build|verify each user story, and

2)   How you can use Rally to persist the story, the story acceptance tests and the story to acceptance test verification paths. (Bullet #3 above).

However, for many practitioners Rally is not the only tool in the project environment, so in a second post he describes how HP Quality Center can be used to perform Verification Testing on User Stories that are planned, tracked, and managed within Rally.

As I mentioned in a prior post in this series, effective, scalable agile project management tooling is a critical component to developing and documenting high-assurance software, so I am happy so see these tooling examples and look forward to the next few posts in Craig’s series. As usual, I’ll keep you “post”ed.