ACM Stand.最新文献

{"title":"A software engineering standards framework for nuclear power","authors":"J. Harauz","doi":"10.1145/240819.240823","DOIUrl":"https://doi.org/10.1145/240819.240823","url":null,"abstract":"ION The second requisite is that the requirements in the standard must be sufficiently abstract so as not to unnecessarily limit the methods used or freeze the technology employed for any particular process. Methods, notations and formats evolve and improve over time, but the fundamental requirements that provide the degree of confidence in the software product remain, for the most part, stable. The need for sufficient abstraction also applies to the documentation requirements within the standard. It is necessary to define documentation requirements in an “abstract manner” that allows for the partitioning of documents (such as multiple design 134 StandardView Vol. 4, No. 3, September/1996 ★","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"45 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1996-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115421872","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Developing a configuration management tool compliance standard","authors":"T. Vollman","doi":"10.1145/240819.240828","DOIUrl":"https://doi.org/10.1145/240819.240828","url":null,"abstract":"m Automation of software engineering activities through tool use has not been as successful as xexpected. In part, this is due to the difficulty of understanding a tool’s capabilities and performance characteristics, so that its usefulness for the organization can be assessed. The development of a standard for third-party certification of configuration management tools is about to begin. This article addresses the steps necessary to develop this standard, including identifying a broad base of participation, gaining the necessary international support to initiate the project, and ensuring that the effort can be completed in a reasonable amount of time. In addition, the result must maintain the balance necessary to be valuable to and welcomed by its three audiences: configuration management (CM) tool users, tool evaluators, and tool manufacturers. Moreover, insight into the standards development process is provided by addressing the boundary conditions which must be met: conformance with ISO/IEC guidelines and regulations, consistency with other standards, both existing and in the final stages of adoption, and liaison with various organizations. utomated support for software engineering processes (using, for example, CASE tools, environments, or workbenches) has not been as successful as many had expected. Of the various possible causes for this lack of success, such as the immaturity of tools and technology, the two most common are a lack of organizational readiness and commitment, and a misunderstanding of what a tool will and will not do. The newly adopted IEEE 1348, A Recommended Practice for the Adoption of CASE Tools, will help organizations establish realistic expectations for the use of automated tools in software engineering. An ISO/IEC technical report on the same topic is also being prepared. A major source of dissatisfaction among tool users is their perception that tools frequently don’t perform as advertised or as expected. Their disappointment is usually the result of inadequate tool evaluation. Evaluating complex technologies is an expensive, time consuming task that requires special expertise. Few organizations have the resources to evaluate a tool thoroughly enough to come to a full understanding of how it would perform in that organization’s environment. While it is not clear what constitutes a sufficient level of understanding, the difficulties experienced by organizations in adopting CASE clearly indicate that that level is not always reached. One way to alleviate this problem is to provide for thirdparty evaluation and certification to ensure that a tool meets certain specific requirements. In 1995 two new international standards were adopted which provide the framework for an ambitious undertaking: the development of a configuration management (CM) tool compliance standard.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"49 1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1996-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128827806","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"A CSL view of applications, portability, scalability, and interoperability","authors":"G. Fisher","doi":"10.1145/234999.235005","DOIUrl":"https://doi.org/10.1145/234999.235005","url":null,"abstract":"he Computer Systems Laboratory (CSL) of the National Institute of Standards and Technology (NIST), part of the U.S. Government’s Department of Commerce, has promoted portability, scalability, and interoperability of applications through conformance testing and measurement activities and through support of voluntary industry standards development. The first Federal Information Processing Standard (FIPS) adopted for Federal government use was the voluntary industry standard for ASCII. CSL’s view of portability, scalability, and interoperability stems from a pragmatic approach to the information technology (IT) market. CSL, along with organizations involved in the voluntary industry standards process, is striving to help define and promote interface, protocol, data format, services, and other standard specifications that will broaden the base of portable, communicating applications within the Federal inventory, and that will enhance the competitiveness of U.S. industry in the world market. CSL is actively involved in the evolution of portable, scalable, and interoperable environments that will support mission-critical applications in numerous domains. CSL views portability as providing the mechanism to move applications, including software, data, users, and documents, from one platform to another with minimum changes or training requirements. Scalability extends the portability concept to broaden the operating environments in which an application can execute, for example, from standalone personal computers to massive, distributed, client/server systems. Interoperability provides the capability for applications to communicate with each other reliably and to exchange information both syntactically and semantically. CSL’s limited resources will be most effectively used in the future by focusing on interoperability, especially by providing leadership in conformance testing. The mix of standards and other specifications applied to specific environments for development of new systems and integration of legacy systems will require the continued cooperation of industry, government, and academia. Through the definition of standard interfaces, services, data formats, and protocols, and the implementation of conformance testing, consumers can receive a measure of assurance that products meet standard requirements. sv T","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"33 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1996-06-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116006932","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Too soon, too late, too narrow, too wide, too shallow, too deep","authors":"B. Meek","doi":"10.1145/234999.235007","DOIUrl":"https://doi.org/10.1145/234999.235007","url":null,"abstract":"m What makes standards succeed or fail is the subject of much speculation, often during late-night chat. Speculation it always remains: firm conclusions are never reached, or do not bear the scrutiny of cold and sober dawn. Anecdotal evidence is not in short supply, and case studies can be done, but little can be translated into general principle. Standards, it seems, are sensitive plants; one will “take” and thrive, while another, to all appearances equally fit, will struggle to survive at all. ne thing is certain: technical excellence is not sufficient for success. More worryingly, it is demonstrably also not necessary. Some of the anti-standards brigade (and some cynics who claim to be basically pro-standard) even claim that a successful standard cannot be technically excellent, because it is bound to be a compromise between conflicting interests, or because it will be obsolete by the time it gets established, or both. That proposition will not be discussed here, but will be taken instead as a starting point. It is assumed that, as IT professionals, we want to make a standard “succeed,” both technically (to be adequate to the task) and practically (to become accepted and used). We know that many IT standards succeed in one sense or the other, but very few succeed in both. Note that the technical requirement is to be adequate to the task, not to be the best achievable, a point pursued elsewhere [Meek 1995]. Technical and practical objectives don’t always lead in the same direction. We sometimes hear it argued that there’s nothing worse than a bad standard (see e.g., von Sydow [1990])—but sometimes that a bad standard is better than none. Like so much in this area, the answer is not clear cut. It depends on what the aim of the standard is, its context, and the nature of its badness. And even if “adequate” versus “best achievable” is not in itself an issue, what constitutes “adequate” can be, though doubt can be reduced by having clear objectives and conformity rules [Meek 1995]. So, given that we cannot guarantee that a standard will succeed, what can we do to ensure that our standard will be of adequate or better technical quality without putting its chances at risk, so that, should it thrive, it will be seen to be a good standard, rather than “dreadful, but it’s all there is,” or worse? To succeed in practice, our standard will have to meet a need: a need which is perceived; which is regarded as important; and which cannot be met in any other way than by a standard. Many factors will influence this process; many quite outside the control of the standards-makers. Two strong factors are timing and sizing, of which the second has two O Too Soon, Too Late, Too Narrow, Too Wide, Too Shallow, Too Deep","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"192 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1996-06-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121624542","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Standards: what's in it for me?","authors":"A. Doniger, Nigel Goodwin","doi":"10.1145/234999.235006","DOIUrl":"https://doi.org/10.1145/234999.235006","url":null,"abstract":"m The upstream oil and gas industry (exploration and production, or E&P) is positioning itself for long-term success by elevating the intellectual pursuits of its workforce. This elevation entails a shift in focus from data and information to knowledge and wisdom (Figure One). The new vision of success is being realized through the combination of three elements: integrated business processes, teams of knowledge workers, and the tools to support both. & P business processes are now viewed in the context of the overall life-cycle of the asset (that is, the oil and gas field) (Figure Two). Professionals are no longer organized into functional silos, but rather into collaborative teams of specialists (Figure Three), and they require new types of tools to realize their targets. Standards and standard practices are essential to those tools. Petrotechnical Open Software Corporation (POSC) was incorporated in 1990 to meet the demand for industry-specific standards to support the tool implementations.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"9 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1996-06-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122376292","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"The business of application portability","authors":"David Rowley","doi":"10.1145/234999.235000","DOIUrl":"https://doi.org/10.1145/234999.235000","url":null,"abstract":"m The focus of this issue of StandardView is on application portability. At its most basic level, portability is an economic issue. It centers on leveraging an existing investment and deploying it in new ways. It’s about being able to run an application written for one platform on an entirely different platform. It’s about saving time and money, and maintaining quality. Portability is fundamentally a business issue, not a technical one. ortability is also an old issue. Portable Fortran in the late 1960s first gave rise to the need to move scientific applications from outdated equipment to the then brand-new. From the earliest days of application development, rapid advancement of computer hardware and fierce competition among platform vendors have created the need for moving applications. Business requirements change, integration requirements become more stringent, mergers and acquisitions force previously separate MIS groups to exchange data and applications, and to adopt new platform standards. All these factors create a landscape where application portability is key to competitiveness and to the abilities to innovate and provide high-quality application support to line areas.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"4 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1996-06-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128824130","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"The myth of application source-code conformance","authors":"Stephen R. Walli","doi":"10.1145/234999.235002","DOIUrl":"https://doi.org/10.1145/234999.235002","url":null,"abstract":"m Branding and certifying applications source-code conformance to POSIX standards and The Open Group specifications demands attention every few years. The general premise is that an organization purchasing POSIX.1-certified or XPG4-branded systems should be able to purchase corresponding applications. This reasoning defeats the purpose of source-code portability specifications, and has no economic foundation. It confuses applications users with applications developers, and provides information to purchasing management that is grossly out of context. here have been at least two cases in the past two years within the POSIX community where people outside the standards development group have claimed that without POSIXconforming applications to run on their POSIX-conforming implementations, they see no value in these specifications. The Open Group is now demanding a similar program. If such programs for applicationconformance branding are implemented, I believe they will fail due to poor economic and technical foundations, and will confuse customers making standards-based purchases. To support this argument, I first describe source-code portability and porting and their place in current applications development practices. I examine source-code portability standards, discuss how implementation conformance is defined, and what conformance certification entails. I then apply this discussion to the problem of application source-code conformance and certification. We define the following terms:","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"164 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1996-06-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134542094","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Applications programming interface for Windows: a timely standard","authors":"R. Farnum","doi":"10.1145/234999.235003","DOIUrl":"https://doi.org/10.1145/234999.235003","url":null,"abstract":"m The Windows environment produced by Microsoft is arguably the most common programming environment in the world. It exists on millions of computers. Software designed for that environment represents a tremendous investment on the part of Microsoft and other software organizations. By standardizing on the Applications Programming Interface for Windows (APIW), this investment can be safeguarded for the future. This article describes APIW efforts and explains why the industry is behind them. icrosoft’s Windows is really a set of functions, libraries and other system elements that make up an interface between DOS and conforming applications. This set of functions is called the Windows Applications Programming Interface (API). For Windows, the API also helps software programs manage windows, menus, icons, and other graphical user-interface elements. Microsoft and other software developers have made a massive investment in the Windows API, of both dollars and time—so massive that it dwarfs almost all other commercial software development activities to date. Analysts have estimated that Microsoft to date has invested over $50 million in the Windows interface, and that it is selling over one million copies per month. There are no estimates of the investment made by other development organizations, but it is large. The investment is justified by the huge marketplace: Windows on Intel-based microprocessors is estimated to make up 80% of the desktop market. Windows currently supports a 16-bit interface (the “traditional” Windows function calls) and a 32-bit interface, Win32 (the Windows 95 and the Windows NT function calls). The two interfaces are not necessarily compatible with each other. Most existing Windows software deals with the 16-bit interface. The release of Windows 95 in August 1995 increased the number of Win32 programs in the marketplace.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"72 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1996-06-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133387305","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"DoD strategy on open systems and interoperability","authors":"Curtis Royster","doi":"10.1145/234999.235004","DOIUrl":"https://doi.org/10.1145/234999.235004","url":null,"abstract":"m The DoD information infrastructure cannot be built by one company or industry alone. It can only be achieved through consensus and cooperation between the private and public sectors and through discussions across national borders. The 5Cs Interoperability in Figure One show how the National Information Infrastructure (NII) Committee on Applications and Technology views interoperability. The JIEO/Center for Standards was part of the NII committee and contributed information.1 he 5Cs of Interoperability must be achieved in order for DoD to develop a single information infrastructure that will (1) produce useful information; (2) provide equity of access; (3) protect privacy and security; and (4) enhance competitiveness, education, and national wellbeing. Information technology (IT) standards is the primary issue underlying every application that DoD must use to achieve this single information infrastructure. IT standards are needed for DoD to establish an integrated, transparent, and interoperable information infrastructure that the WARFIGHTER perceives as seamless and without boundaries. Vendors play a major role in developing shrink-wrap products to help DoD achieve interoperability and open systems solutions. DoD does not believe interoperability is best achieved where interface specifications (i.e., application to application, application to appliance, appliance to network, and network to network) are not open.2 The IT industry has problems when a single powerful and well-capitalized provider (such as Netscape or Microsoft) refuses to release its application program interface specifications to obtain a public consensus. The DoD’s goal is to achieve interoperability through a public consensus process that results in nonproprietary specifications such as the Internet. To be accepted as an “open system” requires compliance with the Technical Architecture Framework for Information Management (TAFIM) and the DoD Personal Computer (PC) policy. A companion document called the Information Technology Standards T DoD Strategy on Open Systems and Interoperability","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"68 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1996-06-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126310752","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Software portability: still an open issue?","authors":"P. Tanner","doi":"10.1145/234999.235001","DOIUrl":"https://doi.org/10.1145/234999.235001","url":null,"abstract":"m Portability is widely regarded as a done deal, but, although progress has been made, the problem has not been solved; if anything, it is becoming more complex. The commercial impact of non-portability increases as information systems become more distributed and interoperability becomes a higher priority. This article explores the issues behind the issues and their technical and commercial impact. We also outline some possible solutions being evaluated, particularly within the X/Open community of IT buyers and suppliers. Proposals such as a “what-works-withwhat” information base and procurement assurance mechanisms are explored. pen systems are about interfaces— defining, stabilizing and managing them so that they can effectively hide implementation details—and about building a portfolio of conformant products. This process, coupled with healthy competition among suppliers, leads to commercial benefits such as flexibility and value in IS solutions. Already, in the mid-range server market, it is not difficult to produce server applications that are portable (and therefore commercially available) across a wide range of platforms. Platforms evolve as technology advances and applications evolve with them. This portability has now gone far beyond the operating system and embraces the user interface, networking, data access, security, messaging etc. Intense work on system and network management is necessary to complete the picture. Meanwhile, Microsoft has done “the same thing” on the client platform—but without the openness that most people want. As the dominant supplier of the client platform they also define standards. This is certainly good. The economics of the client platform cannot support the heterogeneity of the server market. Similarly, the cost of development and distribution for multi-platform software does not fit the client model that covers the full spectrum from personal applications to those of international corporations and governments. It would have been convenient to have had one, not two, paradigms of standardization, but this simply did not happen. Users and application developers have coped well despite the increasing functionality and complexity of application solutions that today’s businesses demand. These two paradigms must now come together in a client/server market where application solutions are increasingly deployed across Windows®-based clients and open, generally UNIX®-based, servers. This situation poses a new set of challenges for both user and application developer. O Software Portability: Still an Open Issue?","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"12 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1996-06-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128989027","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}