Welcome to the world of Infosys Engineering! It is a half a billion plus organization that takes pride in shaping our engineering aspirations and dreams and bringing them to fruition. We provide engineering services and solutions across the lifecycle of our clients’ offerings, ranging from product ideation to realization and sustenance, that caters to a cross-section of industries - aerospace, automotive, medical devices, retail, telecommunications, hi tech, financial services, energy and utilities just to name a few major ones.

« October 2009 | Main | December 2009 »

November 25, 2009

Internationalization and the development life cycle

As a product company your team has come up with a brilliant concept which has tremendous marketing potential in your country. Your marketing survey shows that the concept will soon catch up with other countries across the globe and you can capture the overseas market too. The only catch is that the product will be required to be globalized before it is launched in the international markets. A global launch is still 5-6 months away, so what product strategy will you adopt? Develop the product in English and later when you have access to the global markets, think of internationalizing it or start developing an internationalized version of the product right from conceptualization stage so that you are ready to penetrate the global markets when the time comes? This is a question most product managers will face while developing a product.

The ideal time to start thinking about Internationalization or Localization of your product is at the conceptual stage of the product development life cycle. The product management has to be clear about their vision for the product. If the product is meant for international audiences, it is a good idea to plan for it earlier than later since it will definitely be more expensive to do the same thing later and you may also lose out on market share due to a delayed launch. Internationalization is often more important than localization in the development stage since localization will normally not involve code re-engineering whenever it is done. Think about a product which is not internationalized and you want to introduce multilingual support to it. Changes will have to be made in multiple layers in order to achieve this. These changes will be costly in terms of the time taken, bugs introduced and additional testing required. However if the product architecture had made the same provision at design time, things would have been much simpler and all the development team had to do was get the string resources translated in order to support a new language.

What does it take to internationalize your product right from requirements to design to development and finally testing? The requirements gathering team must understand the typical i18n requirements and they must evaluate the product requirements from an i18n perspective too. The design team must understand the typical i18n aspects and ensure that the product design takes care of all i18n issues along with the intended architecture and design. The development team should be experienced with making i18n related code changes and it is important that they understand the i18n best practices in order to avoid rework later. The development of the core components and internationalization must go hand in hand. Pseudo-localization testing must be planned for the product to identify potential localization issues. If these practices are followed, it is more or less assured that it will be easy to adapt the product to different regions or countries as and when required with minimum cost and time to market.

November 11, 2009

Effort estimation for a Globalization project

Effort estimation is the first step to undertaking any software project and a Globalization project is no different. Effort estimation for a product or application which needs to be Globalized follows more or less the same estimation principles as regular maintenance projects, yet there are no defined methods specifically for estimating the amount of I18N or L10N changes required. While working on the proposal for a Globalization project for one of our clients we were faced with the dilemma of adopting standard methodologies like SMC based estimation, FP based estimation etc or trying to create a hybrid and come up with our own estimation model which follows the same estimation principles but is more tailored for globalization projects. Finally we came up with a raw estimation model which was fine tuned over time and gave us estimates which were statistically inline with the results from other maintenance projects.

The first step to estimation is to understand the underlying product. Embarking on a project without complete information generally leads to disaster later. In the initial meetings with the client it is important to understand the current scope of the product. It will be useful to know the target geographies where the product is going to be sold, the current degree of internationalization if any, the platforms which need to be supported, the product architecture etc. Each requirement throws in more challenges in terms of estimation. The technical people involved in the estimation should have prior Globalization experience and understand the various I18N impact points in the code. They should be able to isolate code which needs I18N related changes with the rest of the code. Off course this is a very daunting task when the code base is huge, which is the typical scenario with a product; so we need tools and utilities which can find out all the impact points in the code. There are static analysis tools available which can do this to a certain degree. They can help in finding out the number of hard coded strings in the product, the number of non-Unicode API's and data types used etc and come out with reports which can be further analysed and used while estimation. At Infosys we use our in-house developed Internationalization tool which is rule based and helps in analysing code based on the specific set of rules that we set. This way the reports contain very relevant information which can be directly used in the estimation model.

At the time of estimation, it is important for the architect to decide on the encoding which will be supported by the product. This decision has a direct binding to the impact points in the code. In case the application has to support UTF-16, most of the API's and data types in a C++ application have to be replaced with their wide char equivalent, while if the application has to support UTF-8, only a handful of string related API's are impacted. The decision to use a particular encoding can prove to be very important since deciding to use a different encoding later at the implementation stage can prove to be very expensive and introduces risks in the quality and schedule of the project. Every encoding has its pros and cons and it must be well debated before going ahead with the decision. If there is database support in the product, the database layer should be analysed so that data that flows in and out of the database is in the required encoding. All internal and external interfaces of the application must be analysed so that the data flowing between modules or applications has an encoding which the communication layer can understand. The tools which help in estimation have a limited scope and the rest depends on the expertise of the person analysing the code and design documents.

The software estimation process breaks down the requirements into sub requirements which are made as granular as possible. At a very granular level if we know the number of API's or data types we need to change, we can roughly estimate the effort required to make those changes. If we know the third party tools the application interfaces with, we can estimate the effort required to internationalize the external interfaces or upgrade the third party tools to their Unicode supported version. A simple requirement like Unicode support for the UI translates to creating resource files for all locales, getting the number of strings which need to be externalized into those resource files, creating a library for reading and writing to the resource files etc. In this way we estimate at the very granular levels always taking into account our past experiences while making similar changes and the organization wide PCB (Process Capability Baseline) metrics. This estimation model is based on the bottom-up approach where estimates at the very root level finally add up to give the total development effort. To this we add the usual project management and testing efforts and come up with a final estimate.

The key to the whole estimation process is understanding the product and coming up with an exhaustive list of I18N impact areas and breaking them down into measurable entities which can be analysed manually or using tools. Like any other estimation process, this may or may not be very accurate, but after applying this to several Globalization projects, the model gets more and more well defined and the estimates are much more accurate. I am sure there are other estimation models people have experimented with while estimating effort for Globalization projects. It will be interesting to discuss alternate models and understand the pros and cons of each.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter