Role definitions in software engineering

[Claes Svensson]

Yet again, I am involved in a process to define the roles and
responsibilities of our team. This time, the team is focused on
Product Development and typical roles include Software Engineer,
Software Architect, Technical Writer, Test Leader etc...

This must be a reinvention of the wheel! Does anyone know of
standards, guidelines or templates that defines (preferably concrete)
typical such roles that we can use or refine for our purpose?

Sofar, I have not been able to find anything specific document within
RUP. I have also examined the SEI Team Software Process but failed to
find concrete suggestions. Anyh ideas?

Thanks in advance,
Claes

[Gerold Keefer]

there is a role definition in the microsoft solution
framework. IBMs work book driven approach has
the following roles:
-customer
-planner
-project manager
-team leader
-architect
-analyst
-designer
-domain expert
-developer
-information developer
-human factors engineer
-tester
-librarian

[s b e c k e r _ n o s p a m@nexbridge_nospam.com Randall S. Becker]

I'm actually surprised that came out of IBMs work book. Those sound more
like jobs. Roles are very different, in my contact with IBMs process
definition practices. They are much more specific to tasks and skills pairs.
The idea being that an individual fills more than one role in his or her
job, but only one role in the execution of a given process. I think these
definitions are nowhere near granular enough for process analysis. Maybe I'm
just looking in the wrong book ;-)

Claes, you need to ask yourself whether you are looking to define jobs or
processes. If jobs, then the list is a Gerold's list is a good starting
place. If processes, you'll have to take a long look at your own company.
FWIW, defining roles/tasks/skills is one of the longest parts of detailed
process analysis. Just to take an example, in a CMM Level 2 software
development company, you'll see roles like SCM Manager, SCM User, SCM
Librarian, C++ Designer, C++ Developer, C++ Inspector, VB Developer, etc.,
even if these are only filled by two jobs (team leader, developer - you pick
which goes to which in your company. I can't do that for you ;-) ). It's not
something easily done on a weekend. One of my clients spent six months doing
in in a division of under one hundred people.

Randall

"Gerold Keefer" <gke...@avoca-vsm.com> wrote in message
news:3C52892F...@avoca-vsm.com...

[xpyttl]

Randall makes some good points about process.

It really isn't about the roles so much as it is the work process and
methodology, and these tend to be somewhat unique to the organization. This
doesn't mean that you shouldn't understand what other organizations have
made successful and learn from them, but recognize that your particular
organization has a different culture, values and objectives than any other.

The only thing that may be a little unique is that there are some roles in
software engineering that need to be pretty separate. Testers and
developers need to be separate, the SQA function needs to stand off, and
tecchies rarely make good managers and vice versa.

Understand where your work process fits in with the rest of the
organization, blow that down to a detailed (and complete!) methodology, and
at that point, the various roles and their responsibilities ought to be
evident.

And a word about completeness of the methodology. When we tecchies talk
about methodology, we are often fixating on the grody details. The
important stuff is at a higher level - how the project is arranged, managed,
budgeted, etc. The successful methodology needs to marry all these
dimensions and articulate them in some detail.

This can be a real challenge if the methodology isn't driven top down. A
successful methodology takes a lot of power away from managers. Look at
CMM. At level 2, a lot of it is about giving the development team (software
engineering group in CMM jargon) virtual veto power over most management
decisions. There is a recognition that a methodology won't be successful
unless the development team can say no - no we won't do it for that budget,
no we won't get it out 3 weeks sooner, no we won't add that feature at the
last minute. Developers can't push this sort of change from the bottom up.
But to be successful, a methodology needs to clearly articulate how these
things are done, and who does what and under what circumstances.

..

"Randall S. Becker" <r s b e c k e r _ n o s p a m@n e x b r i d g e _n o s
p a m . c o m> wrote in message news:C8z48.15962$eL....@news1.bloor.is...

[Claes Svensson]

Thanks for your responses. To answer Randall's question, I am looking
for process role descriptions - ie several roles can be filled by the
same person. I found a few suggestions in Gerold's reference to the
Microsoft Solution Framework. Unfortunatetly, I was unable to find
something about the IBM work book driven approach mentioned. CMM seems
to define what needs to be done, but has few suggestions on how it can
be done (eg the concrete role template samples I am looking for to aid
with inspiration and speed up the definition process).

Anyway, thanks again for your feedback!

Regards,
Claes

[Nicolai Czempin]

"Claes Svensson" <till...@hotmail.com> wrote in message
news:94550888.02013...@posting.google.com...

To get started, take a look at "Introduction to the Team Software Process"
by Watts Humphrey. Some of the TSP papers on www.sei.cmu.edu mention
additional roles, but don't give the same kind of detail that the book has.
While the book is meant for students and/or small teams, it gives very
detailed role descriptions, which seems to be what you're after. The roles
in the book also seem fairly orthogonal (or, to be more precise, it seems
that the workload of actually taking on more than one role would be too much
for any one person), but nothing's keeping you from adapting them to your
needs.
I've been waiting for the "big one" (i. e. not just the introduction) for a
while now, but I'm not holding my breath...