Slide 14.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.

1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process McGraw-Hill, 2004 Stephen R. Schach srs@vuse.vanderbilt.edu

3 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter Overview l Cost–Benefit Analysis l Risk Analysis l Improving the Process l Metrics l CPM/PERT l Choice of Programming Language l Reuse l Reuse Case Studies l Portability l Why Portability?

4 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Cost–Benefit Analysis l An information system will be constructed only if it is cost-effective to do so l A popular technique for determining this –Compare estimated future benefits against projected future costs –This is termed cost–benefit analysis

5 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Cost–Benefit Analysis (contd) l Tangible benefits are easy to measure, but –Intangible benefits can be hard to quantify directly l A way of assigning a dollar value to intangible benefits is to make assumptions –In the absence of data, this is the best that can be done –Better assumptions mean better data and more accurate calculation of intangible benefits l The same technique can be used for intangible costs

6 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Cost–Benefit Analysis (contd) l Cost–benefit analysis is a fundamental technique for deciding –Whether a client should computerize his or her business and, if so –In what way l For each strategy, costs and benefits are computed –Select the strategy for which the difference between benefits and costs is the largest

7 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Risk Analysis l A risk is an event or condition that can cause the delivery of an information system to be –Canceled –Delayed –Over budget, or –Not to meet its requirements

8 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Risk Analysis (contd) l Risks include: –The project may not meet its time constraints –The moving target problem can result in time and cost overruns –The delivered information system may not meet the client’s real needs –The developers may not have the needed expertise

9 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Risk Analysis (contd) –The hardware may not be delivered in time –The CASE tools may not be available, or may not have all the needed functionality –A COTS package with the same functionality may be put on the market while the project is underway

10 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Risk Analysis (contd) l The first step –List the risks in a project l Risk management is the process of –Determining what the risks are, and then –Attempting to mitigate them »Minimize their impact

11 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Risk Analysis (contd) l Example 1: –To mitigate the risk that part of a proposed information system will not work »Build a proof-of-concept prototype l Example 2: –To mitigate the risk that the development team will not have the necessary skills »Provide training

12 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Risk Analysis (contd) l Risks are like diseases –Sometimes they go away spontaneously –They often get better or worse without intervention –Minor ones merely need to be watched, but –Major ones need to be cured (mitigated)

13 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Risk Analysis (contd) l A risk list must therefore be maintained l For each item on the list, the following items are recorded: –A description of the risk –The priority of the risk (critical, significant, or routine) »The priority can change, in either direction –The way the project is impacted by the risk –The name of the person responsible for monitoring the risk –The action to be taken if the risk materializes

14 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Risk Analysis (contd) l Risk analysis is integral to the Unified Process l During the inception phase –The risk list is drawn up –Attempts are made to mitigate the critical risks –The use cases are prioritized according to their risks l l During the elaboration phase –The risks are monitored –The risk list is updated »Particularly with regard to priorities

15 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Risk Analysis (contd) l During the construction phase –The risk list is again updated l During the transition phase –Attempts are made to find any previously unidentified risks l Risk analysis does not terminate when the product is delivered to the client –The risk list must be maintained through the entire life cycle of the product

16 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Improving the Process l The global economy is critically dependent on computers –And hence on information systems l Many governments are concerned about the information system development process –This includes the activities, techniques, and tools used to produce information systems

17 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Improving the Process (contd) l The Department of Defense founded the Software Engineering Institute at Carnegie Mellon University in Pittsburgh l A major success of the Software Engineering Institute is the Capability Maturity Model (CMM)

18 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Capability Maturity Models l The capability maturity models of the Software Engineering Institute –A related group of strategies for improving the process for developing information systems »(Maturity is a measure of the goodness of the process itself)

19 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Capability Maturity Models (contd) l The Software Engineering Institute has developed CMMs for –Software (SW–CMM) –Management of human resources (P–CMM; the P is for “people”) –For systems engineering (SE–CMM) –For integrated product development (IPD–CMM), and –For software acquisition (SA–CMM) l In 1997 it was decided to develop a single integrated framework for maturity models –Capability maturity model integration (CMMI)

20 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Capability Maturity Models (contd) l SW–CMM is presented here –SW–CMM incorporates technical and managerial aspects of the development of an information system l Underlying principle: –The use of new techniques cannot result in increased productivity and profitability –Problems are caused by the way the process is managed –Improving the management of the process will result in »Improvements in technique »Better-quality information systems, and »Fewer projects with time and cost overruns

21 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Capability Maturity Models (contd) l Improvements in the process cannot occur overnight –The SW–CMM induces change incrementally l Five different levels of maturity are defined –An organization advances slowly toward the higher levels of process maturity

22 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Capability Maturity Models (contd) l Maturity Level 1: Initial Level l No information system management practices are in place –Instead, everything is done ad hoc –Most activities are responses to crises –The process is unpredictable –It is impossible to make accurate time and cost estimates l Most development organizations worldwide are still at level 1

23 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Capability Maturity Models (contd) l Maturity Level 2: Repeatable Level l Basic information system project management practices are in place –Planning and management techniques are based on experience »Hence the name “repeatable” –Measurements are taken »The essential first step in achieving an adequate process –Without measurements, it is impossible to detect problems before they get out of hand –Also, measurements taken during one project can be used to draw up realistic schedules for future projects

24 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Capability Maturity Models (contd) l Maturity Level 3: Defined Level l The process for information system development is fully documented –Managerial and technical aspects of the process are clearly defined »Continual efforts are made to improve the process l At this level, it makes sense to introduce new technology such as CASE –In contrast, “high tech” only makes the crisis-driven level 1 process even more chaotic

25 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Capability Maturity Models (contd) l A number of organizations have attained maturity levels 2 and 3 –Not many have reached levels 4 or 5 l For most companies the two highest levels are targets for the future

26 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Capability Maturity Models (contd) l Maturity Level 4: Managed Level l A level 4 organization sets quality and productivity goals for each project –These two quantities are measured continually –Action is taken if there are deviations from the goals

27 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Capability Maturity Models (contd) l Maturity Level 5: Optimizing Level l The goal of a level 5 organization is continuous process improvement –Statistical quality and process control techniques are used to guide the organization l The knowledge gained from each project is utilized in future projects –The process thus incorporates a positive feedback loop

29 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Capability Maturity Models (contd) l To improve its process, an organization –Attempts to understand its current process –Formulates the intended process –Determines and ranks in priority actions that will achieve this process improvement –Draws up and executes a plan to accomplish this improvement l This series of steps then is repeated –The organization successively improves its process

30 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Capability Maturity Models (contd) l Experience with the capability maturity model –Advancing a complete maturity level usually takes from 18 months to 3 years »But moving from level 1 to level 2 can take up to 5 years »It is difficult to instill a methodical approach in a level 1 organization

31 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Capability Maturity Models (contd) l For each maturity level there are key process areas that an organization should target to reach the next maturity level l Example: The key process areas for level 2 include –Configuration control –Quality assurance –Project planning –Project tracking –Requirements management

32 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Capability Maturity Models (contd) l These areas cover the basic elements of information system management: –Determine the client’s needs (requirements management) –Draw up a plan (project planning) –Monitor deviations from that plan (project tracking) –Control the pieces that make up the information system (configuration management), and –Ensure that the information system is fault free (quality assurance)

33 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Capability Maturity Models (contd) l A level 5 organization is far more advanced than a level 2 organization l Example: –A level 2 organization is concerned with quality assurance, that is, with detecting and correcting faults –The process of a level 5 organization incorporates fault prevention, that is, ensuring there are no faults in the first place

34 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Capability Maturity Models (contd) l An original goal of the CMM program was to raise the quality of defense software –By awarding contracts to only those defense contractors who demonstrate a mature process l The U.S. Air Force stipulated conformance to SW– CMM level 3 by 1998 –The Department of Defense as a whole subsequently issued a similar directive l Today, the SW–CMM program is being implemented by development organizations worldwide

35 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Other Process Improvement Initiatives l The International Organization for Standards (ISO) –9000-series standards l Set of five standards for industrial activities –Standard ISO 9001 for quality systems –Standard ISO 9000-3, guidelines to apply ISO 9001 to information systems

36 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Other Process Improvement Initiatives l There is an overlap between ISO 9000 and CMM, but they are not identical –ISO 9000 is not process improvement –The stress is on documenting the process »With an emphasis on measurement and metrics –ISO 9000 is required to do business with the E.U. –Also by many U.S. businesses, for example, GE –More and more U.S. businesses are ISO 9000 certified

37 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Other Process Improvement Initiatives l ISO/IEC 15504 is an international process improvement initiative, like ISO 9000 –It was formerly known as SPICE »(Software Process Improvement Capability dEtermination) l An international process improvement initiative –Started by the British Ministry of Defence (MOD) –It includes process improvement, software procurement –It extends and improves CMM and ISO 9000 –It is a framework, not a method »CMM and ISO 9000 conform to this framework –Now it is referred to as ISO/IEC 15504 »Or just 15504 for short

38 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Costs and Benefits of Process Improvement l Implementing information system process improvement leads to increased profitability l Example 1: –Hughes Aircraft spent nearly $500,000 between 1987 and 1990 for assessments and improvement programs –During this 3-year period, Hughes Aircraft moved up from maturity level 2 to level 3 –Hughes Aircraft estimates its annual savings to be of the order of $2 million

39 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Costs and Benefits of Process Improvement l These savings have accrued in number of ways, including –Decreased overtime hours –Fewer crises –Improved employee morale –Lower turnover of information technology professionals

40 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Costs and Benefits of Process Improvement l Example 2: –The Equipment Division at Raytheon moved from level 1 in 1988 to level 3 in 1993 –A twofold increase in productivity resulted, as well as –A return of $7.70 for every dollar invested in the process improvement effort l More and more organizations worldwide are realizing that process improvement is cost effective

41 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CMM and CASE l Many CASE environments automate a manual process –If an organization selects a CASE environment that enforces an inappropriate process –Use of that CASE environment is counterproductive l It is worse when an organization at CMM level 1 or 2 uses a CASE environment –Because there is no defined process in place

42 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CMM and CASE (contd) l Every organization should use CASE tools –And there generally is little harm in using a workbench l However, an environment imposes an automated process on the organization that uses it l If the organization is at level 3 or higher –A CASE environment is appropriate to aid information system production by automating that process l But if the organization is at levels 1 and 2 –No process as such is in place –Introduction of a CASE environment leads to chaos

43 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Metrics l Measurements (or metrics) are essential to detect problems early in the information system process –Before they get out of hand l Metrics serve as an early warning system for potential problems

44 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Metrics l A wide variety of metrics can be used, such as –LOC measurements –Mean time between failures –Effort in person-months –Personnel turnover –Cost –Efficiency of fault detection

45 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Metrics (contd) l Gathering metrics data costs money –Even when data gathering is automated, the CASE tool that accumulates the information is not free –Interpreting the output from the tool consumes human resources l Numerous different metrics have been put forward –Which metrics should an information system organization measure?

46 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Metrics (contd) l There are five essential, fundamental metrics: –Size (in lines of code, or better) –Cost (in dollars) –Duration (in months) –Effort (in person-months), and –Quality (number of faults detected) l Each metric must be measured by phase or workflow

47 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Metrics (contd) l Data from these fundamental metrics can highlight problems such as –High fault rates during the design workflow –Code output that is well below the industry average l A strategy to correct these problems is then put into place l To monitor the success of this strategy, more detailed metrics can be introduced

48 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CPM/PERT l More general types of management information are also needed l Example: –Critical path management (CPM), otherwise known as –Program evaluation review techniques (PERT)

49 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CPM/PERT (contd) l When developing an information system –Many hundreds of activities have to be performed –Some activities have to precede others –Other activities can be carried on in parallel

50 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CPM/PERT (contd) l Example: –Two activities are started at the same time –They can be performed in parallel –Both have to be completed before proceeding with the project as a whole –The first takes 12 days, but the second needs only 3 days

51 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CPM/PERT (contd) l The first activity is critical –Any delay in the first activity will cause the project as a whole to be delayed l However, the second activity can be delayed up to 9 days without adversely impacting the project –There is a slack of 9 days associated with the second activity

52 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CPM/PERT (contd) l When using PERT/CPM, the manager inputs –The activities –Their estimated durations –Any precedence relations

53 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CPM/PERT (contd) l The PERT/CPM package will then –Determine which of the hundreds of activities are critical –Compute the slack for each of the noncritical activities –Print out a PERT chart showing the precedence relationships, and –Highlight the critical path »The path through the chart that consists of critical activities only »If any activity on the critical path is delayed, then so is the project as a whole

55 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CPM/PERT (contd) l There are 12 activities and 9 milestones –A milestone is an event used to measure progress, such as the completion of an activity or set of activities l Starting with milestone A, activities AB, AC, and AD can be started in parallel l Activity FJ cannot start until both BF and CF are finished

56 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CPM/PERT (contd) l The project as a whole is complete when activities HJ, FJ, and GJ are all complete l Completing the whole project will take at least 25 days

57 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CPM/PERT (contd) l The critical path is ACGJ –If any one of the critical activities »AC, CG, or GJ is delayed in any way, the project as a whole will be delayed l However, if activity AD is delayed by up to 15 days, the project as a whole will not be delayed –There is a slack of 15 days associated with activity AD l Now suppose that activity AD is delayed by 15 days

59 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CPM/PERT (contd) l There are now two critical paths –Activity DG has become critical l Simply printing out a PERT chart showing the expected durations is useless –Data regarding actual durations must be input continually –The PERT chart must be updated

60 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CPM/PERT (contd) l How is the PERT data continually updated? –The task is too large for humans—a CASE tool is needed –All the information system development tools must integrated –Information of all kinds, including »Source code »Designs »Documentation »Contracts, and »Management information must be stored in a system development database

61 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CPM/PERT (contd) l The CASE tool that generates the PERT chart then obtains its information directly from the database –Thus, what is needed is a CASE environment

62 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Choice of Programming Language l In what language should the information system be implemented? –This is usually specified in the contract l But what if the contract specifies –The product is to be implemented in the “most suitable” programming language l What language should be chosen?

63 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Choice of Programming Language (contd) l Example –QQQ Corporation has been writing COBOL programs for over 25 years –Over 200 software staff members, all with COBOL expertise –What is “the most suitable” programming language? l Obviously COBOL

64 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Choice of Programming Language (contd) l What happens when new language (Java, say) is introduced –New hires are needed –Existing professionals must be retrained –Future products are written in Java –However, existing COBOL products must be maintained –Expensive software is needed, and the hardware to run it –100s of person-years of expertise with COBOL are wasted l There are now two classes of programmers –COBOL maintainers (despised) –Java developers (paid more)

65 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Choice of Programming Language (contd) l The solution: –OO-COBOL »Object-oriented COBOL—2002 l QQQ Corporation train their technical staff in –The object-oriented paradigm in general, and –OO-COBOL in particular l QQQ Corporation can then –Develop new information systems in OO-COBOL, and –Maintain existing information systems in traditional COBOL

66 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Choice of Programming Language (contd) l Where there is no clear reason for choosing one programming language over another –Use cost–benefit analysis »Management must compute costs and benefits of each language under consideration »The language with the largest expected gain is chosen –Alternatively, risk analysis can be used »For each language, a list is made of the potential risks and ways of mitigating them »The language with the smallest overall risk is selected

67 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Choice of Programming Language (contd) l Which is the appropriate object-oriented language today? –Twenty years ago, there was only one choice—Smalltalk –Today the most widely used object-oriented language is C++ –Java is in second place

68 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Choice of Programming Language (contd) l C++ is popular because of its similarity to C –C++ is a superset of C –C++ is therefore a hybrid object-oriented language –Managers therefore often assume that a C programmer can quickly pick up the rest l Conceptually C++ is quite different from C –C is for the traditional paradigm –C++ is for the object-oriented paradigm l Before an organization adopts C+ –Training in the object-oriented paradigm must be given

69 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Choice of Programming Language (contd) l Java is a pure object-oriented programming language l Education and training are even more important with Java than a hybrid object-oriented language –Like C++ or OO-COBOL

70 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Choice of Programming Language (contd) l What of the future? l Existing information systems –COBOL will remain the most widely used language l New information systems –Will be written in object-oriented languages like »C++ »Java »C#

71 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Reuse l Instead of utilizing previously developed programs, organizations all over the world develop their own programs from scratch –Why do information technology professionals continually reinvent the wheel?

72 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Reuse Concepts l Reuse –Using artifacts of one information system when developing a different information system with different functionality l Reusable artifacts include –Modules –Code fragments –Design artifacts –Part of manuals –Sets of test data –Duration and cost estimates

73 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Reuse Concepts l Two types of reuse –Accidental reuse (or opportunistic reuse) »First, the information system is built »Then, artifacts are put into the artifact database for reuse –Planned reuse »First, reusable artifacts are constructed »Then, information systems are built using these artifacts

74 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Reuse Concepts (contd) l A strength of deliberate reuse –A artifacts specially constructed for reuse are likely to be »Easy and safe to reuse »Robust »Well documented »Thoroughly tested »Uniform in style l A weakness of deliberate reuse –There can be no guarantee that such an artifact will ever be reused

75 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Reuse Concepts (contd) l Reasons for reuse –It is expensive to design, implement, test, and document software –On average, only 15% of new code serves an original purpose –Reuse of parts saves »Design costs »Implementation costs »Testing costs »Documentation costs l So why do so few organizations employ reuse?

76 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Impediments to Reuse l There are a number of obstacles to reuse: –The not invented here (NIH) syndrome –Concerns about faults in potentially reusable routines –The storage–retrieval problem –Costs of reuse l All these can be solved

77 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Impediments to Reuse l Legal issues can arise with a contract information system –The information system usually belongs to the client –Reuse of an artifact for another client constitutes theft of intellectual property

78 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Reuse Case Studies l Six case studies show that reuse is practical –They span the 25-year period from 1976 to 2000 l What reuse rates can be expected? –The theoretical maximum is 85% –The case studies show what can be achieved in practice

79 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Raytheon Missile Systems Division l Over 5,000 COBOL information systems were analyzed l Planned reuse of –Design artifacts »6 code templates (sort data, edit or manipulate data, combine data, explode data, update data, report on data) –COBOL code »3200 code artifacts l Reuse rate 60% (1976–1982) –Productivity increase of 50%

80 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Toshiba Fuchu Works, Tokyo l Industrial process control systems l Accidental reuse of –Specifications –Designs –Modules –Contracts –Manuals –Standards l Reuse rate (1985) –33% design –48% code

81 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. NASA Software l Ground support system for unmanned spacecraft control l Management permitted (but did not encourage) accidental reuse l Accidental reuse of code modules l Reuse rate (1982) –28% reused unchanged –10% reused with minor changes

82 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. GTE Data Services l Data-processing software l Reuse was strongly encouraged by management –Cash incentives when module was accepted for reuse –Cash incentive when module was reused l Accidental reuse of modules l Reuse rate –(1988) 15% reused code, $1.5 million saved –(est. 1989) 20% reused code –(est. 1993) 50% reused code

83 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Hewlett-Packard l Reuse has been implemented in many divisions of the company l Software Technology Division –Resource planning software –Accidental reuse of code modules –4.1 faults per KLOC of new code, 0.9 for reused code –Overall fault rate decreased by 51% –Productivity increased by 57% –Cost $1 million, savings $4.1 million (1983–92)

84 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Hewlett-Packard (contd) l San Diego Technical Graphics (STG) –Planned reuse of firmware for printers –The program cost $2.6 million, the savings were $5.6 million (1987–94) –24% reduction in faults –40% increase in productivity –24% decrease in delivery time –Cost of developing reusable software—11% more –Cost of reusing it—19% of developing it from scratch

85 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Hewlett-Packard (contd) l Hewlett-Packard makes a wide variety of printers –They try to have common software in all printer models l Between 1995 and 1998, for a new printer model –The effort to develop the code decreased by a factor of 4 –The time to develop the code decreased by a factor of 3 l Over 70 percent of the components of the code are reused, almost unchanged, from earlier products

86 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. European Space Agency l On June 4, 1996 –The Ariane 5 rocket blew up 37 seconds after lift-off l Cost: $500 million l Reason: –A computer tried to convert a number from one format into another –The number being converted was too large for this conversion to be possible l The on-board computers crashed, so did the rocket

87 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. European Space Agency (contd) l The conversion was unnecessary –Computations on the inertial reference system can stop 9 seconds before lift-off –But, if there is a subsequent hold in the countdown, it takes several hours to reset the inertial reference system –Computations therefore continue 50 seconds into the flight

88 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. European Space Agency (contd) l The cause of the problem –Ten years before, it was mathematically proved that the problem could not occur—on the Ariane 4 –The software was used, unchanged and untested, on the Ariane 5 –However, the assumptions for the Ariane 4 did not hold for the Ariane 5 l Lesson –Artifacts developed in one context needs to be retested when integrated into a different context

89 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Size of Reused Components l NASA –Most reused components were small l Toshiba –Many large components were reused l GTE –Many large components were reused l Reason –A strong managerial commitment to reuse is needed

90 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Portability l Every information system must be portable –That is, easily adapted to run on different hardware– operating system combinations l Hardware is replaced every 4 years or so l There are several obstacles to portability

91 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Hardware Incompatibilities l Sources of incompatibilities include –Diskette formats (PC vs. Macintosh) –Character codes (EBCDIC vs. ASCII) –Tape drives (different parities) l There is an economic reason for perpetuating incompatibilities –To force a customer to buy an expensive compatible computer »To avoid an even more expensive conversion to a cheaper incompatible computer

92 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Operating System Incompatibilities l An information system that runs under Windows will not run under –Linux –Mac OS, or –OS/370 l Problems can arise even when upgrading the same operating system –Example: Windows

93 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Compiler Incompatibilities l Information systems should be implemented in a widely used language such as –COBOL –C –C++, or –Java l Using only standard features of that language

94 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Why Portability? l Good information systems have a life of 15 or 20 years or more l Hardware usually is changed every 4 years l Solution 1: –Buy upwardly compatible hardware and operating systems –This may be expensive l Solution 2: –Ensure that software is truly portable

95 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Why Portability? (contd) l Portability should be strongly encouraged by all information technology managers, and –Especially by top management

Slide 14.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.

Similar presentations

Presentation on theme: "Slide 14.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Slide 14.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.

Similar presentations

Presentation on theme: "Slide 14.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with."— Presentation transcript:

Similar presentations

About project

Feedback