|
There is an age old debate about who's responsible for Quality in software. Some people have Quality teams, others dedicate Quality to Testing. The Rational Unified Process (RUP v2002) says: Quote: It goes on to say that the Project manager should ultimately own and be responsible for Quality. For Process and Tools I find that ownership of Process and Tool is an area that is different every time I see it in most project teams or organisations. I've seen it evident in small teams being owned by individuals who are good at learning details of specific packages and how they work. They do this as a part time job, being a mentor and toolsmith besides doing their normal role of developing, testing or whatever. This is good and how small teams work anyway. It's all about who you have on the team, how best you share the load and help each other. Use the best skills of the people to the best advantage. On larger teams where ownership tends to be shared by teams of people, I've seen Process owned by Architecture. I've seen process owned by Quality management. I've seen process owned by Project management. In many cases Configuration management actually tends to run the many of the process and tools. The reason this becomes frustrating is because I often go into projects as a consultant to help them define their Processes and Tools, and find that I am not given admin rights to R&D on Tool configurations, or change existing tools attributes, etc. In large projects, often only the Helpdesk get enough rights to configure many of the tools used by the developers. Typically they don't even know how to install them let alone configure them correctly. By this I don't mean CM tools, fortunately build and CM is very close to development so managers realise they need to employ the right people deal with these issues and give them the correct admin level rights. It's more the Requirements management, Change management, UML Modelling or Test tools that fall into this category. By and large I find this not very well defined and thought out in many large teams. The RUP has made an excellent start at describing this by defining an Environment Discipline, which has the roles of a Process Engineer, Tool-smith and Systems Admin. But it does not seem to get into much detail when it comes to larger organisations where Production/Operations tend to own and want to make highly secure, all environments including the Development environment (to the point where Developers can't even make any changes) How has your team dealt with this problem or overcome it in some well structured way? To keep it in context let us know how large your team is. I have some thoughts to share on how this could be organised if you are having similar problems. Charles Edwards has been involved with software development for 22 years. He is a contributing editor for CM Crossroads and an independent consultant who performs RUP implementation for organizations that recognize the need to improve their software development process. He works with and contributes to the www.processwave.net web site for process engineers. You can reach Mr. Charles Edwards by email at charles.edwards@processwave.com
Set as favorite
Bookmark
Email this
Hits: 4934 Trackback(0)Comments (0)
|
| Last Updated on Tuesday, 24 January 2006 03:21 |
TrackBack URI for this entry
Subscribe to this comment's feed