The Software Engineering Institute (SEI) was formed to provide the US government with a body that developed standards for the human and technology aspects of the processes of software and systems development. It is a research and development centre. It now has a European office in Frankfurt. So what does this mean to me you are probably asking yourself? Possibly not very much but for a few minutes of your time you may find that there is something the SEI can offer you by way of a different perspective on software and the process of developing software.
The purpose of the SEI (www.sei.cmu.edu) is to enable organisations to make measurable improvements in the way they deliver code, defect free, on time and within budget. This is the Holy Grail that all users of software would like to see. They don't want to be guinea pigs with every package or application they have to work with. The SEI has worked hard on establishing a model that enable organisations and people to understand where they are and where they would like to be in the future – with a transition path to get there. The organisation has expanded its services and expertise beyond the model initially developed, the Capability Maturity Model (CMM). The book, Managing the Software Process by Watts Humphries, covers the CMM and how to improve the process..
The adoption of the model is most likely more appropriate in the larger corporate organizations when implemented in a more formal manner in the more technical industries such as Telco, Aerospace and Defence. The computer industry that supplies hardware, software and services to these sectors saw an opportunity to provide development tools with services including knowledge transfer of the CMM and how it would/could work in an organisation. It was and potentially still is a big ticket item! This may not seem to be relevant to smaller organisation but I would argue that it does. Even the principles, if not the practice, are relevant to the production of software.
So - what does it do for the developer?
Firstly, I think that it helps to instill a mindset that has the quality of the code at the centre. Around that there are a number of core elements such as management, process, improvement, repeatability and communications. In reality this stuff applies to any human business activity but we are either too lazy or lack the knowledge to do it.
Secondly, it makes you think about the impact of whether you are doing or not doing something and communicating that to your peers in a team. This is a key issue because as we have seen in many stark situations, imperial gallons have been measured as litres, millimeters as centimeters, or scales on engineering drawings measured in metric but implemented as imperial and so on. These types of mistakes have lead to not enough fuel being pumped into a passenger aircraft, resulting in a serious incident. Some lead to costly errors and others can result in death. You may think that this is an extreme example and not relevant but I would take issue, because there are two things that matter here. Firstly, there is the capability and knowledge to do the job correctly and secondly the communication, recording and checking the work that has been done. If the management process supports these then the risk are reduced, which in turn means the impact of a mistake is also lessened dramatically.
Thirdly, it could be used as the basis for an apprenticeship, like the apprentice model of years ago. This way of passing on knowledge to the younger generation went out of fashion, but it seems to be making a comeback now. The role of the apprentice was to learn from the experienced hand who had been doing the job for years. Supported by training, especially updated training on new methods of doing things, the apprentice would become experienced through a two or more year process. This typically applied to trades such as plumbing, electricity etc. I believe that this could be a vehicle to transfer knowledge from the older generation of developers to the younger generation. Aside from the courses in university (which is a separate issue) not much on the management and process side is appropriately taught in computer science degrees. They are too technology orientated, unless you know different ;-)).
Fourthly, it provides a framework in which the developer can work to deliver code that is free from bugs and on time and on budget. The measurements are goal orientated and not focused on time and money. The normal measurement is a financial measurement which means the mindset is focused on delivery and not on the quality and robustness of the code. The framework need not be heavy duty – lightweight and flexible may in the end turn out to be best for most projects because that is the nature of the beast. But where governance and accountability is important a more heavier duty framework will go the distance a you will need to have documented all of the activity, people, spend etc for and inquiry on the state of the project and the software that has been produced. If it is software that has a direct bearing on life or death then the ability to show how the code was derived, how it is structured, how it is put together with other code, what the processes were for defining requirements, audit trail from code to initial idea, how the developers worked, what standards they use etc. is critical. Perhaps more applications should have a "black box" for code, a component inside the software that can take readings from points in the application as it running. I know that there are a few products like this but if more users required this to be part of the application we may see software quality issues reduce.
So what should you be doing? I suggest a review of your current development practices and what you think needs to be done. Look at the SEI website and see what nuggets of information that you could use in your team or organization (no matter how small it may be). Check out http://www.sei.cmu.edu/ .
It would be interesting to hear how you get on, please let me know by emailing me at paul@thedeveloperscatalogue.com .
Paul has over 25 years in the computer industry working in the area of software development. He has worked for Digital Equipment Corp, Sun Microsystems, Olivetti Systems and a number of companies developing software applications. He is currently running a new developers website - http://www.thedeveloperscatalogue.com/ - and he is also writing articles for the site and for other publications including International Developer Magazine.
It would be interesting to hear how you get on, please let me know by emailing me at paul@thedeveloperscatalogue.com .
No comments:
Post a Comment