Search

The choice of programming language depends on a number of factors, such as efficiency and maintainability. With the predicted increase of the soft error rate in coming years due to technological improvements and the popularization of energy-saving techniques, the responsibility of tolerating transient hardware faults is no longer solely on the hardware-side, but is becoming more and more a software problem. Therefore choices taken throughout the software development and compilation process, such as the used programming language, are now a factor that should be taken into account. This paper evaluates the impact of the programming language in the sensitivity and vulnerability to soft errors of an application, through extensive fault injection campaigns that cover 5 benchmarks over 7 programming languages, considering the most common implementation. The results show that both the programming language and workload have a significant correlation with the occurrence of failures due to soft errors. Furthermore, since execution time varied noticeably across programming languages, applications developed in less-efficient languages showed a higher vulnerability time window in which they may be affected by soft errors.

Severity levels, e.g., critical and minor, of bugs are often used to prioritize development efforts. Prior research efforts have proposed approaches to automatically assign the severity label to a bug report. All prior efforts verify the accuracy of their approaches using human-assigned bug reports data that is stored in software repositories. However, all prior efforts assume that such human-assigned data is reliable. Hence a perfect automated approach should be able to assign the same severity label as in the repository --- achieving a 100% accuracy. Looking at duplicate bug reports (i.e., reports referring to the same problem) from three open-source software systems (OpenOffice, Mozilla, and Eclipse), we find that around 51 % of the duplicate bug reports have inconsistent human-assigned severity labels even though they refer to the same software problem. While our results do indicate that duplicate bug reports have unreliable severity labels, we believe that they send warning signals about the reliability of the full bug severity data (i.e., including non-duplicate reports). Future research efforts should explore if our findings generalize to the full dataset. Moreover, they should factor in the unreliable nature of the bug severity data. Given the unreliable nature of the severity data, classical metrics to assess the accuracy of models/learners should not be used for assessing the accuracy of approaches for automated assigning severity label. Hence, we propose a new approach to assess the performance of such models. Our new assessment approach shows that current automated approaches perform well --- 77-86 % agreement with human-assigned severity labels.

Introductory program courses often have a final project. The development of a game using programming languages learned is possible choice for this project. A large Midwestern public university has been assigning a programming project at the end of it's first semester, first-year engineering course. Previous projects have included an IR detection program and programming a train scenario. Recently, faculty have been piloting a game software design project in these courses. Student survey results have demonstrated that students prefer the game project to the other projects for many reasons including they are more enjoyable and they help develop necessary engineering skills. The results from this pilot have lead to many questions that will be explored in future studies.

We explore what can be said about the detailed modelling of problem solving ability via a stochastic semantics of a theory of software problem solving, and end with an invitation to discuss possible experiments that may lead to the practical characterisation of the problem solving ability of software teams.

The bubble display controls the sorenoid valve by PLC, generates the bubble in water, and shows the character and the figure with it. It is chiefly used in the several events. A present problem is a software problem and the operation when the display is changed because of its cable communication. It is that the displayed things are limited. Moreover, there is a fault that PLC is expencive. At this present research, both the application to communicate the data of the character and the figure drawn with the touch panel of the Android terminal with the control part on the bubble diplay by using Bluetooth and the control circuit that controlled the bubble display, were developed from the information. It became possible to output the pattern to the bubble display by drawing the pattern on the application of the Android terminal at present, and sending this to the control circuit.

of all software projects are total failures and another 40% are partial failures according to widely quoted surveys in UK, USA and Norway. Large government projects in all 3 countries have been reported with spectacular failure and expense to taxpayers (Royal Academy of Engineering and British Computer Society 2004). What is the problem? Most discussions have centered on improving the software engineering process itself: better estimation, better requirements, better reuse and better testing. No doubt all those can be improved. However, I suggest the motivation to improve them needs to be put in place first. Think about it. Most of these failures have been fully paid for! We not only pay well for failure, but the bigger the failure, the more people get paid! My suggestion is simple. Pay only when defined results are provably delivered. This requires several things: ∞ Contracts that release payment only for meaningful results; ∞ The ability to define those results, particularly qualitative ones, and particularly the organizational ones; ∞ The ability to deliver those results incrementally, thus proving capability at early stages and continuously. Note: This paper specifically addresses the software problem, but I am sure that the ideas here apply to the wider systems engineering problem to some interesting degree as well.

We present an architecture and algorithms for performing automated software problem determination using call-stack matching. In an environment where software is used by a large user community, the same problem may re-occur many times. We show that this can be detected by matching the program call-stack against a historical database of call-stacks, so that as soon as the problem has been resolved once, future cases of the same or similar problems can be automatically resolved. This would greatly reduce the number of cases that need to be dealt with by human support analysts. We also show how a call-stack matching algorithm can be automatically learned from a small sample of call-stacks labeled by human analysts, and examine the performance of this learning algorithm on two different data sets.

For an unmanned aerial system (UAS) to work seamlessly within the national airspace (NAS), it must have a way to sense and avoid any obstacles autonomously. This paper describes a monitoring system that has the ability to monitor in real-time both the hardware and software components of the UAS during flight operations and execute any actions that are necessary to handle or prevent any issues that might occur during an encounter with an obstacle as well as during normal flight. The system was implemented and all its capabilities were thoroughly tested using software-in-the-loop (SWIL) flight simulations with real-time sensor data. The results from these tests demonstrated the system's capabilities to identify a component in a critical state, a software problem, or an environmental issue and handle it in order to maintain the Airborne Sense and Avoid (ABSAA) system's full capability.

Defect causal analysis offers a simple, low-cost method for systematically improving the quality of software produced by a team, project, or organization. DCA takes advantage of one of the most widely available types of quality information, the software problem report. This information drives a team-based technique for defect causal analysis. The analysis leads to process changes that help prevent defects and ensure their early detection. The paper discusses the three principles that drive the DCA approach. It considers the impact of DCA on an organization.

In ancient times, living and working was characterized by using what nature produced and provided. Our first technologies were fire and tools such as blades, stone axes, spears and lances of varying quality depending on the capability and skills of those who made and used. Early memory and calculation tools known as tally sticks were used to record and document numbers, quantities, or even messages. Another early device is the Chinese Abacus for arithmetical calculations. In current societies we have become strongly dependent on technical systems and information technology. Technological progress has accelerated to the point that whereas historic innovations took hundreds, even thousands, of years, we now have the situation that technology can become outdated in as little as a few weeks.

The benefits of cross-training in terms of increasing responsiveness to demand fluctuations have been studied extensively in the literature. In this work, we study another important advantage of cross-training due to customer misclassification, i.e. a caller declares to face a certain problem (e.g. a hardware problem) where in fact another problem persists (e.g. a software problem). In call centers that apply no cross-training, misclassified calls need to be rerouted to agents who are able to serve the true problem, whereas cross-training enables agents to serve different problem types which reduces cycle times. We introduce two-type queueing models to study the effects of customer misclassification on cross-training in call centers. We observe that, if only a third of the agents is cross-trained, high increases in model performance can be confirmed, whereas little benefit is added by higher amounts of cross-training. We also study the effects of routing policies on cycle times.

Analyzing, diagnosing, and proposing fixes to problems in complex software is essentially a linguistic activity: we think in languages such as C and English, we analyze written problem reports, we read listings. In cognitive psychology and interpretation theory, the linguistic constraints upon cognition are well established; but with the exception of those authors working within the field of Speech Act Theory, little has been said about how these constraints affect software problem diagnosis or what we can do to overcome these constraints. This paper examines some of the linguistic aspects of software problem analysis, showing how these may contribute to the bad fix, and then describes a change specification procedure specifically designed to help development teams overcome some of the liabilities of interpreting complex software failures.

Summary The paper describes the successful sidetrack of an oil well in the Slaughter Field in West Texas using coiled tubing (CT). Several first-time CT operations performed during this workover include: Setting a whipstock in casing on CT Cutting a window with CT Using mud pulse measurement-while-drilling (MWD) with CT in a "real" well Use of a fluid-operated orientation tool for in-hole toolface changes Successful use of an "autodriller" to maintain weight on bit while drilling Directional control of the sidetracked hole proved to be ineffective due to a surface software problem. The resultant wellbore was not horizontal as planned, but instead closely paralleled the original well for much of its length. However, the previously non-productive well flowed 1000 barrels of fluid per day (BFPD) from the sidetrack following the workover.

We introduce Proteus virtual development techniques into the microcontroller I2C bus communication designs, and take the AT24C02 for example to explain the Proteus simulation software and hardware design circuit of I2C bus communication. Then we analyse the hardware and software problem in Proteus debugging and provide the solution. The Simulation results which is identical with theoretical analysis prove that the correctness and the accuracy of Proteus virtual simulation. It has very important significance in the microcontroller virtual development.

A logic error in the software of Cosmos II results in apparent malsensing of atrial signals at high rather than low sensitivity settings. The paradoxical function was found in 54 out of 87 units tested (= 62%) if the atrial sensitivity was increased and in 54 out of 87 units tested (= 62%) if the atrial sensitivity was increased and the ventricular refractory period was lengthened beyond critical limits that could be defined individually. The problem inherent in both unipolar (66%) and bipolar systems (54%) is attributed to a summation of a physiological signal and internal noise, which has to be detected at the atrial level within a specific timing window to disable atrial sensing for the next pacing cycle. The malfunction virtually disappears if the ventricular refractory period does not exceed 210 msec. It is recommended, therefore, that Cosmos II pacemakers be left at their nominal ventricular refractory value (200 msec).

We describe the case of a dual chamber rate responsive pacemaker (Relay, model 294-03, Intermedics, Angleton, TX, USA) implanted in a 68-year-old male for sick sinus syndrome, which was not working properly when programmed in the DDIR mode, thus determining occasionally a sort of "VVI" pacing. However, the pacemaker performed well when programmed in the DDDR mode. We discovered that this was not a malfunction of a single device but rather a general behavior of this family of Intermedics dual chamber pacemakers (also not rate responsive), caused by a software problem.

ICD Software Error. Loss of ventricular output resulting from an unexpected software error in a dual chamber implantable cardioverter defibrillator (ICD) is reported. A 70-year-old man with a dual chamber ICD implanted for a history of cardiac arrest and infra-Hisian block presented with acute onset of dizziness. He was found to have loss of ventricular output due to an internal software problem. The problem was corrected by software reprogramming via the programmer. This malfunction exemplifies the potential ability to correct current-generation ICD software problems noninvasively, thus avoiding the need for replacement.

Predicting the time and effort for a software problem has long been a difficult task. We present an approach that automatically predicts the fixing effort, i.e., the person-hours spent on fixing an issue. Our technique leverages existing issue tracking systems: given a new issue report, we use the Lucene framework to search for similar, earlier reports and use their average time as a prediction. Our approach thus allows for early effort estimation, helping in assigning issues and scheduling stable releases. We evaluated our approach using effort data from the JBoss project. Given a sufficient number of issues reports, our automatic predictions are close to the actual effort; for issues that are bugs, we are off by only one hour, beating naive predictions by a factor of four.

Comment: Monitoring Networked Applications With Incremental Quantile Estimation [arXiv:0708.0302], Comment: Published at http://dx.doi.org/10.1214/088342306000000619 in the Statistical Science (http://www.imstat.org/sts/) by the Institute of Mathematical Statistics (http://www.imstat.org)

This paper describes the results of a case study focusing on improving the software problem management process in TietoEnator Oyj. The research question is what kind of challenges are related to the software problem management process. As main findings, we show a list of challenges identified during the study. Those challenges include the increasing number of open and duplicate problems in the problem database, difficulties in combining existing problem management concepts with ITIL-based concepts, a lack of performance metrics such as incident turnaround times, and a lack of knowledge base. The main contribution of this study is to help IT organizations to identify the challenges and problems that are related to ITIL-based problem management.

Design technology has grown over the last thirty years in response to improved programming languages and a rapidly expanding software problem domain. Faced with rapidly developing design approaches, it is vital that a meta-study of design be accomplished periodically in order to keep this growth in perspective. Such a study is necessary to determine how design can be most effectively integrated into undergraduate computer science programs and how design should be taught and applied in industry.

We present an architecture for and prototype of a system for quickly detecting software problem recurrences. Re-discovery of the same problem is very common in many large software products and is a major cost component of product support. At run-time, when a problem occurs, the system collects the problem symptoms, including the program call-stack, and compares it against a database of symptoms to find the closest matches. The database is populated off-line using solved cases and indexed to allow for efficient matching. Thus problems that occur repeatedly can be easily and automatically resolved without requiring any human problem-solving expertise. We describe a prototype implementation of the system, including the matching algorithm, and present some experimental results demonstrating the value of automatically detecting re-occurrence of the same problem for a popular sofware product

The expansion of the patent system to embrace intangible inventions, including software and business methods, provokes continued controversy, even in the United States where the specialized patent appeals court has left few if any limits on the scope of patentable. Yet while software and business method patents overlap to some degree, they embody two distinctly different deviations from the more optimal conditions that prevail for pharmaceuticals and chemicals. The software problem can be described as the extreme functional complexity that results from the ease and dispersion of software creation. Although software appears to be an extreme case because of ...

Version 5.0 of Microsoft’s flagship spreadsheet program Excel came out in 1993. It was positively huge; it required a whole 15MB of hard drive space. In those days we could still remember our first 20MB PC hard drives (around 1985), so 15MB sure seemed like a lot.

Many problems that occur within a system are not preventable, such as, disks that run out of space, hardware failures, and stalled print queues. These problems do not just happen spontaneously but they develop over time. Through vigilant monitoring of system integrity, one can often detect a developing problem before it becomes critical. This chapter discusses system events that are clues to pending problems. A number of DCL command procedures that provide automatic problem detection and reporting are also discussed. Whenever hardware errors occur, the OpenVMS error formatter (ERRFMT), a detached process, writes an error record to the system error log file. The error log file contains a record of all system and device errors that occurred since the log file was created. ERRFMT does not send a notification message when device errors occur. Therefore, a user must monitor hardware errors using utilities. Even when disk space is carefully managed, disks run out of space. This can occur if a user accidentally creates a large file or when a software problem creates a large log file. Running out of disk space has a severe effect on users. Users trying to save documents might lose their work, or other key system tasks might fail in the middle of a large process, leaving files or databases in corrupted states. To prevent these problems, a user should periodically monitor disk space using the SHOW DEVICE command.

For improving their delivery tours, newspaper and magazine wholesalers require a practice-oriented solution to the strategic vehicle routing problem. The main tool to achieve this goal is a special software but if the most is to be gained from the existing optimization potential, it is necessary to have a detailed knowledge of the problem in its real context. This knowledge can be easily acquired by solving the problem in dialog. This paper discusses a practicable approach to the press distribution problem. It presents the situations where software tools are helpful and how they should be applied. Furthermore, a working-in-dialog procedure is described.

In general, software systems are relatively error free and support us doing our work. We could not live without these systems if we want to maintain the level of service, to which our customers have become accustomed. Most users, however, from time to time experience problems. It seems that despite all improvement efforts in areas such as specification, usability, testing and so on, software in use will cause problems, and we must find ways to live with this fact.

Automatic state exploration tools (model checkers) have had some success when applied to protocols and hardware designs, but there are fewer success stories about software. This is unfortunate, since the software problem is worsening even faster than the hardware and protocol problems. Model checking of concurrent programs is especially interesting, because they are notoriously difficult to test, analyze, and debug by other methods.This talk will be a description of our initial efforts to check Java programs using a model checker. The model checker supports dynamic allocation, thread creation, and recursive procedures (features that are not necessary for hardware verification), and has some special optimizations and checks tailored to multi-threaded Java program. I will also discuss some of the challenges for future efforts in this area.

Automatic state exploration tools (model checkers) have had some success when applied to protocols and hardware designs, but there are fewer success stories about software. This is unfortunate, since the software problem is worsening even faster than the hardware and protocol problems. Model checking of concurrent programs is especially interesting, because they are notoriously difficult to test, analyze, and debug by other methods.This talk will be a description of our initial efforts to check Java programs using a model checker. The model checker supports dynamic allocation, thread creation, and recursive procedures (features that are not necessary for hardware verification), and has some special optimizations and checks tailored to multi-threaded Java program. I will also discuss some of the challenges for future efforts in this area.

Due to an error caused by a homemade data-analysis program, on page 1875, Geoffrey Chang and his colleagues retract three Science papers and report that two papers in other journals also contain erroneous structures. (Read more.)

This chapter addresses the inten-elated issues of software reliability and readiness assessment based on open and closed software problem reports (SPRs). It describes a systematic methodology consisting of the following three steps: use of the Laplace trend statistic to determine reliability growth or decay, fitting non-homogeneous Poisson process (NHPP) models and reliability or readiness assessment. The mathematical framework pertinent to the Laplace statistic and the NHPP models is discussed at length. SPR data from commercial and military systems are used throughout the chapter for illustration and explanation.

Network coverage is an important issue for wireless sensor network. It depends on several factors including sensing model that has been used to design the network model. The sensor nodes are prone to be non-functional because of noise, battery energy depletion, software and hardware problems. Hence, it is relevant to assess network coverage considering node failure as a parameter. In the literature, coverage has been extensively studied for Boolean and shadow-fading sensing models. However, Elfes sensing model has not been considered. In this study, the authors investigate the impact of sensing model and node failure on network coverage. Also, temporal variation of coverage has been investigated. A strategy for maintaining constant coverage is proposed.

Vertical soundings were recorded hourly with the Digisonde 256 and the Artist facility during the above mentioned period. During these three months, the Digisonde 256 worked perfectly and only few hourly records are missing. Interruptions of the recording were mainly due to short mains failures. A software problem delayed the production of the output data due to the fact that we had to interact with University of Massachusetts, Lowell group to solve it. Ionospheric HF soundings, Electron density distribution, Dourbes(Belgium).

Programming language standardization is presented as a major aid in making the right language choice to solve a software problem. This is illustrated using the historical and conceptual background of the language Forth. Subsequently we summarize general aspects of a good language standard. The relation between abstraction level and standardization suitability is analyzed. The impact of standardization on software quality is determined in connection to the McCall quality model and its contribution to general language acceptance is illustrated.

This is the (slightly edited) transcript of the verbatim text of an unscheduled talk. It was given because many speakers at this Symposium have voiced their concern about the growing ‘software problem’, and some of them have mentioned the AIPS++ project as a possible step in the right direction. To quote the words of Richard Hills, in his talk about New Technologies for Astronomy”: The AIPS++ project is to build a powerful data analysis package, primarily for radio astronomy, which is based on object-oriented principles. It is being organised by NRAO but the work is being carried out at observatories all round the globe, with the participants in frequent communication by E-mail. One of the goals is to provide an environment in which it will be very easy for users to install their own specialised bits of code for particular purposes. This has been promised by other projects in the past but I am not aware of any cases where it has really been achieved. By the time it is finished the AIPS++ project will represent a very large investment of effort. It is very important that it succeeds: I hope that it does and that it will set astronomical software development on the right course for the 21st century.

The current situation in the supercomputer market is discussed. New manufacturers try to market massively parallel systems. In 1990, several new subsidiaries were founded. On the other hand, the German supercomputer project SUPRENUM was cancelled. As there are no new interesting systems compared to the workshop in 1989, the situation in Japan is discussed in some detail, although the information sources differ in figures, systems and companies. Finally, a list of supercomputer installations in Germany is provided.

There are two special problems in achieving a working PACS system, firstly capturing the data, and secondly displaying the resulting images. Unless these problems can be successfully resolved, all the rest of any PACS network is without practical clinical value, which is not to say that the problems associated with the management of such networks, the communications between the PACS components and the PAS, etc are without difficulties themselves. It was these input and Output stages that we decided to address. Since data capture from CT scanners, MRI devices, and other digital systems is essentially an electronic and Software problem, it was also decided to confine the area of study to conventional (film) radiography.

The history of computing has been dominated by continued explosive growth in the cost/effectiveness of hardware, whose benefits have been increasingly delayed by problems with programming and software. Software problems have been the subject of intensive study and research, but the results have been very slow in trickling through to practice. I have been wondering why this is, and what we might do about it.

At eleven institutes in nine European countries interactive learning programs are developed using identical hard- and software (UNIX and RMG, based on Objective-C). Topics are chosen from science, computer science and technology. The objective is to support teaching at university level and industrial training centers and to enhance qualitative understanding of basic concepts in science as well as competence in the use of quantitative methods.

The “Great pentaretraction” (“A scientist's nightmare: software problem leads to five retractions,” G. Miller, News of the Week, 22 Dec. 2006, p. [1856][1]; “Retraction,” G. Chang et al. , 22 Dec. 2006, p. [1875][2]) in the wake of one of protein crystallography's greatest blunders, while an embarrassment to the authors, nevertheless provides the rest of the field with some small measure of comfort beyond mere schadenfreude. The mistake so clearly illustrates two lessons that we aging baby boomer professors ram down the throats of our proteomically aroused graduate students: (i) that those lovely colored ribbons festooning the covers and pages of journals are just models, not data, and (ii) that you invite disaster if you don't know what your software is actually doing down there in the computational trenches. Students have a hard time subsuming these dicta into their souls for two reasons: the tyranny of authority (the vanity journals occupying the vanguard) and the inherent beauty of the macromolecular models that emerge, as if by magic, from the user-friendly crystallographic software accumulated over decades through the generous labor of the field's talented reciprocal space-cadets. This case highlights the dangers of ignoring biochemical results, conventional but logically solid, as was done in the original papers and as is now outlined in the politely flaccid news report published along with the retractions. Schuldiner's group, for instance, had shown in careful studies published in unglamorous workaday journals that the upside-down topology asserted from the erroneous structures of the multidrug resistance pump emrE could not possibly apply to the protein in its membrane home [e.g., ([1][3])]. It's too bad these results were dismissed as just old-fashioned biochemistry. 1. 1.[↵][4] 1. S. Ninio, 2. Y. Elbaz, 3. S. Schuldiner , FEBS Lett. 562, 193 (2004). [OpenUrl][5][CrossRef][6][PubMed][7][Web of Science][8] [1]: /lookup/doi/10.1126/science.314.5807.1856 [2]: /lookup/doi/10.1126/science.314.5807.1875b [3]: #ref-1 [4]: #xref-ref-1-1 "View reference 1. in text" [5]: {openurl}?query=rft.jtitle%253DFEBS%2BLetters%26rft.stitle%253DFEBS%2BLetters%26rft.aulast%253DNinio%26rft.auinit1%253DS.%26rft.volume%253D562%26rft.issue%253D1-3%26rft.spage%253D193%26rft.epage%253D196%26rft.atitle%253DThe%2Bmembrane%2Btopology%2Bof%2BEmrE%2B-%2Ba%2Bsmall%2Bmultidrug%2Btransporter%2Bfrom%2BEscherichia%2Bcoli.%26rft_id%253Dinfo%253Adoi%252F10.1016%252FS0014-5793%252804%252900240-6%26rft_id%253Dinfo%253Apmid%252F15044024%26rft.genre%253Darticle%26rft_val_fmt%253Dinfo%253Aofi%252Ffmt%253Akev%253Amtx%253Ajournal%26ctx_ver%253DZ39.88-2004%26url_ver%253DZ39.88-2004%26url_ctx_fmt%253Dinfo%253Aofi%252Ffmt%253Akev%253Amtx%253Actx [6]: /lookup/external-ref?access_num=10.1016/S0014-5793(04)00240-6&link_type=DOI [7]: /lookup/external-ref?access_num=15044024&link_type=MED&atom=%2Fsci%2F315%2F5811%2F459.2.atom [8]: /lookup/external-ref?access_num=000220553000033&link_type=ISI

The title of the article “software glitch threw off mortality estimates” (News of the Week, J. Kaiser, 14 June, p. [1945][1]) is misleading. There was no software glitch involved—the tool worked exactly as specified. The scientists overestimated the risks of fine particles in the air because they specified incorrect parameters for the algorithm. That the scientists misused their tool is not the fault of the tool. This is a blunder on the part of the scientists, not the software. [1]: /lookup/doi/10.1126/science.296.5575.1945

washington A software glitch has meant that the Near-Earth Asteroid Rendezvous (NEAR) spacecraft will have to wait another 13 months before the start of a planned orbit of the asteroid Eros, which was intended to begin next week.

Discusses computer vision-the automated analysis of visual data which has long been one of the most intractable problems in automation and robotics. Most researchers in the field believe that the current predominant approach, which regards computer vision as primarily a software problem broadly similar to speech understanding, will eventually achieve useful vision capabilities. However, a growing minority feel that real automated vision will require not just better software but also hardware that is radically different from present digital computers, hardware more capable of mimicking human vision.

Some problems on the prosthesis were discussed in this paper from the view point of human engineering. Recently, engineers have many interests on the prosthesis problem. Almost of their interests have been aimed only to the hardware, in spite of many hard problems are contained in the software.The problems on the prosthesis should be developed as a prosthesis system which is constructed of the amputee and the prosthesis.It is very important thing to develope a excellent prosthesis system not only on the hardware, but also on the software, especially on the man-machine interface problem, or it does not be usefull for the rehabilitation of the amputee.Some examples of the software problem as a section of the rehabilitation engineering, i. e., socket, human engineeing of the amputee, the alignment of the prosthesis and the rehabilitation taming, were discussed here.Human engineering is a very important technique for the developement of these problems.

The economic miracle that transformed Japan into one of the largest, most fiercely competitive economies in the world did not occur until after the Second World War. Faced with the total devastation of their industrial base, the Japanese used American financial aid not only to rebuild but also to transform the structure of their economy. By the mid-1960s and early 1970s, armed with advanced high technology and a loyal battalion of inscrutably efficient workers, Japan came to pose a serious and powerful threat to some of the world’s most prestigious economies.

Discussed a calibration software problem found on the HP85428 (GPMl calibration routine) which does not properly account for the standard offset short length when the shorting plane of the "calibration short" is not at the calibration reference plane.

When this work was originally conceived in the early 1970s, the concepts associated with the phrase “structured programming” were less clearly perceived than they are now, and the notion of “abstract data type” did not exist. While it was generally recognized that methodological approaches to the solution of software problems had enormous potential, there was neither agreement on the methodology nor much experience on which to base belief in the potential.

Sabotage of MCBIS by hospital staff endangers and disrupts the delivery of inpatient health care. Wide-spread interference, along with other implementation problems, cripples the ability of MCBIS to function properly and affects health care costs and quality of services.

In addressing the question of the high cost of software it is essential, first of all, to surround the issue in such a way that it is possible to achieve some understanding of the problem and its causes. The first question to be answered is that of whether or not software costs are, in fact, too high. In order to answer this question requires a definition of software itself. Continuing this vein of questioning obviously can lead to a circuitous path which never leads to anything but tangential conclusions about pseudo problems and pseudo causes.