| Appendix G |
Guidelines for Choosing a Computer Language: Support for the Visionary Organization |
|
Appendix G: Examples
The following examples illustrate the use of the process described in this document. These are only hypothetical examples and are not intended to represent any real set of requirements or products. However, they are representative of real types of problems and the existing state of technology in language products. Example 1 - Small DatabaseA system is required to organize approximately 20,000 sets of data that are to be collected. The system must be able to show relationships among various types of data, and reports must be created that summarize this information. John has been tasked with creating a database and working with this data. Funds are tight, and the need is immediate. This is a small and straightforward database requirement. Although the current projection is for 20,000 sets of data, John anticipated that this might grow to a number twice or three times that size, especially if working with the data turns out to be easy. However, the application will remain relatively simple and straightforward. He recognized that future company growth could eventually make it desirable to incorporate this database of information into a larger database with a much broader range of requirements, and, if this should happen, a small database would be unable to scale up for the new requirements. However, there is no basis for projecting such growth at this time, so a small and straightforward database application would be required for at least a few years. John talked with his boss, Jane, about how this software requirement should be met. Jane consulted Table 1, and found that a COTS product or 4GL would be ideal for handling this requirement. Jane and John worked together to try to find a suitable product. They determined that there is one database product that the company already owns, purchased more than three years ago. There are also a number of COTS products readily available in stores and catalogs, some of which are called 4GLs and some of which incorporate SQL, itself considered a 4GL. The primary concerns with choosing a product to use were:
Jane and John determined that the product currently owned by the company would not be able to meet the capacity requirements of the database. Hence, they began to evaluate a product to purchase. They came up with three candidate products that they investigated in some detail. They examined product evaluations in popular weekly computer publications, and they tried to find people they know who have used each of the products. They also talked with the vendors of the products about each of their concerns listed above. When their evaluation process was complete, John determined that one of the products will not be suitable because both its capacity limits and its usability are questionable. The other two products are reasonably comparable in capabilities and in purchase cost. The deciding factor was that one will run on the Macintosh computer John already uses at his desk, while the other would require the purchase of a product which runs Windows. In this case, the extra expense of purchasing a new computer platform is not justified, so Jane authorized the purchase of the Macintosh 4GL product. Example 2 - Large Information Management SystemA large organization with thousands of employees requires the integrated management of large amounts of data, along with automated support for five different manufacturing processes. The system must automate all of the functions that control each of the individual manufacturing processes, and it must also be able to organize and manage all of the data related to these processes. In addition, it must track all of the relevant information on all employees working with these processes, including training, experience, professional licensing and certification, and hours worked on specific projects. Information from this system must be shared with the corporate personnel system which handles functions such as payroll on all employees of the organization, including many in support positions that are not directly included in any of the manufacturing processes. Many varieties of management reports must be created that summarize both large and small portions of data in the system. Betty is the organization’s lead software engineer, and she has been tasked with determining how the organization will get this automated system. Some funds are available to develop a new system, and the need is immediate. This is a large and complex system which could grow into a very large and immensely complex system as the organization grows. Betty worked with Bob, her boss, to develop a plan for accommodating this computer system requirement. Bob consulted Table 1 and determined that this is a system that will probably need to be developed in-house. The organization’s business plan called for Bob to manage the development of the new system, with Betty as the lead technical engineer. Their first step was to determine what similar systems exist, either in other divisions of their organization or in other companies. COTS and 4GL or 5GL products would be explored for possibly satisfying some well-defined parts of the system requirements, not excluding the outside chance that an existing product could satisfy the whole requirement. Bob and Betty determined that no existing product could satisfy all of their requirements, but a number of potential COTS and 4GL products could be used to satisfy some parts of the requirements. For example, a robust database product, along with a product using the Common Object Broker Architecture (CORBA) for interoperability among heterogeneous systems, could be used to manage the immense amount of data that must be stored, updated, and retrieved by many different people in various locations. The important consideration about COTS products is that they must be able to satisfy a requirement as is, because the COTS advantage is immediately lost if the organization tries to modify the product in any way, no matter how tempting that may seem to be. Bob made the decision that Betty’s software group will develop a system to meet the requirements. The spiral model will be used to guide the development process because it emphasizes risk management, and risk is high for such a large project. The process will use prototyping, both because it will help to mitigate the development risk (making sure the system will meet requirements through feedback collected early and often) and because it will provide a system with minimum functionality relatively quickly. This minimal system will be evolved into the robust system required for full functionality over time. Betty got Bob’s concurrence to use an object-oriented methodology in the system development. One of the software groups has recently completed a relatively small project using an object-oriented approach because Betty is trying to establish a repeatable development process that is founded on solid software engineering principles. The object-oriented trial was a decided success, even though there were some up-front training costs associated with it, so it is time to commit to this process and invest in it. Bob and Betty are anxious to get going with this project because there is a lot of pressure coming from the corporate level to get it done quickly. However, they know better than to jump in to start system development without proper planning. This includes budgeting, selecting an appropriate development language, and selecting appropriate development tools. Betty considered choosing COBOL as the development language because she and most of the software staff have used COBOL in the past for database applications. Although some of the junior engineers are talking a lot about C++, several others have become enthusiastic about Java, and some managers at a higher level are talking about Ada, this is a traditional COBOL-type application. However, Bob insisted on following the guidelines for choosing a language first. This has never been done in the past, and the software group is now making good progress in establishing a solid, repeatable process. Bob wanted to go through the language selection process at least once to be sure to establish a good language foundation for computer systems to be developed both now and in the future. Referring to Table 2, Bob and Betty agreed that no languages needed to be added to the table, but they added support for information management as a language characteristic to the table. Then they agreed that the most important language characteristics to use in their language decision process were: complexity management, maintainability, mixed language support, portability, reliability, standardization, and support for information management. They laid out Table 2 in a spreadsheet, as shown in Table G-1, with appropriate weights given to each of the language characteristics they chose as important and a 0 weight given to all others. They had to add ratings for each language for the characteristic support for information management, and these new ratings are shown in Table G-1. Note that only a 4GL or 5GL that supports the specific need within the information management domain would be considered at this point, so that column was rated at 10. Also, the languages that provide general-purpose support for many domains were rated at 5. When this rating process was completed, calculations were done according to the Rating Formula, and the results are shown in Table G-1. As stated in the explanation for using Table 2, the results were rounded to one digit, with no decimal places. This rounding was included in the spreadsheet set-up so it was done automatically. There is too little precision in the numbers used (they are all one significant digit estimates) to be able to make more out of the results than is shown in Table G-1, and even those results were taken as estimates.
Based on the results of Table G-1, C, FORTRAN, and Assembly were ruled out as contenders. The remaining language ratings, along with the total weight used to determine those ratings, were entered into the first row of Table 3. Bob again employed Betty's assistance in determining which software engineering factors were most important and in establishing ratings for each language for those factors. The factors chosen for consideration were support for development method to be used, tool support for collecting metrics, support for structuring architectural framework, availability of components, compatibility with existing tools/environment, and extent of education/training completed. They were going to choose support for application domain, but then Betty realized that had already been considered in Table G-1 when they had added support for information management as a language characteristic. Table G-2 shows the spreadsheet derived from Table 3, with three languages eliminated, the chosen factors weighted appropriately and other factors weighted 0, and ratings given for each language for each chosen factor. As for Table G-1, the calculations were done according to the Rating Formula. After completing Table G-1, Betty noted that the object-oriented languages had come out better than older languages, even though object-oriented programming support was not one of the language characteristics chosen. Although the project would use an object-oriented method, that was taken care of in Table G-2 with the selection of support for development method to be used. As a part of the process of filling in the ratings in Table G-2, Betty studied the material in the appendices concerning the various languages. From this she learned a lot about the capabilities of these object-oriented languages. She discovered that they also tend to provide support for software engineering, although some provide better support than others. When Table G-2 was first completed, Betty had not yet chosen availability of components as a software engineering factor, and Ada 95 and Java were both tied with the highest score of 7. She reevaluated the important issues that could be a tiebreaker in determining which language to choose and determined that availability of components for reuse would be it. Rather than just making the final language decision immediately, however, she decided to add the availability of components software engineering factor into the process and let the process work. This brought the Java rating down to a 6. Then she did a sensitivity analysis on the results to see if a small change in some rating or weight would also bring the Ada 95 rating down. It did not. She decided that she could live with a decision to use either Ada or Java as long as good development products could be found to support it, but she would start with a decision in favor of Ada 95. The availability of products in the next steps would determine if this were a viable choice. Bob asked Betty to develop a list of candidate development products that use Ada 95 and then evaluate them, using Table 4 and Table 5 to structure the process. Because this is a large, expensive development effort, Betty spent a lot of time considering potential development products. She examined suites of tools, and then she looked at possible combinations of individual tools. She also considered 4GLs that may be used for developing very specific parts of the system. She came up with four candidate tool sets, all including an integrated tool set as at least a part of the complete candidate set. The next step was to use Table 4 to consider costs. Betty laid out the expected expenses for each cost factor for each tool set. She was careful to include training as a significant cost so there would be enough budgeted for this important need. She considered that most of the software staff would need training in the areas of language and object-oriented methods as a part of how to use any of the tool sets. In some cases, little additional hardware or software would be needed for system development because the tool sets would work with computer platforms already in-house, but in other cases new hardware and/or software would be required. Once Betty estimated all of the cost factors as well as possible at this point, she entered them into Table 4. Two of the complete tool sets had significantly lower cost than the others, at least partly because they required little additional purchase of hardware or software. They stood out as the best candidates at this point, so Betty entered them into Table 5. However, if neither of them would turn out to have high enough quality, she was prepared to go back and consider the others.
For each of the tool sets, Betty then had to provide a rating for each product characteristic with a non-zero weight. This was the most time-consuming part of the planning process. Betty contacted the vendors for each of the products considered and asked for evaluation copies. She also contacted some of her colleagues in other parts of her organization and in other companies to get as much information as possible from people who had used any of the tools. She put a small cadre of people in the software group to work on developing a scenario to properly test out the capabilities of the candidate tool sets, making sure they could perform all of the required functions and testing the performance of the tools in the process. Meanwhile, she assigned five experienced and trusted workers, who already had some experience with object-oriented technology, as the tool evaluators, and she assigned them to start learning about Ada. Betty also decided at this time that an overall product rating greater than 5 would be acceptable. She wanted to make this decision now, before the products were rated, so she would be sure to set an unbiased goal. When the evaluation copies of the tools arrived, Betty sent the evaluators off to test each of the tools and tool sets, each working independently to exercise the planned scenario. They were each instructed to come up with a rating between 0 and 10 for an entire tool set for each of the product characteristics already chosen. None of them knew what weights had been assigned to each of the product characteristics or what Betty had decided was an acceptable rating, and they had all been instructed not to talk with each other about the ratings or the evaluation process until everyone had turned in an evaluation report. When they had all completed the entire scenario on both tool sets, Betty collected the reports and established the ratings for each product characteristic for each tool set. She did this by adding together the five ratings from the five evaluators for each product characteristic for a tool set, dividing by 5, and then rounding the result to the nearest integer. The results of this process are the ratings given in Table G-3. Finally, Betty laid out Table 5 in a spreadsheet and used the Rating Formula once again. The results are shown in Table G-3. Again, note that the overall ratings have been rounded to one digit, with no decimal places, because to show more digits would be misleading. Tool Set B came out best in Table G-3. This did not necessarily mean that Tool Set B would be satisfactory. However, Betty had already determined that a rating greater than 5 would be acceptable, so Tool Set B’s rating of 7 was good enough to get it selected. As it turned out, Tool Set A would also have been acceptable. Betty showed the product evaluation results to Bob, who enthusiastically approved the use of Ada 95 as the development language and the purchase of Tool Set B. It was then time to start training everyone who would be involved in the development in the appropriate areas.
|
| < Previous Page | Search | Contents | Tables | Next Page > |
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 |