The Alibre Design Development Cycle

I spent some time with Ashok Srinivasan, Alibre’s Vice President of Development, to know more about how Alibre goes about developing its product. Before joining Alibre, Ashok worked on the development teams of a number of MCAD systems including Solid Edge and Unigraphics, now NX.

Deelip: Many people have been wondering what kind of a company Alibre is? I mean, is it a tiny outfit that outsources all development to some place like Russia or India. Stuff like that.

Ashok: (Laughs) Actually it is quite the contrary. We are all here in Dallas. Nothing is outsourced which is probably an exception to most companies which do a lot of outsourcing, particularly to India. We were at one point outsourcing to a couple of Indian companies. But since the last three or four years we have a core development team right here. We really don’t feel the need to do any outsourcing, at least at this juncture. The entire Alibre product line is developed 100% here in this office.

Deelip: Can you tell me more about your development cycle?

Ashok: Sure. Actually I have a document which explains our development cycle in brief. As you can see the cycle starts with Marketing getting feedback from a variety of sources which include our web site, our user forums, VAR meeting and conferences that we have periodically, direct customer meetings. Actually our VAR channel is pretty active. We support around 15 languages and all the localization is done by them.

Our add-on partners give feedback to our development and QA teams regarding what new API’s they want to see in the next release. Then there are a series of meetings and discussion between the Marketing, Development and QA which result in detailed product specifications. Once the specs are drawn up the next step is creating of a project plan from which QA goes ahead and starts writing test plans. These are actually a bunch of documents, one for each item in the project plan which specify what to test, some up with what-if scenarios, etc. All this happens even before a single line of code is written by the development team. Then Development start writing code to implement the features in the project plan. Once features start getting implemented, builds are generated. Then based on the project plan and the test plan QA starts testing the builds and start recording defects or bugs. This is actually a cycle that goes on till the features are completed. This is an important milestone in the cycle, something that we call “Feature Complete”.

At this point, we have accumulated a pile of defects in Bugzilla, our bug management system. Thereafter we move to the Code Stabilization stage wherein Development and QA basically lives off Bugzilla.

Deelip: So at this stage I guess you do not work on any new functionality.

Ashok: Correct. At this point, anything new goes into the next cycle, unless it is absolutely required to have in in this cycle. So now the code gets modified by Development as the bugs are taken care of. QA goes and verifies them, checks for regression and updates the Bugzilla database.

Deelip: Do you do automated testing as well?

Ashok: Yes we do. Actually we are in the process of beefing it up even further. We have a collaborative project going on with the University of Texas at Dallas in which graduate students are enhancing out automated test tool. Obviously not all testing can be automated and some needs to be done manually by QA.

Usually these are the longest phases in the cycle. But that also depends upon the type of release – whether it is a 6 month cycle or an 8 month cycle.

Deelip: I noticed that you are calling the next version 2011. So are you moving to a year long release cycle?

Ashok: Yes, this time its going to be a one year release cycle and that is direction that we are taking. But then sometimes we have a intermediate dot release like we just had a V12.1.

After the Code Stabilization stage we have an extensive Beta Testing stage wherein Marketing becomes the front face of the operation. Customers sign up for beta testing and need to sign an NDA after which an installer is made available to them. We make our Bugzilla tool available to them as well and they start entering bugs which gets processed by our QA team which makes it a regular bug after getting all the information in place for the Development team to take action.

So after a lot of beta testing is done, Marketing takes a series of polls of the beta testers. When we reach a point when a majority of customers feel that the product is good, its stable and ready for release we come up with a Release Candidate but which is not yet released to the public. We really do not formally shut down the beta testing. It carries on but the builds are going to come out less frequently.

Also at this point we try and avoid major code changes because if we get too adventurous, we may slip in a bug that we may not catch before final release. So we are very careful with what we change and the focus at this stage moves on to Endurance Testing where we get people from customer support, marketing, QA and some in development depending upon who is available, to come in and carry out intense work flow testing on stuff like large assemblies. The idea is to hit the product with whatever we got and see how long before it breaks and the measure it. For example the time between aborts is an important metric. Then we compare these metrics with the values of previous releases and we get a sense of when the Release Candidate is ready to be released to the public.

We then let the Release Candidate simmer out for a couple of weeks and let users play with it. Then before the final release we have a short stage called Pre-Release QA which involves QA installing and testing the product on different operating systems and service packs.

Deelip: I really appreciate you disclosing all this. I am sure many of my readers will find it interesting. Another thing. When a user reports a bug or creates an incident, does he get automatically notified when that particular problem has been fixed.

Ashok: Yes, all that is handled in SalesForce.com. If you look at any incident logged in at SalesForce.com you will see the entire history of that incident and emails automatically generated and sent to the customer and the responses of the customer. This information is also available to the customer and he is able to track the status of the problem that is bothering him.