Conquering by Inaction

It was apt that I should come across this nugget of wisdom- “Conquer by Inaction” while¬†managing a project of which I just could not understand the technical details. On the other hand, the team that I had was highly mature and usually they drive me (the project manager), rather than the other way around.¬†

Conquer by Inaction

(or The Tao of Project Management)

Continue reading

Posted in Project Management | 1 Comment

Estimating Test Effort

The best way for a ball park estimate for the testing effort is relatively simple- just take one third of the effort required for the complete development of an application. However, sometimes this total effort may not be available, for example, if the development and test vendors are different or the development and testing practices are not integrated. In that situation, the testing team needs do an independent sizing of the application, using a technique like Function Points and then computing the number of test cases.

One of the best known techniques are the ones provided by Caper Jones and David Longstreet. According to Caper Jones,

Total number of test cases =  (Count of Function Points) raised to the power of 1.2.

David Longstreet provides a similar formula for computing the number of UAT test cases:

Total number of UAT test cases, which is = 1.2 x (Count of Function Points).

As with every such empirical model, one has to use them as a guide and evaluate them with real data. In my own experiences with web based (Microsoft dot net platform), the numbers are slightly different, and approximate better as follows:

Total Number of test cases = (Function Point Count) raised to the power 1.05
Total number of UAT test cases = 1.35 x (Function Point Count)

Once the count of the test cases has been found, apply the productivity factors for test case authoring and test case execution to arrive at the total testing effort.

The following is the data for a 3000 function point project on which the above formula have been tweaked.

Unit Test Cases                 : 13,000
Integration Test Cases       : 5,000
System Test Cases            : 13,000
UAT:                                : 4,100
Total                                : 35,100

References: Estimating Test Cases and Defects by David Longstreet
Software Estimation Rules of Thumb by Caper Jones (pdf)

Posted in Planning, Software Metrics, Tips and Tricks | Tagged | Leave a comment

Managing by Exception

As a techie who grew through the ranks, starting as a programmer to project lead to project manager and then a program manager, I have had no management training as such. It came naturally, the learning happened either by burning one’s own hands or by the guidance of a knowledgeable manager.

Moving from project lead to project manager was relatively seamless. There were a few changes though. The most significant was the focus I had to bring in laying down project specific processes and ensuring compliance. I also became less hands on as far as programming and architecting was concerned. My reliance on metrics increased. Unknowingly, I also carried forward the habit of micro managing the project, keeping an eye on each and every team member and their activities. This included spending time with individual team members at their desks while they worked, sometimes helping them with debugging their programs. An interesting aside was that I realized while one may grow out of the habit of programming, one almost never loses the ability to debug programs. 
Continue reading

Posted in Project Management | 2 Comments

Software Development is…

Results of a fun poll that I conducted over at Linkedin.

Posted in Software Engineering | Leave a comment

Reverse Engineering for Software Systems

In its most rudimentary form, reverse engineering can be defined as “going backwards through the development cycle”. It has  its origins in espionage when rival countries would break apart a product from the opposite country and figure out its mechanism in order to build a similar product. Wikipedia defines reverse engineering as:

Reverse engineering (RE) is the process of discovering the technological principles of a device, object or system through analysis of its structure, function and operation. It often involves taking something (e.g., a mechanical device, electronic component, or software program) apart and analyzing its workings in detail to be used in maintenance, or to try to make a new device or program that does the same thing without utilizing any physical part of the original.

When I started my career at an Indian public sector telecommunication company, one of the projects that I worked on was a versatile multiplexer. At that time the Indian market was still closed and technological know how from the more developed countries was limited. We did not even have a sample of the multiplexer, just a technical brochure with a feature list of the product. I am not sure if that can be called reverse engineering, but our team did manage to build a working product. By the time it hit the market, I had left the company so I do not know how well it fared. However, I had other brushes with reverse engineering, both successful and not-so-successful.

Continue reading

Posted in Software Engineering, Tips and Tricks | Tagged | 2 Comments

Software Metrics- IV

I have often been asked to take charge of projects that are in deep trouble. I am no longer surprised that almost universally, the stage when a project is generally acknowledged to be in trouble is during the late stages of testing and rolling out the first release. Never does it happen during the requirements and design stages at all- for reasons that are obvious- there is nothing tangible that the end users actually see during  these phases except perhaps a stream of documents.

While I will write a set of posts on my experience in turning around projects, I would like to illustrate here how metrics can be used to analyze the depth of the problem and also provide a very quick plan for stabilizing the project very quickly.

A simple defect analysis based on the cause of the defects can shed light on what are the key areas that need to be addressed.

In the following diagram from an actual web- based application development project, for example, it is very clear that the process for regression testing needs to be improved as defects because of its inefficiency are 22%. It is also clear that the substantial numbers of defects (23%) are on account of requirements (missed + ambiguous) and another 17% of the defects pertain to insufficient test cases. Addressing these three areas would have an immediate impact on the quality of testing. Given cost and schedule constraints, it may not be required to address all the causes and instead concentrate only on these three factors that address 72% of the defects.

Posted in Software Metrics, Uncategorized | Tagged | 2 Comments

IT- The Future is Here

This article was written 15 years ago when internet services officially started in India. I had expressed a number of fears in this some of which have been happily proved incorrect. However, I find it interesting that there are almost no fundamentally new technological breakthroughs that have come around since the article was written. Some of the concerns raised in the article still hold, particularly its conclusion.

Trivia: The original article was typed on a PC- XT machine using Word Star 7.

I had used email for just over a month then using a corporate account and the browser I was then using were Mosaic and Gopher !

Anyone remember using these?

Read the full article here.

Posted in Uncategorized | Leave a comment