4 min to read
SEPG
Recently, I have been very involved in hiring for and growing our Software Engineering Process Group (SEPG). Thus far, I have either distanced myself or paid scant attention to this part of software development. But my involvement in this initiative has made me to rethink through this and consider it in a new light. As I delved a little deeper into SEPG, I understood that SEPG = SQA (Software Quality Assurance) + SQC (Software Quality Checking) + Others depending on the organizational complexity and also its propensity to go after every certification available under the sun.
SEPG Purpose
According to me, SEPG first needs to be distinguished from its very close cousin - the Software Engineering Methodology Group. The Methodology group promotes a certain way of developing software - be it RUP (Rational Unified Process), AGILE or even the Waterfall model - ugh! In contrast to this group, the SEPG group is more focussed on the capture of Software Process Metrics and a standard way of tracking the execution of software development. SEPG is all about repeatability and learning across different projects. SEPG should ensure uniformity across different projects irrespective of which actual methodology the project follows. This is so important that it is worth repeating. What we are saying is that individual projects may follow whatever methodology they want to follow - be it RUP or AGILE but the same kind of metrics are captured across all of them. And these metrics are captured at the same designated interval of time. Sometimes the capture of these metrics may be triggered by actual events in the software development life cycle such as the release of software to QA, release of software to production, GO ALIVE release of software etc. CMMi or ISO certifications help in this effort as they talk about the uniformity of metrics and the trackability of requirements as they become features of the developed software. But certification is a very obsessive thing - the company may pursue certification and ignore its main goal that of software quality.
SEPG Inception
Typically, the first step in SEPG inception is of course the actual hiring of the SEPG folks. No surprises there! The group then decides to meet with the stake holders to see what needs to be done to ensure that we become a learning organization. Various software metrics would now need to be captured at specified intervals of time as mentioned before. The simplest way to capture these metrics is to request users to enter these at periodic intervals to a metrics system. Of course, the veracity of this information would be questionable since this metrics application is independent of the software development system. The time of inception of the SEPG group within an organization heralds the time when the organization has become a “learning organization”. As such, there is a certain amount of resistance in the organization - especially from developers who would find, that this stringency in adhering to capturing software metrics, is hindering creativity. No developer wants his entire time to be monitored and micro managed!! Process proliferation, even with the noble objective of capturing metrics, should not be the objective of any SEPG initiative if it intends to be useful to the organization. So there arises an all too familiar tussle between the SEPG group and the developer community. Excessive emphasis on processes, does hinder developer productivity. But in the absence of these metrics, the organization would not know whether it is becoming better or worse for there are no metrics to measure how it is faring.
An Agile Approach to SEPG
These paradoxical confrontation of priorities from two different requirements is amicably resolved by the Agile methodologies. A detailed discussion of what Agile means and what it does, is deferred to other sources. In this blog entry, we would just examine the process automation part of Agile. Agile relies on automation to implement its strategies such as continuous integration and continuous testing. But the same automation can be used to capture the software metrics that we talked about. This would mean that we just have to get better in tracking issues, resolving them and doing software releases. The entire purpose of software development is to add features to an application. I believe that tracking requirements against a release date and having a systematic release procedure are the key ingredients towards development of a trackable system that automates the capture of most SEPG metrics.
Comments