Case Study: Symbian Ltd.

Solution Summary

Following the release of version five of Symbian's EPOC operating system (EPOC Release 5) in March 1999, Symbian started looking at replacing its software configuration management (SCM) system. The existing system was felt to be too limited to handle the complexity of EPOC and its future release strategy.

Customer Profile

Symbian was established by leaders in the computing and wireless industry to enable the mass market of smartphones and communicators -- next-generation mobile phones, or Wireless Information Devices (WIDs).

Symbian has two main objectives:

  • To develop and license a standard software platform for WIDs
  • To work in partnership with the industry to ensure availability and interoperability of applications, content, services and networks for WIDs

Symbian is achieving its goal of enabling the mass market for WIDs with measurable success.

Originally the software subsidiary of Psion, Symbian has over 18 years' experience in developing software technology for mobile computing devices. Symbian was established in June 1998 as a privately owned, independent company by Ericsson, Motorola, Nokia and Psion. Matsushita joined the Symbian joint venture as a shareholder in May 1999.

Since its launch, Symbian has signed strategic agreements with a wide range of wireless industry leaders including NTT DoCoMo, the world's largest network operator, as well as Kenwood, Sony, Sanyo, Sun Microsystems, Oracle, Qualcomm, Texas Instruments, ARM, Cadence and Sybase.

The company currently employs approximately 720 people in 11 offices. With headquarters in London, Symbian also has offices in Tokyo and Kanazawa, Japan; Ronneby, Sweden; Cambridge, UK; and the San Francisco Bay Area, USA.

Development Challenge

Symbian's operating system (now renamed the Symbian OS) is optimized for the demanding requirements of WIDs. It delivers powerful applications and communications capability in a small package, thanks to a robust system kernel, powerful object-oriented middleware, industry-standard communications protocol suites, and an optimized implementation of Sun's Java language. The Symbian OS's robustness, compactness and performance are delivered through careful system design in C++ and tailored programming disciplines used by all Symbian developers.

The configuration management challenge facing Symbian was to coordinate and control the efforts of 300+ developers working on EPOC around the world. They needed a solution that would manage the development of over 100 components which are packaged into a number of DFRD (device family reference device) suites. These are delivered to licensees for incorporation into products.

Requirements

The Symbian environment is complex, with many parallel developments underway at any one time, providing for several release projects as well as projects to produce significant new features. The Symbian OS is substantial, consisting of more than 40,000 source files. It is mission-critical for the licensees. With tens of thousands of PDAs and related items in the field running the Symbian OS in ROM, reliability is key.

When embarking on the selection of an SCM tool, Symbian also decided to take the opportunity to improve its development process in order to give the company the fastest return on its investment in the new tool.

The new process took into account both generally accepted SCM best practices, and the life-cycle model suggested by other users of the short-listed tools. With the new process, code changes are made in development branches and integrated with a main codeline when they are working. "Each codeline has its own usage policy depending on its purpose - development, porting, QA, etc. - which allows us to have more control over the evolution of a release," says Peter Jackson, a software architect at Symbian. Code is promoted through the mainline to release codelines which have progressively more rigorous criteria designed to improve product quality until it is ready for shipping.

"The build coordinator is a key role in the new development process," explains Jackson. "We have a team of build coordinators, drawn from within the development community, who work in rotation. Each day, the build coordinator begins by publishing a timetable and any variations on the submission process. At the end of the day, the coordinator publishes the accepted submissions and starts the build process. On the following day, the coordinator examines the build logs, carries out smoke tests on the system and publishes the build report. If a build fails, the coordinator identifies the submission(s) that caused it. The engineer(s) responsible are then said to be on the hook - their most urgent task for the day is to repair the system."

Competitive Alternatives

"The process of choosing a tool started with internal discussions from which emerged a set of hard requirements, and we used these to aggressively filter the list of possible candidate systems down to a shortlist of five," Jackson says. "These five systems were then put through a more thorough evaluation. Responsibility for each evaluation was delegated to specific individuals, who would immerse themselves in the candidate system and complete a checklist describing how the tool measured up to the requirements."

From this evaluation, the project team chose a set of three tools which would be piloted by using them concurrently with the development process. This would also involve further usability evaluations. At the end of the pilot phase, none of the three tools had been explicitly ruled out. The final evaluation was therefore on the basis of perceived quality and minimizing the impact of change.

Perforce Solution

Symbian chose Perforce Software as its SCM supplier because its solution not only fit Symbian's stringent criteria, but the company demonstrated that it understood the way Symbian worked. The depth of the evaluation model developed by Symbian gave developers the confidence to go with this choice.

Perforce appeared to offer support for a richer style of working than the other tools. It was also a product that was well-liked by its most important potential users in the company -- the software engineers themselves. This has been a factor in their continued support for Symbian's SCM processes.

With the new development model thought out and the new SCM tool selected, Symbian had to find a way of switching to it without disrupting development itself. They did this by introducing Perforce in the background, and using an import mechanism for it to acquire code changes from the incumbent system. This meant that developers could make a transition to the new system at their own pace.

Key Advice

Jackson says he would give anyone starting on a similar project the following key pieces of advice:

  • Involve the right people. Use respected members of the development community and good project managers. Secure the commitment of senior management.
  • Plan. This comes about almost naturally if you build the right team - but it is essential to form a migration plan and put effort into tracking it.
  • Put the required effort into developing and tracking the new processes.
  • Train and communicate. However simple a system might seem to those involved in setting it up, there is enormous capacity for misunderstanding. A training program helps to get the messages across and is an important source of feedback. Your supplier should play a central role in identifying and fulfilling training needs.

Further Reading

The Symbian experience with Perforce is described in greater detail in a paper entitled A Year With Perforce which Peter Jackson presented at the 2000 Perforce User Conference.

Read the paper that Peter Jackson presented at the 2001 Perforce User Conference entitled Cooperative Development at Symbian.

Profile

Peter Jackson
Peter is a Software Architect at Symbian Limited, London, UK.

Development Environment at a Glance

Company name
Symbian Ltd.
Headquarters
London, UK
Industry
Hardware/OEM Licensees
Type of application
Production of core operating system and applications for licensees
Client hardware
Windows/NT or 9x clients
Server hardware
Windows NT Server 4.0 with dual CPUs (PII 450 MHz)
Type of Network
100 Mbps; 10 Mbps hub
Number of users
500 (a mixture of developers, testers, documentation writers and Web developers)
Number of development sites
Seven (three in London; one each in Cambridge, Japan, Sweden, and the US)
Number of files
77,718 in the mainline and at least 15 release/delivery codelines each near that number. We also have thousands of development branches, but they are a smaller subset of the total.
Languages Used
C++, Java
Customer since
August, 1999

More Case Studies