From Specification to Implementation (III)

Continuing with related post (From Specification to Implementation) I will described the last processes implementation in a public organization supported with RedMine.

The final photo (today, forward work will be done) consist on:

A set of processes:

• Project Planning (CMMI)
• Project Monitoring and Control (CMMI)
• Requirements Development (CMMI)
• Requirements Management (CMMI)
• Release Management (ISO 20.000)
• Defect Management 

A group of roles (RedMine roles):

• Sponsor
• Expert User
• Functional Director
• Project Manager
• Project Team 
• System Manager
• System Team

And several management elements (RedMine trackers):

• New Initiative
• Goal
• Project Plan
• Requirement
• Requirement Change
• Sprint
• Release
• Version
• Defect
• Request for Change (development)

With these three group of elements the new methodology is ready to be used. The relationship between then is described in the following picture:

Further related documentation have been generated: templates, reports, user manual, change management... and everything is supported with wiki and document functionality.

From specification to implementation

Processes specification is a hard work that many times finish with a theoretical approach, high amounts of money spent and low or null use in the organization.

Main reasons for these situations are:

• Processes goals is aligned to organization goals but they are not supported by end users, main affected of the new way of work that implies a new methodology.
• Methodologies approach are so wide and nonspecific, they could not be implemented by default, but need a customization for each organization.

For me the reasons why a methodology does not fit in a organization is due to:

• People who has to work with it are not involve in processes specification.
• Processes definition is supported as documents, but not implemented in any tool.
• Managed elements defined by the methodology are not valuable, they only suppose more work, but not simplified work and reporting.

In order to avoid these situations and minimize methodology pitfalls I recommend you to start this work with the following partners:

• A short list of goals: few processes in a organization with a list of identifying problems and a set of metrics that evidence how to improve.
• A short list of users: process owner and end user process. They have to be able to define their requirements and validate your work.
• A corporate tool to implement, document and support the processes. This tool will be the base of any organization work.

From Classical to Flexible Testing

From Classical Testing to Flexible Testing

From a long time ago Quality Assurance Department were involve in several works: 

• methodology specification, 
• process definition, 
• process implementation, and 
• quality reviews. 

These functions are being enhanced and improved and different teams and responsibilities are being defined.

Testing is a new department in business with a separated responsibilities focus on product verification and validation, integrated in product specifications, product schedule and involve with product goals and success.

This new approximation implies a new paradigm which require new techniques and process focused on succeed.

Differences of a flexible approach. Project Success

In a context where project success is a matter of IT business head, quality is a way to guarantee project success, where all processes are focussed on quality, productivity and excellence. Quality is not an external matter in product generation, but is implicit in all activities and roles.

From this approach, testing could not be a set of process executions oriented to defect detection and request new deliveries, but focus is detect prevention, expecting that with only one delivery software will be accepted and promoted to implementation.

In order to reach this goals, we should:

• Publish our methodology and any automated tool that could simplified verification, in order to allow any developer team auto-evaluated every day and previous any delivery.
• Training service in verification and in any specific consideration that should be know by any part in development and system specification.
• Defect tracking system, in order to communicate development team and testing team.
• Flexibility model: what happens in case of a blocking defect? Should testing ask for a  new delivery? Answer is always yes, but the way we allow this new delivery should be different for certain situations.

Flexibility model

This model allow a conversation between testing office and development office in order to reduce number of deliveries, and makes all one group with one goal: project success.

If we have a delivery in which everything works but there is a dependency no satisfied we can:

• Ask for a new delivery (with all the cost associated with it)
• Allow several correction to each service (for example compilation service), which will be more cheaper and project schedule will be better.

Flexibility model defines for testing office: which services will be flexible, the amount of corrections that will be allowed and the maximum time that testing will wait for them.

With it project quality is not at risk, cost could be reduced and schedule enhanced, but all teams have a must that is project success.