James D. Mooney
Dept. of Statistics and Computer Science
West Virginia University
PO BOX 6330
MORGANTOWN WV 26506-6330
jdm@cs.wvu.edu
A portability research group has been established at West Virginia University to help meet this need. Our overall goal is to develop improved methodologies for addressing portability in a cost-effective way for a wide range of software. A major obstacle to meeting this goal is the lack of established mechanisms to specify and measure portability. In this presentation we propose some initial approaches to the development of such mechanisms. We first describe briefly the issues that arise in developing portable software, and in reimplementing or porting existing software. This analysis is used to identify specification types and metrics that may aid in making effective portability-related decisions when performing these activities.
We argue the need for specifications to describe interfaces and environmental attributes and to characterize the "degree of portability" of a software unit. Some approaches to formalizing these concepts are discussed.
Cost metrics for software development and porting activities are also discussed, and we consider their use in comparing development and implementation alternatives. A formal definition for degree of portability is proposed, and some relevant software quality measures are briefly considered.
Some simple examples are also presented to illustrate these concepts.
Thus most software packages will eventually face the need to be ported in order to maintain and expand their viability. This need can be most effectively met if portability has been "built in" during the development process.
There is a need for software development methods which can explicitly consider portability as a possible objective. In addition, there is a need for techniques to systematically evaluate the portability of existing software in specific situations, and select an effective porting strategy if possible. Despite the evident value of portability, most existing methods do not address it [Lewis 90, Sommerville 92]. When porting does occur, it is based on ad hoc methods (for example, see [Blackham 88, Peck 81] and the case study chapters in [Lecarme 89]).
The absence of portability as an explicit concern in software development methods is demonstrated in a study by Song and Osterweil [Song 92]. This study examined a broad range of SDM's with the goal of developing a framework for description and comparison. The methods considered ranged from Booch's OOD [Booch 86], to Jackson's JSD [Cameron 86], to more conventional methods. This study identifies dozens of concepts that are included in one or more of these methods, including problem concepts (e.g., software complexity), solution principles (e.g., information hiding), and element measures (e.g., cohesiveness). None of these concepts relates directly to portability (or reusability).
There is also ample evidence for increased recognition of the need for portability. Lewis and Oman [Lewis 90] identify portability as one of the key emerging software challenges. The widely-used text by Sommerville [Sommerville 92] has devoted more space to portability in each edition. "Open systems" and "multiplatform implementations" are now popular industry buzzwords. Portability across parallel architectures is increasingly sought under the name of "architecture-independent parallelism" [Skillicorn 90].
Progress has been made in recent years in the incorporation of formal methods into the software development process. There is great interest in the use of formal notations for expressing functional requirements specifications [Gerhart 90], and there is expanding use of metrics both to measure the development process and to evaluate the resulting products [Mills 90]. However, no formal techniques have been reported to specify or measure portability.
The software portability research group at West Virginia University is carrying on a variety of investigations related to these issues. Our general goal is to improve the cost-effectiveness of the software development process by exploiting the potential for porting and reuse. One of our specific goals is the development of specification and measurement techniques relevant to software portability. This paper explores some of the issues that need to be considered in working toward this goal, and proposes some elements of a framework for continuing research. We consider specifications and metrics in relation to the portability issues raised by two principal activities: development of a portable software system, and implementation of an existing software system in a new environment. The latter activity is considered "porting" if the new implementation is derived from an existing one.
The paper is organized as follows: section 2 outlines the viewpoints we take on basic portability concepts. Development and porting activities are considered in detail in sections 3 and 4. Based on this analysis, we then identify in sections 5 and 6 some specific types of specifications and metrics that may be required. A pair of simple example is treated in section 7. The final section then discusses the areas of need for further research in specification and metric issues related to portability.
Porting is the act of producing an executable version of a software unit or system in a new environment, based on an existing version. Current discussions focus mainly on application portability. We use the term software unit to indicate an application program, a system program, or a component of a program. A software system is a collection of software units. The term environment refers to the complete range of elements in an installation that interact with the ported software. This typically includes a processor and operating system; it may also involve I/O devices, libraries, networks, or a larger human or physical system. Many authors use the term platform with a similar meaning.
The term portability refers to the ability of a software unit to be ported (to a given environment). A program is portable if and to the degree that the cost of porting is less than the cost of redevelopment. A software unit would be perfectly portable if it could be ported at zero cost; this is never possible in practice. Instead, we characterize software by its degree of portability, which is a function of the porting and development costs, with respect to a specific target environment. One goal of our work is to formalize this concept.
The principal types of portability usually considered are binary portability (porting the executable form) and source portability (porting the source language representation). Binary portability offers several advantages, but is possible only across strongly similar environments. Source portability assumes availability of source code, but provides opportunities to adapt a software unit to a wide range of environments. In this paper we consider only source portability.
The porting process has two principal components which we call transportation and adaptation. Transportation is physical movement; this may not be trivial since compatible media must be used and various types of representation conversion may be required. Adaptation is any modification that must be performed on the original version; we take this to mean both mechanical translation such as by language processors, and manual modification by humans.
Costs may be associated with the use of a portability-based strategy for software development; these could take the form of increased development costs and of possible reductions in some quality measures of the actual software (e.g., performance, or conformance to system-specific user-interface conventions). The corresponding benefits take the form of reduced costs to produce and maintain future implementations, as well as possible quality improvements in factors such as reliability.
This view is consistent with the majority of SDMs, such as those studied in [Song 92] or described in [Bergland 86]. The issues we discuss here are orthogonal to most details of the SDM or lifecycle model. They do, however, require the view that the lifecycle of a software unit or system is not restricted a priori to a single implementation.
2. What degree of portability is desired for the various environments in these classes?
3. What extra development costs, if any, are acceptable in order to achieve these portability goals?
4. What reduction in the quality of the implementations, if any, is acceptable to achieve the desired portability? The first of these questions seeks to define constraints for the portability question by placing bounds on the range of environments to which porting may be anticipated. The second question deals with portability benefits, that is, the improved attributes of the final design expected due to portability considerations. The remaining questions address the two potential costs of portability: increased cost in the development process, and reduced quality in the actual implementations.
If these questions can be answered precisely, it may be possible for the designer to select a methodology that can achieve the desired portability goals within the boundaries of the acceptable costs.
2. Eliminate all unnecessary assumptions throughout the design.
3. Identify specific environment interfaces required (procedure calls, parameters, data structures, etc.). For each interface, either:
4a. Encapsulate the interface completely in a suitable module, package, object, etc. Anticipate the need to adapt this interface to each target system; or:
4b. Identify a suitable standard for the interface, which is expected to be available in most target environments. Follow this standard throughout the design. Anticipate the need to provide a software layer to "bridge the gap" for environments which do not implement the standard satisfactorily. A special case of 4b is the selection of a suitable programming language. This choice must consider the availability of translators for the anticipated target environments. Moreover, it is desirable that as many of the required interfaces as possible be captured as elements of the language itself. For example, a language with a variety of standard file operations built in, such as Ada or C, would allow these operations to be used freely throughout the program. Choice of a language with limited facilities, like Pascal, would require more attention to isolating these operations if portability is to be maintained. This consideration might require selection of a different language than would be preferred based on other criteria.
2. The notion of a specific degree of portability. We believe that these are the two central challenges for effective portability specification. Some approaches that could handle these issues are considered in section 5.
Note that question 1 can be answered most broadly if we focus on a minimum set of requirements as outlined in 3.2. It is important that specifications which are sensitive to portability goals should not overly constrain the implementation. In some cases differing behavior is desirable for different implementations. For example, a flexible specification would specify usage of a graphical user interface with certain generic properties, rather than a Macintosh interface in particular.
The principal questions to be decided are: 1. Should the existing program be ported, or should an equivalent program be redeveloped?
2. Should the inherent portability of the program be improved?
The degree of portability, however, can only be precisely specified with respect to a specific target environment. Even if the existing program has a known degree of portability for a class of environments, a specific environment may not be entirely typical of the class. Moreover, target environments may be considered that were not included in the original design class.
This problem is most effectively addressed if it is possible to characterize portability by identifying the complete external interface requirements of a software unit. These could then be compared with the interface attributes of the environment, and a straightforward analysis could estimate the probable porting costs (and thus the portability degree) by comparing the characteristics of the software unit and the environment.
Using this knowledge about the degree of portability, a decision must be made to take either a porting approach or a redevelopment approach. This decision should consider the costs of each step in the development processes implied by each approach, as well as any difference in benefits.
Assuming availability of the source code, the principal steps in the porting process are transportation and adaptation, and the latter may be separated into manual modification and automated translation. Thus we have three principal activities: 1. Modify the source as necessary to suit the requirements of the new environment.
2. Translate the modified source to executable form, using a compiler or other translator which generates code for the target environment.
3. Transport the program physically to the target environment in suitable form. These steps may be performed in various orders, depending for example on whether translation is more conveniently done by a cross compiler in the original environment or by a resident compiler in the new one.
In some cases, supporting tools must be ported using similar procedures, probably before the main software is ported. These may include compilers and even operating systems. Often auxiliary data files or databases must be ported as well.
Once installed in the new environment, the software must be tested and debugged. This activity can also be partially performed at earlier stages by techniques such as formal verification or simulation testing. This process may lead to iterations of the earlier steps.
Finally, the completed implementation should be documented, and normal maintenance or enhancement activities may be required throughout its life cycle.
Once the specifications are available, the principal development activities are: 1. Design a software structure most appropriate to the new environment;
2. Implement the software for the new environment. Here also it may be necessary to develop (or port) support tools for the new environment, and to port or reimplement data files.
Testing and debugging are again required, and may lead to iterations of the design and implementation steps.
As in the porting case, the new implementation should be documented, and maintenance activities must be supported.
The principal activities of porting, as outlined above, begin with modification, translation, and transportation. The redevelopment activities begin with design and implementation. Both options share the later activities of testing and debugging, documentation, and maintenance. Also in both cases, there may be a need to port or redevelop tools and data files.
Modification is typically the most costly of the initial porting steps. This is primarily a process of bridging the gap for any interfaces which are not implemented by the environment in the manner expected by the software unit. This work is proportional to the number and size of mismatched interfaces and to the degree of mismatch; it will be minimized if the original software has been designed for portability.
One method to bridge some of these gaps is to port software units from the other side of the interface, such as libraries or even operating systems. This porting is a major undertaking with large costs and potential long-term benefits. It should be justified only by its usability in a very large project or over a series of projects.
Translation is an element of both options. However, a new language may be chosen for redevelopment. In porting the original language is fixed. If no translator is available for the target system, one must be developed or ported at high cost. Again, this can be justified only by its value for many projects or for very large projects.
Transportation of source code is unlikely to present a major cost. Transportation of data files may be costly due to format conversions required, but will present the same difficulties with either option.
For the redevelopment option, standard techniques can be used to estimate the costs of design and implementation. Design costs may be reduced if portions of the original design can be reused.
The costs of testing and debugging, documentation, and maintenance should follow normal expectations for a redeveloped software unit. If the software has been ported, all of these costs will be lessened. Only a limited amount of code has been changed from an original, tested version, so errors should be less numerous. If the software is strongly similar to the original version, the documentation will be similar also. Finally, most maintenance modifications will be easily importable to multiple installations, since source modules are very similar and may even be directly shared.
A few of these factors are so significant as to obviously tip the balance in favor of one of the two options. If none of these factors apply, the costs of the remaining differences must be considered more carefully. These costs are further examined in section 6. We must also note that the redevelopment process offers greater opportunities to improve the software in two (conflicting) ways: to optimize its structure for the particular target environment, and to increase its portability to future environments.
If the redevelopment option is chosen, portability can be enhanced by the same techniques described for original development in section 3. This may be attractive if future ports are anticipated. Since a choice was made for redevelopment, it is likely that the existing portability was not high. The new version could become a starting point for the porting option in future implementations.
If the porting option has been chosen, improving portability is likely to be much less attractive for two reasons: 1. The existing portability is probably already fairly high, since a choice has been made to port rather than redevelop;
2. Any design changes need to be propagated back to the original version and all implementations to maintain consistency.
Specifications of many types are used throughout the software development and maintenance processes. The term specification is often assumed to refer to requirements specifications, which identify required characteristics of systems yet to be built. In most cases requirements specifications identify the desired functional behavior of the system. Much study has taken place on effective techniques for functional specification, and there is increasing interest in formal notations such as Z [Diller 90] and VDM [Jones 86].
There is a recognized need for techniques to more effectively specify non-functional requirements for software systems, such as timing constraints, reliability, and portability [Roman 85, Stankovic 88]. The first two of these are subjects of active research (e.g., [Luqi 88, Sitaraman 92, Srimani 92]); the last is considered here.
Specifications also play an important role in characterizing designs and finished products. In this case one goal may be a precise description of actual functional behavior and non-functional properties; another is a description of structural elements such as algorithms, data structures, and module interfaces. Programming languages offer one precise mechanism for specifying some of these elements, but there is no general agreement on the most appropriate mechanism for a language-independent specification.
As shown in 3.3, there is a need for two particular types of specifications: 1. Descriptive specifications which characterize the environmental requirements for a software unit, and the facilities available in a specific environment, in terms of interfaces and intrinsic attributes such as reliability;
2. Quantitative specifications which characterize the actual or required degree of portability of an application with respect to a specific environment or class of environments. No additional specification types were suggested by the analysis of section 4.
The first type require a concise statement of interface structures and of certain environmental attributes. For example, specifications for a linear algebra package might call for certain models for memory management and floating point arithmetic; those for a video processing application might require a display device with certain attributes, storage capacity above some minimum, and processing power for a stated number of frames per second.
The purpose of this information is to identify mismatches between software units and environments. Fatal mismatches, such as absence of essential physical resources, should be easily detectable, since they imply that no implementation is possible. Correctable mismatches should be made clear to allow identification of suitable techniques for overcoming them, and estimation of the associated costs.
The interface structures are most effectively identified by reference to established standards, where suitable standards exist. A list of standards (with appropriate options) suitable for a particular type of software unit has been given the name profile by the standards community[ISO 90]. For example, a profile may specify the use of such elements as the POSIX operating system interface, X-Windows, and IEEE-854 floating point arithmetic (although these specifications do not all have the same status as officially recognized standards).
Interfaces that are not addressed by a suitable standard may be specified at a high level as general resource requirements (high-resolution color graphics, mouse support, main storage for one million 32-bit integers, etc.); this will aid detection of fatal mismatches. At a more detailed level they may need to be identified by a complete specification of their logical structure and semantics.
Finally, attributes such as capacity, reliability, etc., must be stated in the form of appropriate metrics. Generally a mismatch in one of these attributes would also be fatal.
The second type of specification listed above must be based on suitable metrics to quantify the cost of porting and the cost of redevelopment. These costs may be derived from the interface specifications discussed above, and from the other specified requirements of the software unit. A typical requirements specification may state that the degree of portability should be maximized, for all feasible environments, subject to certain constraints on the added development cost required to provide this degree. The concept of degree of portability is made more precise in the next section.
Process metrics may characterize resources used such as dollars, equipment, person-days, etc. or production measures such as lines of debugged code. Product metrics may measure size, performance, complexity (density of branches, variables, etc., procedure or module dependencies), or occasionally more abstruse attributes like reliability or maintainability.
The principal role of metrics in relation to portability issues is to help characterize the costs and benefits of incorporating portability in a software design, or of porting an existing software unit. A meaningful comparison between the costs and benefits of portability-based methods and those of other methods can help ensure a sound choice of methods for a given project. Moreover, these metrics should be helpful to characterize the effectiveness of the chosen method after the project is complete.
In this section we propose some metrics of possible relevance to portability. We will first identify a series of measures of software development cost according to the various options we have discussed, and state some straightforward intuitive relations between them. Next, a definition for degree of portability will be proposed. Finally, we will briefly discuss product metrics which are harder to quantify.
We will assume that development cost activities may be measured in the traditional unit of person-days, since humans are the most costly resource in the development process. We will not address well-known questions about the validity of this measure, such as whether persons and days may be traded off in a linear fashion. We assume that any other significant resource consumption is proportional to this measure.
Suppose, first, that the cost of developing a software unit su for an initial environment e1, starting from its requirements specification req, can be estimated by traditional means. If we treat maintenance as a separate, later activity, this cost is composed primarily of components for design, coding, test and debug, and documentation. We designate this cost as Cdev. This cost depends on the requirements and the target environment. It can be broken down as
Cdev(req,e1) = Cdes(req) + Ccod(req,e1) + Ctd(req,e1) + Cdoc(req,e1). Each component depends on the environment except Cdes, since the design phase is (ideally) implementation-independent.
This cost does not take into account efforts required to produce a portable design. These efforts consist primarily of the activities identified in 3.2. This portability analysis has an added cost which we designate Cpa. Note that this cost is not dependent on a specific environment. Cpa in turn is composed of a component for each interface involved, which is proportional to the effort required to accommodate that interface as effectively as possible. That effort will be minimized where a suitable generally-accepted standard exists.
The total cost to develop an original portable design plus an implementation for environment e1, is
Cdevp(req,e1) = Cdev(req,e1) + Cpa(req)
The cost of redevelopment of a software unit with the same specifications, targeted for a new environment, is based on the analyses in 4.4 and 4.5. The components of this cost, especially the design component, will be somewhat reduced compared to original development; this reduction will be greatest if a portability analysis has taken place. We can define
Crdev(req,e2) = Crdes(req) + Crcod(req,e2) + Crtd(req,e2) + Crdoc(req,e2) where, for each component as well as the sum, given identical parameters,
Crx <= Cx.
The component Cpa can optionally be added to Crdev if the redevelopment is to add portability.
Finally, the cost to port a software unit to a new environment is composed primarily of components for manual modification, test and debug, and documentation, as discussed in 4.3 and 4.5. This cost may be defined as
Cport(su,e2) = Cmod(su,e2) + Cptd(req,e2) + Cpdoc(req,e2).
Note that Cport and Cmod are functions of the original software unit itself as well as the target environment, since they are concerned with bridging the gap between them. In general we expect that
Cptd < Crtd and
Cpdoc < Crdoc
Furthermore, if a portable design has not been developed, it is not unlikely that
Cmod > Crdes + Crcod
since the modifications begin with code designed for a different target, whereas the redevelopment begins with more generic specifications. If there is an effective portable design, however, the inequality becomes Cmod << Crdes + Crcod
and this is where we realize the greatest benefits from the portable design. We have not here addressed maintenance costs, but we note again that for a set of implementations that were created by porting, maintenance costs for each should be considerably less than if they were independently redeveloped.
We are now prepared to propose a formal definition for the degree of portability of a software unit, which is a product metric and a function of the target environment:
DP(su) = 1 - (Cport(su,e2) / Crdev(req,e2)). This measure has a maximum value of 1, representing perfect portability (Cport = 0). In general, portability is cost-effective if and only if DP > 0. To appreciate its significance in a particular case it would be necessary to state the values of Cport and Crdev as well.
The final category of metrics we consider are those that measure the possible loss of quality for an implementation derived by porting rather than by environment-specific development. One form of quality loss is extra overhead due to the use of overly-general components plus extra code to bridge the gap. Increases in memory use and execution time are the most likely costs; they can be characterized by well-known metrics, and estimated based on the amount of bridging software that will be introduced at run time.
Much harder to measure is the loss of quality perceived by users for software that does not fully exploit and conform to the resources and conventions of each specific environment (e.g. use of a generic command-line interface on a system oriented to more sophisticated graphics). This loss can probably only be quantified through user surveys. Such a measure would be used in part to determine the effort that should be expended in tailoring ported software to a specific environment.
The first question deals with the nature of the target class of environments. The essential requirements for a platform supporting the type of application we are considering include an effective color graphics interface, and adequate, consistent performance for smooth animation. These needs are typically met by many PCs and workstations. The need for consistent timing may rule out most multiuser environments.
We will not propose here a precise specification for this target class. What is needed, however, is a specification form which can concisely capture requirements such as the following:
* PC or workstation class
* medium resolution color graphics (e.g. 512 x 512, 256 colors)
* mouse or equivalent pointing device
* single process or priority foreground scheduling The other three questions involve tradeoffs on the costs and benefits of portability. Initial responses can be proposed, which may be refined during later analysis. There is a continuing evolution of PC and workstation models in the target class, and many of them would represent a potentially worthwhile market for the type of game to be developed. Therefore, a substantial benefit may be expected from multiple implementations over the life of the program.
The exact degree of portability desired is not as easily answered. Since portability is clearly important, a sensible response is to seek the highest degree for all targets, consistent with acceptable costs.
Reasonable added development costs are probably justified by the resultant gain in portability. We may propose here that acceptable costs would be no more than 20% of the total cost. If the estimated (non-portable) development time is one person-year, then we may tolerate the addition of one or two months to this cost.
Quality costs for our game application are not as readily paid. High interface functionality and optimum performance are both very important if our game is to appear more interesting and challenging than its competitors. We cannot hope for zero costs, but we may decide to tolerate no more than a 5% performance penalty, with minimal loss of functionality.
As a preliminary step in a possible portability analysis, we must identify the functional interfaces our program will utilize in each target environment. Here the principal ones (not covered by programming languages) seem to be
* animated color graphics
* keyboard and mouse input
* interval timing and alarms Several of these interfaces have no widely-used standard specification. Graphics standards exist, but these do not treat a full range of color control and animation functions. The ASCII character code may suffice here for keyboard input, but there is no standard for mouse positioning. There is also no standard supporting a comprehensive range of timing functions. Because of this, we may anticipate a need for substantial effort, and perhaps limited success, in devising a portable representation for all of the required functionality.
We will next perform a hypothetical cost analysis for our example. Most of the specific values we will use are initial guesses unsupported by any experimental data.
The discussion in Section 6 identifies the principal components of the development process as design, coding, test & debug, and documentation. Let's suppose an optimistic breakdown of the percentage of effort for each of these tasks is 40, 30, 20, 10. One optional strategy for future implementations is redevelopment. The cost of redevelopment will normally be less than the cost of original development. How much less depends on the degree of portability provided by the original design.
If portability was not considered in the original design, redevelopment will be substantially like original development. Most interfaces will differ in form. Appropriate modularity will not necessarily have been incorporated. Perhaps a savings of 10% of the original effort can be attained. If a portability analysis was done, the saving may be closer to 30%. The difference lies in the fact that if a portable design was not developed initially, there will be more arbitrary differences in the new design compared to the original. These percentages may be distributed fairly evenly over the four areas.
Let the unit cost for one or more components of the development process be the cost for original development without portability analysis (p.a.). Then our estimated cost for redevelopment without p.a. is 0.9 (since we save 10%). If we estimate the cost for p.a. itself at 0.2, as noted earlier, the estimated cost for redevelopment with p.a. is 1.2 * 0.7, or 0.84.
Next we consider the porting option. If there was no portability analysis, the cost of modification for porting may be greater than the cost of redesign and coding from the original specifications. This is because the modification must convert one system-specific interface to a different one. This excess effort could easily amount to 50%. On the other hand, testing and documentation will always be more straightforward after porting than after redevelopment. A reduction of 25% in these costs may be reasonable. Since design and coding are assumed to represent 70% of the development costs, and test and documentation 30%, the net cost in this case for the complete porting process is given by
C = 1.5*0.7 + 0.5*0.3 = 1.2.
If a portable design has been developed, however, modification will offer some savings over redevelopment. Here the savings may be limited because of the many non-standard interfaces, but with reasonable design effort it should not be less than 50%. We may hope also for a reduction of as much as 50% in the test and documentation costs, since the implementations will have even higher similarity. The overall cost for this option is given by
C = 1.2 * (0.5*0.7 + 0.5*0.3) = 0.6.
We have assumed for simplicity that porting costs will be the same across all feasible target environments. Without p.a., the degree of portability to be achieved is given by
DP = 1 - (1.2 / 0.9) = -0.33.
Since this is a negative quantity, redevelopment is the preferred option.
If instead the components were developed using a portability analysis, the equation becomes
DP = 1 - (0.6 / 0.84) = 0.29.
This value is not extremely high, but it does justify porting as the most cost-effective option.
It is clear that portability will become more cost-effective as the number of implementations increases. The table below shows the total and average costs for up to four implementations, with and without the p.a. costs up front, using the appropriate implementation option in each case.
NO. OF IMPL. 1 2 3 4
Without p.a. 1 1.9 2.8 3.7 TOTAL
(redevelopment) 1 0.95 0.933 0.925 AVERAGE
With p.a. 1.2 1.8 2.4 3.0 TOTAL
(porting) 1.2 0.9 0.8 0.75 AVERAGE For a single implementation, of course, the portability analysis is not justified. With a second implementation the two options offer comparable costs. If the anticipated number of implementations exceeds two, the cost of a portable design is increasingly justified.
The compiler example has some significant differences from the video game example: 1. The potential target class of environments is broad, encompassing batch and timesharing systems as well as PCs and workstations, and requiring only a basic alphanumeric interface.
2. The projected portability benefits are limited, though not zero, since this is a specialized application with a limited set of users. High development costs to incorporate portability cannot be justified.
3. Reasonable performance costs could be tolerated, since compilation speed is not as critical. Compromises in functionality are less likely to arise, due to the less sophisticated user interface requirements. The principal interfaces of importance will include
* alphanumeric screen and keyboard
* dynamic heap memory management
* file management, possibly with random access Problems from lack of standardization will be found in at least some areas of heap management and file management.
Suppose we assume we can accept a 10% performance reduction but no more than a 5% increase in development costs. The interface difficulties are more limited than in the video game, thus these goals may be realistic.
Using the same units and breakdown of the process costs as before, we may estimate redevelopment costs at 0.8 without p.a., or 0.6 with p.a. The smaller figures are justified by the more limited obstacles to porting.
Without p.a., the excess cost of modification may be only 0.1, and the savings on test, debug and documentation for a porting strategy may be 0.3. Thus overall porting cost is 1.1*0.7 + 0.7*0.3, or 0.98 of original development costs. With p.a. we may hope for a modification cost of only about 0.15, with a test, debug and documentation savings of 0.7. This yields a porting cost of 1.05 * (0.15*0.7 + 0.3*0.3) = 0.20.
These figures lead to a degree of portability of 1 - ( 0.98/0.8) = -0.225
without p.a., or
1 - (0.12/0.6) = 0.667 with p.a. A limited-cost
portability analysis should lead to a highly portable design.
The costs for one to four implementations of this example are summarized in the following table. NO. OF IMPL. 1 2 3 4
Without p.a. 1 1.8 2.6 3.4 TOTAL
(redevelopment) 1 0.9 0.87 0.85 AVERAGE
With p.a. 1.05 1.20 1.40 1.60 TOTAL
(porting) 1.05 0.60 0.47 0.40 AVERAGE Again note that many of these figures are fairly arbitrary, presented only to illustrate the proposed concepts. More accurate estimates can be obtained from available experience in the development of particular classes of applications.
We have proposed some elements of a framework for portability, but the complete framework requires much additional work. Our group at West Virginia University is engaged in developing, studying and validating these mechanisms. As one component of our study we seek to identify and characterize a wide range of software types from a portability perspective, and to apply these specification and measurement techniques to selected examples.
A major long-term objective is the development of an arsenal of tools, techniques, and decision-making aids to enable portability to be more effectively exploited in the software development process.
This paper represents some very preliminary ideas for a problem which we believe has been largely unaddressed. If it serves to stimulate some discussion and further ideas in this area, we will have accomplished our intended purpose.
Thanks to Murali Sitaraman, Jim Wilcox and Jon Beck for their comments on various drafts of this report.
Bergland, G., and Zave, P., eds., Special Issue on Software Design Methods. IEEE Trans. on Softw. Engr., Vol. SE-12, No. 2, Feb. 1986.
[Blackham 88]
Blackham, G., Building Software for Portability. Dr. Dobb's Journal of Software Tools, Vol. 13, No. 12, Dec. 1988, pp. 18-26.
[Booch 86]
Booch, G., Object-Oriented Development. IEEE Trans. on Softw. Engr., Vol. SE-12, No. 2, Feb. 1986, pp. 211-221.
[Cameron 86]
Cameron, J., An Overview of JSD. IEEE Trans. on Softw. Engr., Vol. SE-12, No. 2, Feb. 1986, pp. 222-240.
[Gerhart 90]
Gerhart, S., ed. Special issue on Formal Methods. IEEE Software, Vol. 7, No. 5, Sep. 1990.
[ISO 90]
ISO/IEC. Procedures for the technical work of ISO/IEC JTC1. ISO/IEC, Geneva, Switzerland, 1990.
[Jones 86]
Jones, C.B., Systematic Software Development Using VDM, Prentice Hall International, 1986.
[Lecarme 89]
Lecarme, O., M.P. Gart, and M. Gart, Software Portability With Microcomputer Issues, Expanded Edition, McGraw-Hill, New York, 1989.
[Lewis 90]
Lewis, T.G., and P. Oman, The Challenge of Software Development, IEEE Software, Vol. 7, No. 6, Nov. 1990, pp. 9-12.
[Luqi 88]
Luqi, V. Berzins, and R. Yeh, A Prototyping Language for Real-Time Software, IEEE Trans. on Software Eng., Vol. 14, No. 10, Oct. 1988, pp. 1409-1423.
[Mills 90]
Mills, H.D., and P.B. Dyson, eds. Special issue on Metrics. IEEE Software, Vol. 7, No. 2, Mar. 1990.
[Mooney 90]
Mooney, J., Strategies for Supporting Application Portability, IEEE Computer, Vol. 23, No. 11, Nov. 1990, pp. 59-70.
[Peck 81]
Peck, J.E.L., and M. A. MacLean, The Construction of a Portable Editor, Software -- Practice and Experience, Vol. 11, 1981, pp. 479-489.
[Roman 85]
Roman, G.C., A Taxonomy of Current Issues in Requirements Engineering, IEEE Computer, Vol. 18, No. 4, Apr. 1985, pp. 14-23.
[Sitaraman 92]
Sitaraman, M., Towards a Modular Approach for Real-Time Specification and Verification of Reusable Software Components, Proc. 9th IEEE Workshop on Real-Time Operating Systems and Software, May 1992.
[Skillicorn 90]
Skillicorn, D., Architecture-Independent Parallel Computation. IEEE Computer, Vol. 23, No. 12, Dec. 1990, pp. 38-50.
[Sommerville 92]
Sommerville, I. Software Engineering (4th ed), Addison-Wesley, Reading, Mass., 1992.
[Song 92]
Song, X, and Osterweil, L., Toward Objective, Systematic Design-Method Comparisons. IEEE Software, Vol. 9, No. 3, May 1992, pp. 43-53.
[Stankovic 88]
Stankovic, J., Misconceptions About Real-Time Computing: A Serious Problem for Next-Generation Systems. IEEE Computer, Vol. 21, No. 10, 1988, pp. 10-19.
[Srimani 92]
Srimani, P., and Y. Malaiya, Steps to Practical Reliability Measurement, IEEE Software, Vol. 9, No. 4, Jul. 1992, pp. 10-12.