 |
Il forum sulla Qualità di QualitiAmo Torna all'homepage di QualitiAmo
|
Precedente :: Successivo |
Autore |
Messaggio |
QualitiAmo - Stefania Moderatore

Registrato: 16/09/07 18:37 Messaggi: 26638
|
Inviato: Gio Lug 09, 2009 2:41 pm Oggetto: Basare un sistema sui processi |
|
|
Su Quality Assurance potete leggere un articolo dal titolo: "Steps for Baselining Processes".
Questa è la versione tradotta in italiano con il traduttore automatico di Google.
There are many different steps that organizations follow in benchmarking. However, most baselining processes have these four steps:
1. Develop a clearly defined baseline in your organization: This means that all of the attributes involved in your baseline are defined. In our example of defects per lines of code, clearly defining what is meant by defect and a line of code would meet the objective of this step.
2. Identify the organizations you desire to baseline against: Many factors come into this decision, such as do you want to benchmark within your industry, do you want to benchmark what you believe are leading organizations, do you want to benchmark an organization that uses the same tools that are used in your organization, and do you want to benchmark against organizations with a similar culture.
3. Compare baseline calculations: Compare how your baseline is calculated versus the baseline calculation in the company you want to benchmark against. Benchmarking is only effective when you benchmark against an organization who has calculated their baseline using approximately the same approach that your organization used to calculate the baseline.
4. Identify the cause of baseline variance in the organization you benchmarked against: When you find a variance between the baseline calculation in your company and the baseline calculation in the organization you are benchmarking against, you need to identify the cause of variance. For example, if your organization was producing 20 defects per thousand lines of code, and you benchmarked against an organization that only had 10 defects per thousand lines of code you would want to identify the cause of the difference. If you cannot identify the cause of difference, there is little value in benchmarking. Let us assume that the company you benchmarked against had a different process for requirement definition than your organization. For example, assume they use JAD (joint application development) and you did not. Learning this, you may choose to adopt JAD in your organization as a means for reducing your developmental defect rates.
A less formal method for benchmarking is to visit other organizations. This will provide the quality professionals with these benefits:
1. The cost and effort to develop new and innovative quality approaches within IT is cost-prohibitive for most companies. Learn from others and don’t “reinvent the wheel”.
2. Comparing quality programs to those in other companies can identify gaps in current processes and lead to obtaining more effective quality practices.
3. Interfacing periodically with other quality individuals is good for professional development. Those colleagues will not exist internally unless the company is large. |
|
Top |
|
 |
|
 |
|
|
Non puoi inserire nuovi argomenti Non puoi rispondere a nessun argomento Non puoi modificare i tuoi messaggi Non puoi cancellare i tuoi messaggi Non puoi votare nei sondaggi
|
|