Software reuse

Software development constitutes an increasing proportion of development costs due to an increasing number of features in the software. This makes it very important for us to be able to reuse software efficiently.

The first article deals with how RTX practices reuse in the development of software and the other is about reuse in the software organization, which can be easily transferred to your development organization.

Software reuse = Faster development time

The software framework gives a competitive advantage to handset manufacturers since they are able to use the same MMI in all their phones, from cordless to advanced 3G phones. To accomplish this versatility we use a traditional Three Tier solution; thus the user applications are shielded against technology changes. The MMI framework is based on a separation of the graphical user interface code and the application code. RTX also uses a true component-based and extensive software framework to enable more reuse across various projects An object-oriented programming language gave us the direct support for this.

Extremely versatile

The platforms range from all cellular phones to cordless phones. But the phones vary from CPUs that are four times less powerful than cellular handset CPUs and applications from simple black-and-white display DECT phones to sophisticated large-screen, colourdisplay

cellular phones with Phonebooks, Calendar, Camera, WAP, Java and MMS applications. Under these conditions, it is essential that the software can be reused extensively and that the required scalability, productivity goals and quality can be obtained at the same time.

The software application is the differentiating module - hardware is becoming more and more alike

Customers usually have differing requirements for the user interface look and feel. One of the major keys for success for any product is to differentiate itself from other similar products.

Software reuse: Lower costs

Reuse has a high focus at RTX, both in project management and in development. A high focus on reuse is a key element to keep and improve our competitiveness.

A full graphical multitasking windows system

The goals that we set for ourselves ranged from the highly technical to goals oriented purely towards the software development process.

Looking at the target systems, we soon realized that a full graphical multitasking window system would help us implement advanced applications and systems. A clear separation of the graphical user interface code and the actual application code is a well-known property of good software, and we wanted direct support for this in the software. Together with an object-oriented programming language, we  could meet our long-term goals of reuse more easily, shorter time to market and higher quality at the same time - two key factors, especially in the handset market.

XFC is based on defined standards

To ease the use and adoption of the software, we based the software on well-known standards and methodologies instead of proprietary solutions. This would mean that the window system should be just like any other window system but simpler and slimmer. Support tools and formats should be based on open standards such as XML (Extensible Markup Language) and XSL (XML Style sheet Language) together with graphical front ends.

OS independent

No assumptions should be made about any specific RTOS or scheduling scheme (preemptive or non-pre-emptive). It could, however, be assumed that some kind of OS would be present and that memory management, a messaging mechanism (usually via a queue) and timers would be available.

Think in terms of interfaces - syntax and semantics are important

Whether one uses object-oriented programming (OOP) or not, the important issue is to think in terms of interfaces. As long as the interfaces can be described in terms of syntax and semantics, the actual implementation is of no interest except to the ones who actually implement it. By using OO features such as inheritance and polymorphism, we add the possibility of extending interfaces in a consistent and simple way. Describing systems and interfaces can be done in many ways. A popular notation these days is the use of UML as the descriptive language. UML supports interface description using object-oriented notations. To close the gap between an OO design and the actual implementation, an OOP language is needed as it directly supports design features such as classes, inheritance and polymorphism.

The RTX solution Object-oriented language is OOC; embedded C++ is not suitable

XFC uses a proprietary object-oriented language implemented in ANSI C - OOC. The reason for not using embedded C++ is that not all of the platforms that we had in mind actually had a C++ compiler.Even if C++ were a possibility, there has been much bad experience with inefficient C++ compiler generated code, which results in bigger code size as well as degraded performance. We needed to be in total control of the OO language. Therefore we chose to describe the class interface in XML and then automatically generate ANSI C code by the use of XSL. When writing a class, the programmer has to write the class description and implement the function algorithms. The C interface file, class virtual table and class function stubs (optional) are automatically generated, typically using the native-make system. The class description also acts as hypertext documentation with embedded documentation tags that can contain free text or HTML. It can be opened in an Internet browser that supports XML and XSL. It provides hyperlinks within the class and between classes. As OOC is modelled much like C++ both syntactically and semantically, any experienced C++ programmer will be familiar with this environment.

Read more about:

• XFC architecture and design

• XFC windows

• XFC telephony

On our website: http://technical-articles.rtx.dk/

Software reuse - organization

How to reuse experience and parts of previous projects to develop cost-effective solutions.

"As a rule of thumb at RTX, a feature must be available in three previous products and three future products before software reuse is feasible." Organizations may be tempted to invest in a single new technology, method etc., but in so doing they neglect the culture in the organization, and the people and the environment with which the initiative must co-exist. This often leads to disappointing investment results. Such a phenomenon occurs frequently, and is graphically described as the “Silver Bullet Syndrome” because some optimistic people think they can solve all problems by buying a simple tangible solution. For example, a common mistake is that object orientation (OO) is necessary and important for implementing software reuse. This is not the case, and RTX has succeeded in building a reuse

programme based on classic procedural techniques.

Three pillars -model used by RTX to augment and sustain software reuse

It is important for the organization to maintain a holistic approach to the implementation of systematic software reuse in order to obtain sustainable benefits from the investment. The following model is used at RTX to augment and sustain the software reuse process. It shows that the three pillars must be built up incrementally to improve the software reuse process in the organization. All three pillars are important to ensure the software reuse initiative is successful. However, it is also important to recognise that the human factor is intrinsic to all three areas, and can be considered the foundation on which all three pillars rest. RTX has

• developed a software architecture that supports reuse,

• built a new organisational structure,

• incorporated new methods and tools to facilitate reuse between projects.

Surveys have shown that most failures in implementing software reuse programmes are caused by the human factor.

Software reuse is a business matter involving technology transition and organisational change. Ensuring a reuse culture, providing training, adhering to standards, securing management commitment etc. are more important and are the key factors for success. Thus RTX has chosen a holistic approach towards institutionalising software reuse.

Software reuse will be more feasible in flexible organisations

A rule of thumb at RTX is that a feature must be available in three previous products and three future products before software reuse is feasible.This is to ensure that the feature occurs in multiple products and that development of a reusable component is feasible. However, the interface or component boundary cannot be considered completely fixed from first version onwards. It often requires three or more consecutive versions of a component before the functionality and interface are satisfactory and can be considered fixed. This means that the widespread use of the component in the organization is not possible, if the organization is not sufficiently flexible and adaptable to take on board the likelihood of boundaries changing in the first few versions of a component. In other words, software reuse will be more feasible in flexible organisations which can reuse components from the early stages when boundaries may still be subject to change.

For this reason, RTX has an organisational culture in which:

• information about reusable software and architecture flows freely,

• developers trust each other,

• management is committed to reuse,

• and all developers develop software with reuse in mind.

The RTX organization is flexible and adapts continuously to the ever-changing telecommunications market. The flexible organization and the holistic approach to implementing software reuse with a focus on the human factor as illustrated as the foundation for the three pillar model is one of the secrets behind the success of RTX software reuse.

Architecture, which denotes the process of developing software architecture to increase software reuse among products, i.e. software architecture which is optimised for a product domain and not just a single product.

Organization, includes the delegation of responsibility and the creation of a formal and informal organisational structure.

Tools/methods deals with the development of processes to sustain software reuse, modify existing procedures, and the investment intools to facilitate development, communication and coordination, e.g. a component archive.

Experience from the latest cordless project from RTX:

In the latest DECT project we measured 55% reuse of software. And approximately 90% of all faults are found in the new developed code. So reuse is the way to faster development and fewer software failures.