Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

i'm looking for metrics/standards/normatives to evaluate a given "Software Development Process". I'm NOT looking to evaluate the SOFTWARE itself (trough SQUARE and such), i'm trying to evaluate software development PROCESS.

So, my question is if you could give me some pointers to find this standard, considering that "evaluation objetives" would be documentation quality, how good is the customer relation, how efective is the process, etc. Very much like a ISO 9000, and like CMMI on a sense, but much lightweight and concrete and process oriented, not company oriented.

Please help, i'm trying to stablish the advantages of our development process as formal as i can.

share|improve this question

migrated from Mar 9 '11 at 17:17

This question came from our site for professional and enthusiast programmers.

To the best of my knowledge, there aren't any gold standards for methodologies for software development. What seems to happen is endless waves of snake oil salesmen promoting something which has a kernel of truth from twenty to forty years earlier. – Paul Nathan Mar 9 '11 at 20:41
Thanks, altough it can be usefull for me to get feedback on standard/common stages of the process, it is not necesary to consider a single standard or normative set of rules. – Ron-Damon Mar 9 '11 at 20:57

You are as likely to encounter a meta-process to qualify processes as you are likely to create a perpetual motion system to generate energy.

Process is a reaction to prior stupidity

In other words a process is the natural organisation of individuals to function as a team towards a common goal.

Now, this, as you have stated, does not mean the process is "good". The difficult part here is to evaluate what constitutes a good process. Towards this end everyone will have a different opinion each shedding light on a different aspect or trying to eliminate a specific bottleneck.

A good process is one that ensure a set of goals are attained. To determine what a good process for you would be like you have to first determine what aspects you wish to optimize and what aspects can be compromised towards this goal. The purist would attempt to create the ideal process that satisfies all possible goals but this is a false goal as many are contradictory by nature and cannot be reconciled. Therefore compromises are not only desirable but a necessity.

Possible goals for software production are :

  • Product Quality
  • Deterministic Defect Control
  • Code Quality
  • Optimizing team member interactions
  • Traceability
  • Velocity
  • Maintainability
  • Usability

The list goes on. Once you know what you want to optimize you can design a means to ensure these goals are met. To help you many processes have been created and used that address one or more of these but always to the detriment of another. A good process will identify what will be optimized AND what will be detrimentally affected. An excellent process will be able to quantify them.

For example Cleanroom Software Engineering will yields guaranteed levels of defects and closely control changes made to a system. BUT the costs of producing zero defects software will be prohibitive all but the most extreme situations where interventions when deployed are extremely difficult or impossible (deep space probes come to mind).

Some process will emphasize documentation, others will ensure regular incremental deliveries.

Process is Software

My best advice to this problem is to think of the process much as you think of a software system. Both attempt to solve a problem through algorithmic solutions. Just like software you need to create a model of the different actors and systems. You need to identify what the process must produce. Just like software you will need means to measure how this process is performing and carefully craft measure points in your system. And just like software you need to constantly analyse and evaluate these measurements keeping in mind that all forms of measurements will yield an incomplete picture of the whole and must constantly be adjusted and thus must never taken at face value.

Your biggest challenge is the fact that your actors are not deterministic algorithms or services but humans with different experience, educations and views as to what constitutes a good software.

ISO quality meta-processes attempt just that but to achieve this properly they are made voluntarily vague and incomplete. Their goal is to ensure your process contains enough information and measurement points to evolve with time towards your chosen goals.

When creating CMMI Carnegie Mellon has chosen a specific set of goals and created a process that attempt to achieve them.

best of luck in your findings, I would greatly appreciate if you could share back to this question what you have found to address your problem.

share|improve this answer
Thanks man, you have been very helpfull. I will answer back when i have enough development of this issue. – Ron-Damon Mar 14 '11 at 17:01

Developers are People

The first thing I assume you would want to measure of a process is how well it works for the people using it, and how well adopted it is in reality. I've seen organizations in which the developers loathed the red-tape required to write code so they would circumvent the process as much as they could.

Every Process Produces Results

Any process should be pragmatic - and produce results. Metrics I consider for my dev team are:

  • How accurate are estimates
  • How much code is being written per day
  • Is the application being developed in a logical sequence
  • Is work being redone
  • Is there over-communication or a lack of communication?
  • How often does work need to be redone - (not bugs) are things developed incorrectly or miss requirements altogether.

I might suggest a book called "The Mythical Man Month" to shine some light on how to evaluate software processes without sniffing the glue of (or starting a religious war) agile, extreme programming, waterfall, etc...

Although this may not directly answer your question I hope this at least philosophically helps.

share|improve this answer
Some good ideas here, but: 1) Lines of Code is only a good metric if it's lines of code eliminated, and 2) Work being redone is part of the process; it even has a name: refactoring. – Robert Harvey Mar 10 '11 at 4:16
Agreed, lines of code is no metric, I guess I wasn't describing lines of code but in my head "how many tasks" are being accomplished. – Ben DeMott Mar 10 '11 at 4:22
Yes, it seems i will have yo choose/create a set of metrics that would work with process evaluation. But i'll still keep trying to at least base those on other methodologies, but just not standarized. – Ron-Damon Mar 14 '11 at 17:06

To evaluate your current development process in order to find ways to improve it, I would look for the various tasks that are currently being done that involve a lot of manual work and a lot of back-and-forth communication that make those tasks very tedious and time-consuming.

Anything you can do to improve communication between the various people involved in the process and shorten the amount of time taken to complete various tasks in the process will certainly improve the overall process. Communication is key and is usually the weakest part of the overall process. Documenting the overall process and the information required to complete it would be a very good thing to have, especially if it is accessible to everyone involved.

It is important to discover all of the various tasks that make up the current process and to speak with those involved in it and get their feedback. This way the process as a whole can be better analyzed and ideas for improvement can begin to be made. There is no cookie-cutter solution, you must develop what works best for you based on what you need to accomplish.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.