Operational Quality of Release
IT Operational Quality of Release - OQR
Needs of OQR, History
The needs for calculating Release/Development Change Quality occurs after implementing new development process in the company and moving from lean management to Agile due to decreasing quality of product, i.e. potential shippable product in the beginning of transition which is naturally due to following facts:
* Development Knowledge transferring throughout all agile teams, required time and efforts, so the goals is all developers should have sufficient knowledge about all parts of the product(s), services,
* Depend on the quality of the Development, but usually taking average(each agile team have from junior to senior) product should have strong
:1. Strong architectural Core, Defined libraries and main usage rules
:2. Identified Maintainability areas and the rules
:3. Agreed non-functional requirements(improvement of performance, reliability, scalability, security, etc.)
So, in order to analyze and measure the final quality of the Release,Hot-Fix, or any Change(according to Change Management)
there is designed very simple condition which shows the Operational Quality of Release(OQR).
Calculation of IT Operational Quality of Release - OQR
We should take all tickets which have been opened after release N, with potential root cause as a release/hot-fix for the particular incidents/problems,
than calculating Operational Quality of Release (OQR)
: Ic(N)(Incidents coefficient) = 1(here is 1 because if incident occurs twice this because problem) x [ the efforts (man/hours) spent to resolve it ] x
: Pc(N)(Problems coefficient) = x [ the efforts (man/hours) spent to resolve it ] x
OQR(N) Ic(N) + Pc(N)===
OQR improvement measurment
For measuring improvement we simply need to compare OQR coefficients after 2 release.
OQR(N) = Ic(N) + Pc(N) - for Release N
OQR(N2) = Ic(N2) + Pc(N2) - for Release N2
OQR(N) > OQR(N2) - The Quality of Release N2 have been improved
Needs of OQR, History
The needs for calculating Release/Development Change Quality occurs after implementing new development process in the company and moving from lean management to Agile due to decreasing quality of product, i.e. potential shippable product in the beginning of transition which is naturally due to following facts:
* Development Knowledge transferring throughout all agile teams, required time and efforts, so the goals is all developers should have sufficient knowledge about all parts of the product(s), services,
* Depend on the quality of the Development, but usually taking average(each agile team have from junior to senior) product should have strong
:1. Strong architectural Core, Defined libraries and main usage rules
:2. Identified Maintainability areas and the rules
:3. Agreed non-functional requirements(improvement of performance, reliability, scalability, security, etc.)
So, in order to analyze and measure the final quality of the Release,Hot-Fix, or any Change(according to Change Management)
there is designed very simple condition which shows the Operational Quality of Release(OQR).
Calculation of IT Operational Quality of Release - OQR
We should take all tickets which have been opened after release N, with potential root cause as a release/hot-fix for the particular incidents/problems,
than calculating Operational Quality of Release (OQR)
: Ic(N)(Incidents coefficient) = 1(here is 1 because if incident occurs twice this because problem) x [ the efforts (man/hours) spent to resolve it ] x
: Pc(N)(Problems coefficient) = x [ the efforts (man/hours) spent to resolve it ] x
OQR(N) Ic(N) + Pc(N)===
OQR improvement measurment
For measuring improvement we simply need to compare OQR coefficients after 2 release.
OQR(N) = Ic(N) + Pc(N) - for Release N
OQR(N2) = Ic(N2) + Pc(N2) - for Release N2
OQR(N) > OQR(N2) - The Quality of Release N2 have been improved
Comments