Software Process improvement & how it should be crafted -

“Process is King!” said the British, and probably many others, and they were mostly right. We would like to be able to give a solid framework of processes, that is mixed and fit the people, operation, business environment and development model we use in Engineering in order to be able to use the resources available for us, in the right way – most efficient and effective way.

The trick is getting the right balance between process, quality and quickness and build an operation that fits the parameters mentioned before.

Working in agile, would mean differently than working in v model environments. That means the software processes must be different - for example: unit tests are a necessity, unit level and integration level test automation are highly important, the path from requirements/user stories until solid code is generated is critical, etc.

If working in a v model, or regulated environment (medical, military, government, etc.), the software process would be different, and more emphasis would be given to well-documented processes, traceability, and objective evidences. That needs to be factored in.

Note: The Software process improvement and the Testing process improvement are similar in nature, and thus the evaluation, analysis and recommendation phases will be performed very similar to each other.

How do we support this -

We will typically evaluate the need based on the type of operational environment (regulated or not, etc.), perform a gap analysis to evaluate the current situation, present a report/presentation to major stakeholders, recommending areas and high level topics for improvement, and prioritize them for – effort and impact. For that we will use a SPI model as base, some elements of CMMi® where necessary, combining aspects for testing from some TPI related models, our own experience ones, or a mix – depending on the needs, size of operation, and business/engineering environment.

The next step would be to support and build an actionable work plan for improvement of the engineering group, taking into account the business release requirements, as well as the benefit of changes to be introduced to support that.

After the plan is approved, we shall support a process of changing/defining/adjusting processes, tools, procedures, measurements. Each of those, after defined/changed, will be piloted to see the teams can use it in the most effective way, and only after that it will be documented (if necessary). Probably be adjusted on the way, thus fitting the methodology to the field best practices of the project/company.

Following are related solutions you might find relevant for you as well.