Appendix D: Software Engineering Factors This appendix considers the issues of software engineering technology related to the choice of a computer language. The judicious choice of computer languages can help an organization to stabilize its journey into the future. However, languages cannot be considered in isolation. This appendix presents various related software engineering factors that must be considered at the same time. Today’s business vision must embrace the developing ideas and methods of today’s computer technologists. The problem is that these ideas and methods are still developing, and it is difficult in many cases to be certain which direction points to a primary path and which will lead deep into the woods. This is especially true if one stands in the middle of all the "techno-babble" running rampant in today’s office places. One is inundated with information—overwhelming, conflicting information. To make sense of it all, it is necessary to look for some stable truths. In the software business, this is called moving to a higher level of abstraction, getting away from the unnecessary details to be able to analyze the important issues at a higher level. This discussion of software engineering factors will remain at this higher level, looking for stable truths. The software engineering factors listed in Table 3 in the main document are given in italics in the following discussion. As with the characteristics in Table 2, these factors are not entirely independent. They were chosen because they are the software engineering factors related to a choice of language. The decision maker will need to establish a rating for each language for each of the factors considered important for the current language selection decision. Ratings range from 0 to 10, where 0 is very poor and 10 is excellent support for a factor by the language. The discussion below for each factor provides guidance on how to determine a rating for that factor. In this appendix, the discussion begins with a section on Computer Languages, and this is followed by the major section on Software Engineering Factors. The appendix concludes with a discussion on Meeting Requirements. Computer Languages A computer language is a mechanism used to communicate with a computer. This simple definition has led to a concept of generations of languages. Yet the simplicity of this issue has become muddled by the use of CASE tools and environments. The term fourth-generation language (4GL), for example, has been used to describe everything from a simple language translator to a complete CASE environment. Some people are also starting to use the term fifth-generation language (5GL), seemingly in an attempt to break out of the mire. Currently, this is doing little more than adding to the confusion. The first three generations of languages are not very difficult to explain. First-generation languages are machine languages, in which instructions are particular sequences of ones and zeros that digital computers can understand. Second-generation languages, assembly languages, are a step up, as they permit programmers to use meaningful abbreviations for machine-specific instructions in place of the incomprehensible ones-and-zeros form. Each instruction in an assembly language translates directly to a machine language instruction through the use of a tool called an assembler. Thus, the language form is still primitive and unstructured. Third-generation languages (3GLs), often called high order languages (HOLs), provide a major step up in abstraction. HOL instructions represent more abstract forms of instructions, no longer dependent on the particular set of machine instructions provided by a particular computer. These HOLs provide a general-purpose form for expressing the procedure to be followed by the computer. HOLs are typically translated by a tool called a compiler into machine-level instructions that can be understood by the computer. If an HOL is standardized, then the same set of instructions in that language should provide the same result on computers manufactured by different companies. Beyond the use of 3GLs comes the concept of communicating with the computer in more abstract ways yet. Entering into the domain of 4GLs, one finds more confusion than agreement. Unlike the first three language generations, there has been no single approach used for accomplishing this concept of abstraction. In fact, this concept goes beyond the conventional idea of a computer language, to tool sets. In effect, a 4GL is a set of tools that automatically, or semi-automatically, translates human instructions in some abstract form into instructions understood by the computer [Martin 86] [Wojtkowski 90] [Appleby 91] [Ghezzi 87]. A 5GL requires the use of knowledge-based systems [ANSI/IEEE 90] [Connors 94], a characteristic of many 4GLs. There is no distinct generation-type jump between languages described as 4GLs and 5GLs. Hence, these two language types are considered together in this discussion. The power of a tool set refers to the ease with which tool users may develop a software system. Moving toward 4GLs and 5GLs generally means improving the power of a tool set. Certainly, for the sake of ease of development, the more powerful the better. However, this is not the only concern. In studies of the use of 4GLs in software development, the quality of the software produced by a 4GL is often lower than the quality of a similar system produced by a 3GL [Misra 88] [Verner 88]. The key is in the quality and maturity of the tools behind the development in either case. It is important to choose a powerful tool set that can also develop good quality software. Otherwise, the initial gains in productivity may be quickly lost as soon as performance requirements are not met or changes need to be made to the system. Communicating with a computer in more and more abstract ways is a desirable goal because it is the way humans will continue to use automation more and more effectively. However, when moving to this higher level of abstraction, the concerns are better discussed in terms of capabilities of tools and tool sets, rather than in terms of language generations. When considering the capabilities of various tool sets, one of the major concerns is whether the software developed using these tool sets can be moved to different hardware and operating system platforms. It is also important to know whether a tool set can be moved to a new platform. Software Engineering Factors The discussion below begins with software engineering in general. The remaining subsections discuss the topics for which software engineering factors are included in Table 3 – Method and Process, Metrics and Measurement, Application Domains, Software Reuse, Reengineering, Development Environment, and Education and Training. Software Engineering Boehm defines software engineering as "the application of science and math by which the capabilities of computer equipment are made useful to man via computer programs, procedures, and associated documentation" [Boehm 81]. Others have extended the definition to emphasize that engineering is generally a concern with large, complex systems. Hence, software engineering is the discipline of building software systems, and its major concern is managing complexity. Business today demands sophisticated computing capabilities. Even the software products used for office automation (word processors, spreadsheets, etc.) have become large and complex in the process of meeting user needs. The issues involved in creating large, complex software are many and varied. They include the issue of computer language, but that is just one element of software engineering. Many of the other important software engineering factors are discussed in the following subsections. Method and Process Establishing methods for developing software systems has been an issue of software engineering since before it was called software engineering. Practitioners are always looking for better ways of doing business, and, in the young software disciplines, many development methods have been introduced. Over the years, these methods have matured, been refined, and in some cases been replaced by, or incorporated into, new methods. Today, there is much discussion about object-oriented methods, as these largely subsume the older function-oriented and data-oriented methods. In spite of many types of arguments about the old versus the new, the issues of real interest are the ways in which the newer methods incorporate the best characteristics of older methods and then extend them. Object-oriented methods have taken the strengths of function-oriented methods in describing function and the strengths of data-oriented methods in describing data, and they have combined these strengths into a different overall way of viewing a system. The importance of the current trends in methods is that they are being refined to better manage the complexities of larger and larger software systems. Newer methods continue to address the issues of scaling up from small systems to large and even huge systems. The future may well see methods being developed that have new names and paradigms. However, they will undoubtedly incorporate the best ideas of today’s methods, and then they will extend them to handle complexities even better. The important issue is that methods must be able to deal with issues of complexity, no matter how large the scale of the software system involved. A related consideration is the process used for managing a software development project. This process must include consideration for the methods used, but other issues are equally important. In particular, the process must consider that software development is a people-oriented business, and people need a structured and disciplined environment in which to do cooperative work. [Humphrey 89] The most important aspect of the development process is that it should be well defined before any development work begins. This is the most effective way a project can be properly managed to ensure positive results. An effective process must be predictable, consistently meeting cost and schedule projections, while yielding products complying with user expectations. It must provide a plan for producing a product, while improving an organization’s capacity to produce better products. The process must have a defined framework that is flexible, understandable, powerful, and refinable. The process must always promote solid software engineering tenets, and this includes how languages are employed. Another issue closely related to method and process is standards. Standards are important in any type of production, and software production is no exception. Before discussing standards, it is important to understand what the term means. The ANSI/IEEE Standard Glossary of Software Engineering Terminology defines standards as "Mandatory requirements employed and enforced to prescribe a disciplined uniform approach to software development, that is, mandatory conventions and practices are in fact standards" [ANSI/IEEE 90]. Accepted standards may assume many forms. They may be the result of a formal process of defining, refining, and approval, or a collection of commonly used practices that have proven effective. They may have the backing of official agencies such as ISO, ANSI, and the DoD, or be adopted and supported less officially by the software community at large. Certainly, large companies can encourage the use of practices that become de facto standards because of widespread use. However they are defined and supported, standards can make people more productive with computers. The de facto industry standards have had a significant impact on computing. For example, the Unix operating system has become a useful industry standard. After many years, it has become an operating system that is available on many different computers, supporting a more uniform look across many platforms. This has occurred because customers wanted it that way, because they could be more productive if they did not have to learn to use a different operating system on every different computer. Thus, Unix has served to provide some measure of hardware independence. Nevertheless, there are still many different Unix dialects, because the definition of Unix was never rigorously or uniquely defined. As a result, the transition from one Unix-based system to another is not always painless. The success of the Unix strategy of a consistent interface has been exploited in other products as well. Many software vendors strive to provide the same look and feel in their products, regardless of what hardware and operating system combination is the target. This technique certainly assists the users, as they must transition among many, fundamentally different, computer systems. The role of standards in the language domain is equally important to consider. There are two principal ways in which language standards today have evolved. The contrast can be readily seen by comparing the Ada language standard with the standard for the C/C++ language family. The Ada language was defined before Ada was supported by compilers, and the standard is supported by the various standards organizations. From the beginning, any Ada compiler had to comply with the established, written standard. Compilers for Ada are validated against the standard definition in order to determine compliance. The language standard is reviewed on a periodic basis, language changes are suggested, studied, either approved or rejected, and then the standard is changed. This process has recently unfolded with the Ada 95 definition. As before, compilers are validated against the new standard definition. In other languages, such as C and C++, there are standard definitions that are also supported by the standards organizations. However, there is a significant difference between these standards and the Ada standard. Unlike Ada, the C standards have been written and approved after the language was developed and put into use (as of this writing, the C++ standard has not yet been finalized). The result of this is that many dialects of C and C++ exist, and they have significant differences among them. Thus, while C is highly touted for its portability, in fact, the porting characteristics can be quite poor if different dialects are involved. Proponents of the C approach to standards creation argue, legitimately, that C has been more responsive to rapidly changing needs in the software community. Without the ponderous standards review process, language changes can be incorporated more quickly. The price that has been paid has been the development of the many dialects that may or may not be compatible. Recognizing the need to bring language changes to the marketplace more quickly, while not compromising the integrity of a single language definition, the Ada community is looking toward streamlining the standard review process. Instead of looking at the entire language before changes are made, incremental releases of language updates may become the norm. This approach will promote evolutionary change to keep up with emerging language technology, while assuring a stable and consistent language definition for the future. [McCarthy 95] Standards can make the difference between smooth sailing and total chaos. There is little doubt in the marketplace today about the merits of standards, although available standards have very different approaches to creation, to review, and to compliance. The nature and rigor of a standard must be understood in order to predict how effective it may be for a particular problem. Since the computer industry is too young to have just one set of accepted standards, an organization must choose from among available computer industry standards very carefully. The nature of the standards used in the original development process will have long-reaching effects as a product matures. Support for development method to be used – the support provided by a language for the particular development method chosen. Any computer language can be used with any of the development methods. However, different languages provide varying degrees of support for particular methods. The amount of support provided by a language for the development method of choice should be used to determine a rating for this factor. For example, if an object-oriented method is to be used, then an object-oriented language will provide better support than other languages. Support for other methods is usually less clear cut, but the key is the ability of the language to express the elements used in the method of choice. For example, if the method chosen is structured analysis/structured design, a 4GL or 5GL would provide poor support because they do not express programs in a procedural fashion. Support for development process to be used – the support provided by a language for the particular development process chosen. The development process used is largely language independent. However, in some cases the language of choice can provide support for the process. For example, if the process emphasizes risk reduction, Ada was developed with risk reduction in mind, enforcing consistency and abstractions where possible. Assembly languages, on the other hand, are wide open and leave all enforcement up to the programmer. Most other languages are somewhere in between. Although a language can support only a portion of the concerns of risk reduction, any type of help is important to the development of a high-risk system. Another example would be the role of language when prototyping is a part of the process. Some 4/5GLs were developed with prototyping in mind and can support a much more efficient prototype development than most other languages. In this case, it may be that a 4GL or 5GL would be chosen as the prototyping language, and another language would be chosen for full system development. This factor would be of particular interest in making a language decision only if a specific element of the development process is identified that can be supported better by some languages than others. Compatibility with standards to be used – the compatibility of a language with the standards chosen. Language standards are not considered here since they are considered in Table 2. Many standards are language independent. However, some languages are more compatible than others with certain standards. For example, if Unix is chosen as a standard, C and C++ are certain to be compatible, since C was originally developed specifically for use with Unix. On the other hand, an assembly language for one hardware platform would be incompatible with a standard specified for a different hardware platform. This factor should only be chosen as important if language-related standards (not language standards) are considered important. Metrics and Measurement It is impossible to make a determination of how good a software product is, or whether the current software development process is effective, without making some quantifiable measurements. Measuring software is difficult, so it is often not done, but this is also the reason that software disasters are still so common. In fact, without measurements, disasters sometimes are not even anticipated until the day the software is to be deployed [Jones 95]! Management has little control over a project, and hence little ability to improve either the process or the product, without being able to establish a quality baseline and then to measure against it. The difficulty with measuring software is determining what is to be measured and how to measure it. The things to be measured, along with their specific numerical results, are often referred to as metrics. Software metrics often do not lend themselves to the precision found in the results of more physical measures, such as a length measurement. However, it is important to have an indication of the usability of a software system, for example, even though this measurement is largely subjective. It is also difficult to know what to measure for some software quality metrics, such as maintainability. However, the effort to define meaningful metrics for software development, and to consistently gather measurements for them over all development projects within an organization, is management’s way to ensure adequate system quality as well as to effect continuing improvements in the development process. Tool support for collecting metrics – the availability of metrics collection tools for a language. The only reasonable way to consistently measure most metrics is to use automated tools. The tools do not take the place of management involvement with metrics. Rather, they enable management to regularly collect consistent measurements without spending an inordinate amount of time doing it. Management must still determine what metrics to track, how to interpret the results, and, based on that interpretation, what actions to initiate to improve the process and product. This factor is only looking at tool availability, not specific products. A survey of appropriate vendors and dealers should reveal how readily available such products are for a particular language, and this will provide a basis for a rating. Application Domains It seems apparent that, although there are certain principles and methods that can be applied to any type of software, the specific use for the software also makes for some distinct differences among different types of applications. The various types of applications are said to be in different application domains. A general categorization of application domains could include management information systems (MISs), real-time systems, and command and control systems [DoD 94]. Much more specific real-time domains might include flight control systems, nuclear safety systems, or visual simulation systems. These are just examples of hundreds of domains that could be defined, and there would probably be a lot of overlap in the domain definitions. The important issue here is not to try to categorize all possible domains, but rather to emphasize the concept that every software system has much in common with other systems. Defining an appropriate, specific application domain should be the first step in defining any new software system, for this leads to the ability to build on foundations that have already been laid for other systems in the same domain. Ultimately, all systems within a domain share many foundational concepts, and knowledge of one system can provide insight into another. Support for application domain – the support provided by a language for the application domain of interest. Some languages are considered general-purpose languages, for use in many applications domains, while others are much more specific to a particular domain. As a general rule, the domain-specific languages will provide better support for the domain than general-purpose languages, although a general-purpose language may provide adequate support. The worst situation is to try to apply a domain-specific language outside of its intended domain because its support for another domain is generally poor. Most 4 and 5GLs are domain-specific languages. In rating this factor for a language, its general or specific nature should be determined. If it is a general-purpose language, it should be rated with respect to how well it has been used within the domain in question. A domain-specific language should be rated high if it is intended for the domain in question, and low otherwise. Software Reuse Much emphasis is now being placed on making better use of the investment that has already gone into the development of similar systems. Every new system developed today, no matter how different it may seem to be from any others in existence, has many similarities with existing systems. There is no good reason these new systems should be started from scratch. There are many difficulties associated with the concept of software reuse, and this is not the place to discuss them in detail. The point here is to establish software reuse as an important issue. Reuse can take the form of buying a commercial product off-the-shelf (total reuse), or any part of a system can be reused, including design, documentation, and testing efforts from previous systems. An important new sub-discipline just beginning to get a lot of attention in the software engineering world is domain engineering. This is a very specialized area that concentrates on reuse and encourages the use of techniques for creating systems that are reusable within specific application domains [DoD 94]. Much more will be heard about reuse in coming years. This is ultimately where software productivity should show dramatic improvements. However, the predictions that expected this to have already occurred were premature. Today, we find truly significant amounts of reuse only in some very narrowly focused application domains. There are many difficult problems that must be solved before significant reuse becomes a reality throughout the world of software development. One of the important characteristics of reused code is the language in which it is written. Different languages may be mixed in an application, so it is not necessarily a problem if the code to be reused is in a different language from the primary development language. However, different languages support reuse differently. It is particularly helpful for reused code to be well structured and to provide a well-defined interface. Support for structuring architectural framework – the support provided by a language for structuring an application framework for a software system based on a defined software architecture. A software architecture is a high-level description of the structure of a software system, just as an architect’s drawing is a high-level description of the structure of a building. Software architectures hold the key to large-scale software reuse and significant increases in productivity in developing new software systems. Although an architecture is a language independent concept, the realization of an architecture in an application framework (code template) lays the foundation for the software implementation. The framework provides the basic structure for the subsystems and major components of the system, along with a definition of the interconnections and interfaces to these subsystems and components. With this in place, developers can work independently on the implementation of a subsystem or component, knowing how it will interface with the rest of the system (use other components and have other components use it). If a framework is valid for many applications within an application domain, not only can it be reused, but components, and even subsystems, that have already been developed for it may also be reusable. This factor is looking at the support provided by a language for structuring an architectural framework for the application, or it could be that a reusable architectural framework already exists for the application domain. The framework is of interest for structuring the current system, but, if it is to be developed as a part of the application development, an even bigger consideration is its suitability for reuse in future systems within the same application domain. Hence, the suitability of the language for producing such a framework is important. A language, such as C++, that supports encapsulation of abstractions, provides good support for this factor. A language, such as Ada 95, that supports structuring large scale abstractions such as subsystems and partitions, as well as smaller scale abstractions such as abstract data types, provides particularly good support for this factor. The key in rating this factor is in whether an architectural framework already exists in a language, or in how much support the language provides for architectural abstractions—components, subsystems, partitions, threads, data abstractions, etc. Availability of code generators – the availability of code generators for a language within the application domain of interest. Code generators are tools that can generate code in a specific language from a description of the system design. This description can be given in a number of different forms. For example, graphical design descriptions are often used as the basis for generating an application framework. These descriptions usually do not provide enough detail to be used as the basis for generating more than a framework. In some very narrow application domains, code generators can be used to generate major portions of an application, complete with much detail. These generators are tailored to the application domain, so they do not follow a general pattern. One example is a generator for an information system that uses forms for expressing the system design. The particular nature of the narrow application domain can be captured in the type of data collected from the forms, permitting much of the detail to be a part of the generated code. Note that often the code generator is itself considered to be a 4GL. In rating this factor, consideration should be given to the availability of code generators for the application domain. Availability of components – the availability of components for a language within the application domain of interest that can be reasonably expected to be useful. Code components for specific abstractions, large or small, exist for any language that has been used for any significant length of time. The keys are how likely the components are to fit the needs of the current project, and how easy useful components are to find. If components have been developed specifically for reuse within an application domain, then they are good candidates for reuse within that domain. On the other hand, if an organization just keeps a library containing code from previous projects, but those projects do not share a common architecture, the reusability of components in the library is questionable. It is often, if not usually, easier to redevelop the component than to make the necessary changes to an existing component when the component was not specifically developed with reuse in mind. Also, if the candidate components are in a well-structured reuse repository (whether within the organization or in an outside entity), this will facilitate being able to find components of interest. If the candidate components are just archived "somewhere on a system" or "somewhere on a network," it will be very difficult to find useful components, or even to know if there are any useful components. Hence, when rating this factor, several issues should be considered. Try to determine the extent to which components within the application domain are readily accessible in the language of interest, the ease of finding suitable components, and the likelihood that the components will be useful once they are found. Reengineering Most organizations have made a large investment in one or more significantly sized software systems. As these systems become inadequate for today’s requirements, many organizations are realizing they do not have to throw this investment away. To begin with, it can provide a good start for the system that will replace it. All parts of the old system are candidates for reuse, as discussed in the previous subsection. When considering how to replace an old, outdated software system, several choices are possible. The first should be to consider reengineering it. A system is a good candidate for reengineering if the old system has a good basic overall architecture that can be used as a basis for the new system, and if the new system—meeting all its new requirements—can be constructed from this framework more cost-effectively than developing a new replacement system. It is usually not easy to make a good decision on what is most cost-effective, but it is well worth the effort. It is probably the case that far too many replacement systems are still being built as new systems, rather than being reengineered from the old systems they are to replace. However, reengineering can also be risky. If good software engineering practices are not used to ensure that the new system does not contain the problems of the old system, then the reengineered system will either not meet the updated requirements, or else it will end up being much more expensive than originally expected (because the old problems are much more expensive to remove once they are a part of the code). A dilemma arises with reengineering if an organization decides to change the language used for implementing the updated system. The goal of reusing as much as possible from the old system is in conflict with the goal of using a different language. However, if the new language is chosen with care, it can be mixed with the old one in the same application. The use of multiple languages is standard practice in large systems today. Where libraries of proven, reliable functions already exist in one language, it is desirable to use them, no matter with what language they were created. The new language of choice can be used for all new development, as well as for replacing modules that are outdated, inadequate, or incorrect. In time, the new language will become the predominant language for the system. Meanwhile, the software system can be incrementally updated, remaining responsive to current needs in the most cost-effective manner. Compatibility with reengineering plan – the compatibility of a language with the system reengineering plan in terms of support for system requirements and support for being able to use components of the existing system. If a system is to be reengineered, the choice of primary language for the reengineered system is critical. It is easiest, but often not the best long-term choice, to use the same language as the current system. The current language must be rated according to whether it can meet the goals of the reengineered system. If other languages are considered, then they must be rated with consideration for the above discussion on the use of multiple languages. A language will rate high in compatibility with a reengineering plan if it can facilitate meeting the goals of the plan. This usually means it should provide good support for the new features of the system—new capabilities, larger size, etc. It also must provide a good capability for interfacing with components of the old language that will continue to be used, even if just temporarily. Development Environment The development environment consists of everything used in the software system development, and it is also used for reengineering as well as all other forms of maintenance. The environment includes the hardware platform(s), operating system(s), and all the software tools used to create a software system. If an environment contains automated tools for supporting more than just creating and compiling code, it is often referred to as a CASE environment. One of the new buzzwords is to call it an integrated-CASE, or I-CASE, environment if all the tools work together by sharing information. As would be expected, CASE tools and the integration of tools are not simple issues. There is much debate as to what kinds of tools are most needed, and integration is a matter of degrees, with debates as to how much is enough integration. The real issues are involved in examining the development environment for appropriateness. What was appropriate in the past is not adequate for the future. Much of the drudgery of software development can now be automated, and much more should be, to permit software professionals to spend their time on real science and engineering. Unfortunately, as discussed below in the Education and Training subsection, neither the preparation nor the expectations of those receiving degrees in computer science, information systems, computer engineering, software engineering, or the like, is often adequate for moving into the future of a mature software discipline. Compatibility with existing tools/environments – compatibility of a language with existing development tools/environments. If the budget is tight, and it always seems to be, then using existing tools/environments is very attractive. First, however, these existing resources should be examined to determine if they will be adequate for use in developing the new system, whether they will be used as is or whether other tools will be added. If this examination determines that existing resources will be used, then it is very important for the language to be compatible with these resources. Many parts of a development environment have little or nothing to do with language. For example, a configuration management tool will generally work on any type of files. However, any tools that deal with code recognition or generation are language dependent. This factor should be rated with consideration for how many of the still usable existing resources are language dependent, and whether or not they will still be useful for the given language. Tool support for performance requirements – the availability of language-related tools for determining software performance characteristics. Most systems have requirements for specific types of performance. In some cases, it may be critical for certain calculations to be completed within a specific length of time. In other cases, a requirement may be for the system to be able to respond to user input or to retrieve data from a database within a specified length of time. Whatever the requirement, it may be considered important to have tool support for determining the performance characteristics of the system. This factor looks at the availability of such tool support for each development language in question. Tool support for security requirements – the availability of language-related tools for evaluating and/or enforcing software security requirements. Security issues are typically difficult and complex. Tool support could make dealing with security issues more straightforward. Such tools could be language dependent. For example, a tool could ensure that software is free of certain language constructs, or certain usage of language constructs, that may not be considered secure. This factor is only an issue if the tools are dependent on language in some way. Tool support for interoperability requirements – the availability of language-related tools supporting interoperability across multiple platforms and/or software applications. It is often an important requirement that a software system be able to communicate with legacy systems or COTS products as if they were an integral part of the software system. This capability is referred to as interoperability. It is a method of communication through which the software system can work with the data used by the legacy or COTS system, and language translation is done automatically and is transparent to the user. It is a seamless form of communication, although it can involve the use of middleware, such as object request brokers. In a more indirect type of communication, the data coming from or going to the legacy or COTS system would have to go through a separate translation step, such as being translated to ASCII form. This indirect type of communication is not transparent to the user, so it is more cumbersome and time-consuming. It also usually results in the loss of information. Interoperability is an important concern here if the tools supporting this capability are dependent on language. Tool support for maintenance requirements – the availability of language-related tools supporting system maintenance requirements. Software maintenance is a term that has been adapted from the computer hardware industry. Software maintenance refers to any modifications made to software, whether they are to fix problems or to improve capabilities. The notion of easily modifying software has always been one of its appealing points. Unfortunately, it is also most misleading. Many people are mistakenly led to believe that changing software is an easy business, so there is no reason to put great effort into its original creation. Nothing could be farther from the truth. An analogy is useful here. Legos are very flexible, and it is fun to build things with them. It is also very easy to tear them apart and change what is built. This makes them a nice form of entertainment for individuals who like to build things. Legos would not be appropriate, however, as a material for constructing buildings. Likewise, it can be fun for an individual to build and modify small software creations in an unstructured fashion. However, this would not be an appropriate approach for a group of software professionals to use in building large, complex software. Unlike small systems that may never require much in the way of maintenance, most of the lifetime of a large system will be spent in maintenance. Hence, maintenance requirements should be a consideration for any significantly-sized new software system. This factor should be considered if a specific type of language-related tool support is important for meeting those requirements. For example, reverse engineering can be an important technique for documenting the current structure of a system or as a first step in reengineering a system, but reverse engineering is very difficult and error-prone without the use of an automated tool. Availability of bindings/libraries required – the availability of required bindings and libraries that can be easily used within a language. Supporting libraries provide a very important form of reusable software. A binding is a special type of supporting library that provides a set of interface calls permitting direct access to the capabilities of a particular tool from the development language. In rating languages with respect to this factor, it is necessary to set a level of expected library support and then rate each language on how well the actual availability of libraries measures up to the expectation. If a language is able to use libraries made for another language with reasonable ease, those libraries should also be considered in the availability for the language being rated. Availability of compiler for platform to be used – the availability of compilers for a language on the platform to be used. It is good practice to use an integrated approach to selecting supporting hardware and software for a development project, making final selections based on established system requirements. However, the hardware/operating system platform for a system is sometimes dictated to the software staff from the very beginning. In this case, it is essential that an acceptable compiler that runs on that platform be available for a language. It should be noted that in some cases, such as with embedded systems, the actual software development might be done on a different platform than that which will run the final system. In such cases, an acceptable cross-compiler must be available from the development platform to the final system platform. A survey of appropriate vendors and dealers should reveal how readily available such products are for a particular language, and this will provide a basis for a rating. Education and Training Good software will not be produced without good people, and there are many good software professionals in the work force today. However, these people need the right education and training before they can perform their work properly. Unfortunately, the software disciplines are so young that the variation in programs among different colleges and universities is tremendous. Computer science should be the science supporting the study of computer software. However, most computer science curricula today emphasize building software more than studying its scientific, and thus quantifiable, underpinnings. Furthermore, many graduates are prepared to build little more than toy programs when they receive their degrees. Many people working in the software industry have degrees with names such as Information Systems, Computer Science, or Software Engineering. The curricula these people studied were individually defined by the institution they attended, and these curricula address software issues in various ways. Only a few individual programs deal with the issues of building large, complex software systems, an activity that requires the cooperative effort of many people. Eventually, curricula dealing with the issues of large, complex software systems should be called Software Engineering degree programs. Today, however, software engineering is a discipline that is still included in many computer science programs. It has not even been around long enough to be accredited as an engineering discipline by the recognized engineering accrediting group, the Accreditation Board for Engineering and Technology (ABET). Software engineering is the discipline of building more than just toy programs. Some day, software engineering graduates will be properly prepared when they receive their degrees, but today it is hard to even know what their degrees will be called. With the variability in the background of software professionals today, continuing education is all the more important for them. It is common practice for professionals of all types to spend about two weeks per year in continuing education programs to keep current in their disciplines. Without this, they fall behind in knowing how technology has progressed and what new techniques are available for their professions. In the software disciplines today, professionals are commonly not permitted to take time for continuing education. This is often because their organizations are always in a time crisis. The truth is, organizations cannot afford not to let their people have the opportunity to keep up with technology. In fact, for software professionals, two weeks is probably not enough. Most need courses and interactions with fellow professionals to both catch up and keep up. This could require twice as much time, or even more. Many companies in other countries, particularly in India, Japan, and Europe, are spending around 5 percent of their annual software revenues on education and training. In contrast, American companies average only about 1.5 percent. The American software industry is probably on the brink of a crisis if this practice persists. [Quann 94] [Yourdon 92] It is essential that an organization recognize that there is no substitute for good people, there is no substitute for good education and training for those people, and there is the necessity to keep their knowledge current. Knowledge currency includes learning new languages where appropriate. Extent of education/training completed – the extent of the required language-related education and training already completed by the project staff. For this factor, it is necessary to determine the extent of education and/or training that is required of staff members if they are to perform well on project development. Then a rating is given for how much of that education and training has already been completed if the language in question is used for development. It may seem more reasonable to rate how much education/training is required for a language rather than how much has been completed. However, in the rating system we are using, a high rating is better than a low rating, and that would not be the case for a rating of how much education/training is required. Hence, this factor looks at the opposite sense of this issue. Assessing the extent of required education/training before rating individual languages is also useful for establishing the real level of preparation that is necessary for various staff members. This is an area in which artificial qualifications are often set, based more on who is available than on the real requirements of the project. Availability of qualified professionals – the availability of qualified professionals, with the required language skills, who could augment the current project staff. This is an issue of concern if an organization must bring in new people to work on a project. As with the previous factor, it is necessary to first determine the qualifications required of the new people. Then, a rating is given by determining the availability of people with those qualifications, including the appropriate preparation in the language in question. If the professionals available do not have all of the necessary qualifications, then the rating will depend on how much additional education/training will be necessary to prepare them for the project using the language in question. Availability of required education/training – the availability of language-related education and/or training courses that will be required to prepare the staff for the project. In most cases, some amount of education/training is necessary to prepare a staff properly for a new project. This factor should be rated according to how readily available that education/training is, particularly that which is specific to the language in question. Availability can be determined in a number of ways, including searches of trade publications and professional journals, as well as inquiries to appropriate electronic news groups. Meeting Requirements The goal of using software engineering and dealing with all of the software engineering factors discussed above is to produce good software systems. The most important aspect of any software system is that it meets the requirements of its users. All of the above factors are directed toward effectively meeting system requirements, and each plays an important role. To look for one particular factor to improve an organization’s ability to produce software is to oversimplify the problem. Software engineering is difficult. It requires bringing together the right methods, defined process, technology, tools, languages, and people, mixing in the right standards, education and training, and work environment, and then providing the right level of management direction, to be successful.

Sections

1

2

3

4

5

6

7

Appendices

A	B	C	D	E	F	G	H	J
K	L	M	N	P	Q	R	S