IT Business: Canadian CIOs lash out at compliance pressures
One of my colleagues came across this article at ITBusiness.ca :
They're sick and tired of being needled by auditors and forced to adopt inefficient policies, and they're not afraid to talk about it. Read exclusive excerpts from a roundtable where the frustrations came to the forefront
There is a good cross-section of opinions mentioned in the article. It is indeed a reflection on the dramatic regulatory changes that are affecting IT.
One of the core things that I speak about regularly in regards to managing the software lifecycle is around compliance, specifically, audit and traceable results . In particular, there are very specific pieces of Team Foundation Server that can be leveraged to support regulatory compliance in the application development and maintenance lifecycle:
1) Process: In particular, actionable process guidance that supports multiple view facets. From a regulatory point of view, it is just as important to point out why you are acting a certain way as it is to point out the granular details of what you did. Linking process to measures of progress through tooling is also of great benefit. It allows for fantastic and flexible ways to ensure that you are following appropriate procedures before, during, and after activities.
Team Foundation Server enacts process through the use of process templates. One of the most common misconceptions around Team System is that you can only use it with the included MSF process guidance templates (Agile or CMMI 3). This is factually incorrect, and TFS actually provides a very extensible model for enabling external processes, through process template creation/customization, and a rich eventing and programming model. The latest process template editor can be found in the Team Foundation Server Power Tools, a free download at https://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx .
In particular, process guidance can be produced in a number of different ways. To simulate the highly robust process documentation included in TFS for MSF, once can use this process guidance as a template for customization. Using a combination of tools, an organization can download the source MSF documentation from https://msdn2.microsoft.com/en-us/teamsystem/aa718795.aspx , and use rich tools such as Microsoft Office InfoPath to edit the source materials. Once completed, the edited source can be recompiled to generate your own, fully linked and cross-referenced process guidance, in standard html format. This is documented in a number of places, but a great place to start is at https://msdn2.microsoft.com/en-us/library/aa730855(VS.80).aspx .
2) Work Item Tracking: More than just a single repository for actionable lists of work tasks, such as requirements, change requests, bugs, tasks, scenarios, and so on, it provides the ability to track all of the elements of those different lists using the metadata and workflow that is specific to your process and your organization. This allows you to store information that impacts your regulatory requirements, and supports your process.
A key benefit here is the ability to define your own terminology, your own attributes, and indicate wether or not you want that information exposed to the data warehouse for reporting purposes. Additionally, every action taken on a work item is tracked, for full audit purposes, from a small field changing value to modifications of large amounts of the data. This feeds directly into audit requirements. Your audit can be largely satisfied by the work item tracking history, and supplemented with additional information presented through reports from the data warehouse, or artifact storage (such as external documentation or source assets under version control).
3) Source Control- The ability to easily enforce work item to work product linkages (through the integration between work item tracking and the version control system) further supports audit requirements. Version control policy, which can be enabled through administrative settings on a project, allow even more granular control over policies regarding interaction with source artifacts. The policy system is naturally extensible to allow the enablement of virtually any process requirement.
In addition, the version control system, being server based, is entirely transactional. All units of change are captured as transactional units of change, that include not only the actual change affecting the artifact, but also the full context of the change, including the date, time, user (domain user account), associated comments, related work items, etc. These units of change, called changesets, provide a full historical view of the development of the system. When combined with work item information, this becomes a very powerful supplier to audit information.
There's a lot more here, too, including robust reporting capabilities that are completely customizable and linked to your meta-model. But enough for now, I'm not writing a book :)