Issue/Defect management in Onsite-Offshore delivery model

An SDLC project when executed with distributed teams needs attention in many areas involving processes in addition to technologies. The maturity of the processes and the sincerity of the team following them, goes a long way in deciding the fate of the project. One such area of concern for almost all projects is the management of Issues (till testing phase) and defects (there after).

Issues can be of any type, ie it may be requests for clarifications of any requirements, setting up of customer specified environments or any other thing that needs a clarification from a geographically distributed team. As the number of issues grow, it necessitates a consolidation, tracking mechanism and process for followup & closure. Traditionally people resort to xls sheets. They create an xls sheet (mostly issue-log.xls ) with numbers of columns varying according to the experience of the person creating the sheet, consolidate the issues in it and put a process in place for shuttling the xls sheet between onsite and offshore in a specified frequency with updates happenning on either side.

There are a lot of problems with this approach. Namely,

>1> It needs single point of contact on either side. It creates a dependency on those persons. God forbid, if any one of them falls sick, your project falls sick.

2> More often than not the team runs into version issues of the sheet, ie different teams working with different versions of the sheet. Some people go to the extent of attaching version numbers with each xls, only making matters worse.

>3> Managing the file becomes difficult once the number of issues grow beyond 100s.

>4> A lot of issues need discussions. It can happen over phone or in a mail chain. In either case the information related to the issue gets scattered into various media. So the xls sheet alone doesn’t provide complete picture on the issue at any time.

>5> At least one resource each side is wasted for handling the file. If you don’t dedicate a person to handle the issue log on each side then you are bound to get into a version issue, loss of issues or orphan issues.

>6> Situation is much more complicated if you have to manage defects. Because defects usually have a work-flow and need to exchange multiple hands during its lifecycle. Using xls sheet to manage the life cycle is hell of a task.

If your issue/defect management is not correct, you are bound to fail to close many issues which only gets highlighted during UAT phase of the project and becomes a reason for spoiled relationship between you and your customer.

My experience says, these tasks should be automated through introduction of appropriate tools. There are quite a lot of commercial as well as open source tools in market today that help in issue and defect management. Commercial tools tend to become complicated in their effort to provide maximum features, thus increasing the learning curve and reducing the ease of use. We have used open source tools effectively for this purpose and they provide the bare minimum features required to do the task in hand effectively.

Few tools one can try to use are, JTrac, BugZilla etc.

Managing concurrent change with Eclipse and CVS

Many of the software projects developed today use distributed and collaborative development environments. Using geographically distributed team vendors are able to achieve ‘24/7 active’ development of their software. It has its own list of challenges and there are tools aplenty to address those challenges in both OSS and commercial category. Here we discuss one of such peculiar problem (i.e, managing concurrent changes to code base) and explain how Eclipse + CVS combination addresses it effectively.

Due to concurrent changes to the code and improper version control process (or lack of sincerity from developers) we almost always land up in ‘conflict’ situations and spend extra effort in resolving them. Below I discuss a process that helped me in a large development project while allowing me to just work with my development IDE. No extra tools required.

1. CVS Features for managing concurrent change:

CVS provides various sets of features to help the users manage concurrent change effectively. These features work hand-in-hand to help the team. Some of these features are:

• The “watch” feature: To utilize this feature the user explicitly expresses interest in change (edit/un-edit/commit) in a particular resource. CVS takes care of notifying the user whenever any user executes an operation of his interest on the resource viz. edit/un-edit (as explained below) and commit. This feature is not supported by the Eclipse’s VCM (Versioning and Configuration Management) modules’ CVS implementation as in Eclipse 2.1.

• The “edit” feature: Typically any resource that needs change can follow any of the following paths under CVS:

The straight path (I) from an unchanged resource to the new committed resource is a common way of using CVS.

The alternate paths (IIa and IIb) are also supported by CVS and provide another mechanism to manage concurrent change.

If every user religiously follows path II to issue a “cvs edit” before (s)he starts work on a resource and then issues a “cvs commit” or a “cvs unedit” when work is respectively finished or needs to be rolled back, then CVS can keep track of all current “editor(s)” of a resource.

This conversely gives any other user who wants to work on the same resource an opportunity to check with CVS as to the current “editor(s)” of the resource and take appropriate steps. So the modified path II now becomes,

2. The Eclipse Value-Add:

Eclipse goes a step further to help you achieve this. Under Eclipse, a project can be set to send automatic “cvs edit” commands to the CVS repository whenever a resource is changed / “edit”-ed by a user. All resources for such a project get checked-out as “read-only”. When an actual change is made to the file from within Eclipse, Eclipse switches off the read-only flag and send the “cvs edit” command to the repository.

The story doesn’t end there! Eclipse goes even further. If it so happens that the file being “edit”-ed already has registered editors, Eclipse gives you a “warning” stating who is currently changing the file!!

As such both the manual steps of Path II viz. checking the “editors” of the resource and issuing the “edit” command are automatically taken care-of by Eclipse. All you need to ensure is that you work under Eclipse and respect the warnings – that’s all!!

3. What You Need to Do

• Ensure that eclipse is setup to use edit and watch features.

• Make sure that all files are edited under Eclipse

• IFF (and that should not usually be necessary since Eclipse has editors for almost everything!) you do change anything outside Eclipse, make sure to send an explicit “cvs edit” command from Unix / WinCVS / Eclipse itself!

• When Eclipse warns, don’t ignore. Consult with the existing “editor”.

PS: Special thanks to Sumit Sachdev for his contributions to this article.

Version control in Agile development team

Today’s customers and vendors want Agile development practices for every  software project. Wish this could be applied as effectively to non-software projects as well.  Version control is an important activity of every software project and the success of a project largely depends on effectiveness of the version control process used during the project execution.Though it depends on the maturity and sincerity of the developers too but a successful version control is almost always backed by a strong configuration management “process”.

Here, i will explain the very general approach / process that applies to most of the projects. A tweak here n there is usually done to suit the specific environment. CVS and SVN are the tools of choice for agile development projects. I will not talk about the installation and setup for them. I will assume that its is setup and all developers have the code checked out into their local repositories. Following steps need to be followed religiously by all persons on daily basis to maintain a healthy version control system.

1. Do synchronization as the first task everyday morning. If the synchronization results in any “incoming” files, get the files into local machine. This ensures that you start with “latest” copies.
2. Work with the files you are interested.
3. Once you have finished working on a file, do clear any coding standard violations. Compile it and clear any compilation issues. Clear any compiler warnings.
4. Now you are ready to check-in code into CVS. do synchronization.
5. If the synchronization results in incoming files update your system with them. For conflicts, resolve the conflict thru the ‘manual’ merge process.
6. Compile the code and ensure it compiles clean.
7. Do synchronize again.
8. In most of the cases you should now only have outgoing files. In such a case commit those files into CVS with appropriate comments. Otherwise repeat the steps 5 to 8.

General Guidelines

1. Avoid using the “Override and Commit” and “Override and Update” commands unless you are an experienced developer.
2. Do synchronization multiple times in a day. This will keep you closer to latest code and reduce the need for code merge.
3. Do not keep modified code in your local machine. If the code is in a state to compile clean, try to commit it to CVS.
4. You should make it a habit to check-in all your code/docs into CVS before you leave office everyday.
5. Your code must compile clean before doing any check-in.
6. Check-in comments – comments should explain why a change was done. What changes were done can be found from the history, so it needs no mention.

The above process is manufactured out of my development experience. If you have faced any situation which you think applies to version control process in general, please share.