Saturday, February 2, 2008

Have you been in situations were you have to decide if the software has to be changed or the process? And what do you do?Most of the times I saw in projects that both did not changed at all. The so called "work around" are defined. Only they are often poorly managed.

You have several types of projects. On one side there is the newly build project. On the other side the fully standard application implementation. And off course all variants in between.I think there is at least one similarity between these projects. At a certain point you have to decide whether to change the code or the process. Even if you accept the workaround you have to decide after a certain period of time if you change the code or process. In the first situation the workaround is no longer necessary. In the last situation it becomes standard procedure.

On a quest for searching for figures what changes in procedures cost I came to this article:

Quote: And you probably don't believe this either, but it really is easier to change your business process rather than your software. Believe me, because I do hate to say, "I told you so."

In this case for us testers there is still a job to do. Though the code doesn't change, you still have to verify that the software indeed matches the business process. The focus will lie on the User Acceptance test.

If the code changes you also have to test the impact of that change onto the system. And the impact of the change on processes. My experience is that certain changes are found in a late stadium of the project. This will make impact analysis mostly focusing on the impact of the system under test rather then measuring the impact on business processes. This lead me to the following article.

Quote: In a fast changing market environment the task Business. Business of reducing the downtime for change management of business processes has high importance. Ensuring that IT reflects the updated business requirement is an important task related to change management in software development.

In that article they defined a process how to manage process changes into Software changes. If I interpreted it correctly they translated the process changes in a formal language and made relationships towards code. I think in according to that paper it is already easier to tell what impact changes in processes have on code. This might help us identify the areas to re-test.

Software Process Improvement from PelicanWeb gives a graphical overview how to measure holes when new requirements are introduced and what the impact is on the project.

Measuring holes and creating new procedures makes me think that we IT-people always tending to re-invent the wheel. Why should be do it when there is more information available related to organizations. In previous lessons I followed related to Organizational Changes I was confronted with a model as described in the article below. This model is written towards organizational changes. Why not use it on detailed level and combine it with the impact towards systems? Perhaps you, reader, have a suggestion how to start?

Quote: The Matrix of Change can help managers identify critical interactions among processes

I know that there are quite good applications to monitor changes in systems, for example cc Harvest or PVCS Dimensions. I'm not sure if they have the capability to monitor changes in processes and procedures.

Perhaps we need another document as well as test basis. A map on how the software is related to requirements and also business processes. It might help to verify if RFC's are judged correctly according their impact. It also might help to identify the impact of changes based on the relationship towards systems. And also when a work around is accepted, what the impact on processes would be. Based on the impact on the process the life cycle of work-around could be defined and also monitored.

Perhaps in Agile projects such a matrix can help identifying the content of the next iteration.

What do you think? Is there already such a framework? Can we use it? Do we need it?

AS IS

The postings on this blog are provided "AS IS" by Jeroen Rosink with no warranties. Most of the post will be thoughts, and thoughts can change over the time. I would appreciate when you leave a comment to sharpen my ideas and thoughts.