A market can be made more open, more active, and more responsive to buyers and sellers if it is made more organized. The Open GIS Consortium offers a model for organizing business in rapidly advancing technology markets. “Information Communities,” groups of users with common needs, can inject requirements into an open technical committee process that produces a specification for an open interface that gives users access to diverse technologies (and related data) from all compliant vendors. OGC has used this approach to solve the long-standing noninteroperability problems in an industry characterized by exceptionally complex and heterogeneous data and processing systems. Vendors are attracted to the process not only by the promise of market growth, based on the synergy of interoperability and today's burgeoning network computing environment, but also by OGC's aggressive business development programs. OGC has the potential to expand beyond geoprocessing because “repurposing” an exiting consortium with an effective technology-independent specification process is less expensive and risky than creating a new consortium, particularly if a critical mass of interested vendors and powerful and needy users are already members.
{"title":"OGC: user-mediated technology drives vendor opportunity","authors":"L. McKee","doi":"10.1145/243492.243496","DOIUrl":"https://doi.org/10.1145/243492.243496","url":null,"abstract":"A market can be made more open, more active, and more responsive to buyers and sellers if it is made more organized. The Open GIS Consortium offers a model for organizing business in rapidly advancing technology markets. “Information Communities,” groups of users with common needs, can inject requirements into an open technical committee process that produces a specification for an open interface that gives users access to diverse technologies (and related data) from all compliant vendors. OGC has used this approach to solve the long-standing noninteroperability problems in an industry characterized by exceptionally complex and heterogeneous data and processing systems. Vendors are attracted to the process not only by the promise of market growth, based on the synergy of interoperability and today's burgeoning network computing environment, but also by OGC's aggressive business development programs. OGC has the potential to expand beyond geoprocessing because “repurposing” an exiting consortium with an effective technology-independent specification process is less expensive and risky than creating a new consortium, particularly if a critical mass of interested vendors and powerful and needy users are already members.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"4 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1996-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128981987","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}
We report on and analyze the views of long-standing active members of standards-setting working groups in electronic communications. We focus in particular on their experiences of, and attitudes towards, user participation in standardization. The results reveal attitudes that differ considerably from the official statement. To complement the views of standards professionals, we explore the attitude of large corporate email users towards standardization in general, the impact standards have on their apparent reluctance to play an active role in standardization. This includes a closer look at the ways in which email has emerged in organizations, and on what corporate users actually expect email of offer. A typical pattern can be identified, which in turn helps explain the reluctance of corporate users to actively participate in standards setting. Finally, we consider the implications of this and conclude with some recommendations on how the current situation could be improved.
{"title":"Users and standardization—worlds apart? The example of electronic mail","authors":"K. Jakobs, R. Procter, Robin Williams","doi":"10.1145/243492.243495","DOIUrl":"https://doi.org/10.1145/243492.243495","url":null,"abstract":"We report on and analyze the views of long-standing active members of standards-setting working groups in electronic communications. We focus in particular on their experiences of, and attitudes towards, user participation in standardization. The results reveal attitudes that differ considerably from the official statement. To complement the views of standards professionals, we explore the attitude of large corporate email users towards standardization in general, the impact standards have on their apparent reluctance to play an active role in standardization. This includes a closer look at the ways in which email has emerged in organizations, and on what corporate users actually expect email of offer. A typical pattern can be identified, which in turn helps explain the reluctance of corporate users to actively participate in standards setting. Finally, we consider the implications of this and conclude with some recommendations on how the current situation could be improved.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"36 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1996-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125726578","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}
Structured Transaction Definition Language (STDL) is a standardized, block-structured, high-level language that provides a development environment for writing portable, distributed transactional, and nontransactional applications. It has been mapped to the major TP monitors and is compatible with DCE. STDL's common API for distributed TP provides both portability across different TP monitors and enhances productivity through the usual benefits of high-level languages augmented with automated IDL/monitor call generation. STDL meets its design requirements in production use today.
{"title":"STDL: a route to productivity for distributed processing","authors":"Henry Lowe, E. Newcomer, J. Sekine","doi":"10.1145/243492.243503","DOIUrl":"https://doi.org/10.1145/243492.243503","url":null,"abstract":"Structured Transaction Definition Language (STDL) is a standardized, block-structured, high-level language that provides a development environment for writing portable, distributed transactional, and nontransactional applications. It has been mapped to the major TP monitors and is compatible with DCE. STDL's common API for distributed TP provides both portability across different TP monitors and enhances productivity through the usual benefits of high-level languages augmented with automated IDL/monitor call generation. STDL meets its design requirements in production use today.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"81 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1996-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121351912","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}
The odds are very high that an American attending an international standardization meeting or consulting in a foreign country will be asked about the U.S. standardization system. How is it organized? Who is responsible for developing standards? How many standards? Who sees to their implementation? What is the government's role? Why is there more than one standard for many commodities? Foreign engineers who are used to dealing with their national standards institute can be very critical of the decentralized U.S. system. Many are dissuades from applying U.S. standards because of real or anticipated problems in choosing, obtaining, and applying them. Many Americans raise similar questions. Some think that all standards come from the government. While most U.S. standardization specialists are familiar with the standards in their fields, few have an overview of the U.S. standardization system.
{"title":"Putting the U.S. standardization system into perspective: new insights","authors":"B. Toth","doi":"10.1145/243492.243493","DOIUrl":"https://doi.org/10.1145/243492.243493","url":null,"abstract":"The odds are very high that an American attending an international standardization meeting or consulting in a foreign country will be asked about the U.S. standardization system. How is it organized? Who is responsible for developing standards? How many standards? Who sees to their implementation? What is the government's role? Why is there more than one standard for many commodities? Foreign engineers who are used to dealing with their national standards institute can be very critical of the decentralized U.S. system. Many are dissuades from applying U.S. standards because of real or anticipated problems in choosing, obtaining, and applying them. Many Americans raise similar questions. Some think that all standards come from the government. While most U.S. standardization specialists are familiar with the standards in their fields, few have an overview of the U.S. standardization system.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"179 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1996-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133565993","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}
m The Internet Society of New Zealand (ISOCNZ) has been formed to promote and administer the Internet in this country and to represent New Zealand’s interests internationally. This article, written by Roger Hicks, its founding Chairman, describes the Society, its activities and the issues ahead. It begins with an examination of the roles and goals that the Internet Society of New Zealand was created to perform, looks at its achievements to date, and closes with what the Society hopes to achieve in the coming years. he first Annual General Meeting of the Internet Society of New Zealand was held on November 15, 1995, in Wellington, the capital city of New Zealand, where the membership was presented with its newly incorporated society and given the opportunity of electing its first council. This meeting was the culmination of the first phase of a long struggle to create a networked nation. Before I begin a description of the activities of ISOCNZ, I’d like to briefly describe the country that is New Zealand. While it may sound as if I’m an avid proponent of New Zealand (which may be true), it is necessary to understand certain cultural imperatives that drove the creation of ISOCNZ and why its ambitious plans for the future are significant. New Zealand is an isolated country situated in the southwest Pacific. The closest major landmass, and country, is Australia, which is 1000 miles to the west. To the east the nearest landmass is South America. It is 9 hours flying time from Hawaii and 13 hours to the U.S. at Los Angeles. In any measure New Zealand is a physically isolated country, a fact that has not escaped the inhabitants. New Zealand’s isolation has led to a strong culture of independence, innovation, and self-reliance. Everyone in the ISOCNZ carries dual or treble expertise; the country is not large enough to support singular experts. As a result, there is a curious and invigorating melding of disciplines and experience within ISOCNZ that makes it a significant laboratory for both social and technical growth.
{"title":"The Internet Society of New Zealand: roles, goals, and ambitions","authors":"R. Hicks","doi":"10.1145/240819.240829","DOIUrl":"https://doi.org/10.1145/240819.240829","url":null,"abstract":"m The Internet Society of New Zealand (ISOCNZ) has been formed to promote and administer the Internet in this country and to represent New Zealand’s interests internationally. This article, written by Roger Hicks, its founding Chairman, describes the Society, its activities and the issues ahead. It begins with an examination of the roles and goals that the Internet Society of New Zealand was created to perform, looks at its achievements to date, and closes with what the Society hopes to achieve in the coming years. he first Annual General Meeting of the Internet Society of New Zealand was held on November 15, 1995, in Wellington, the capital city of New Zealand, where the membership was presented with its newly incorporated society and given the opportunity of electing its first council. This meeting was the culmination of the first phase of a long struggle to create a networked nation. Before I begin a description of the activities of ISOCNZ, I’d like to briefly describe the country that is New Zealand. While it may sound as if I’m an avid proponent of New Zealand (which may be true), it is necessary to understand certain cultural imperatives that drove the creation of ISOCNZ and why its ambitious plans for the future are significant. New Zealand is an isolated country situated in the southwest Pacific. The closest major landmass, and country, is Australia, which is 1000 miles to the west. To the east the nearest landmass is South America. It is 9 hours flying time from Hawaii and 13 hours to the U.S. at Los Angeles. In any measure New Zealand is a physically isolated country, a fact that has not escaped the inhabitants. New Zealand’s isolation has led to a strong culture of independence, innovation, and self-reliance. Everyone in the ISOCNZ carries dual or treble expertise; the country is not large enough to support singular experts. As a result, there is a curious and invigorating melding of disciplines and experience within ISOCNZ that makes it a significant laboratory for both social and technical growth.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"11 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":"126302658","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}
m Standards in most disciplines have developed over a very long period of time. The world of information technology (IT) is, however, relatively young. Nonetheless, numerous IT standards have already been developed under the auspices of ISO/IEC JTC1, its many subcommittees, and their 56 member nations. The rigor of the procedures for developing these standards ensures that standards published by JTC1 represent world opinion in their form, structure, and content. These procedures also ensure that the standards fulfill a specific need, and thus are practical. nternational standards play an important role in the maturation process of software development and in the furthering of software engineering as a formal discipline. While standards are an accepted part of mature disciplines, such as (physical) engineering and most of the trades, they are not yet well-established in the area of software development and engineering. Although the telecommunications industry leads the way in the development and universal acceptance of information technology standards, it too is still immature. The multitude of mobile and cellular phone standards within the United States serves as an example. In many countries, acceptance of standards, international or local, is not automatic; they are, in fact, not always welcome. Often, this is due to a lack of understanding of how standards are developed. Indeed, the process of developing international standards is understood by few. Many within the standards development arena see the process as being overly bureaucratic. Many outside the arena doubt the ability of a standard to represent the user community. Still others see standardization as one of those things that just happen—too complex to even try to understand. In order to gain wide acceptance of international standards, it is essential that potential users understand the development process, and thus gain some degree of confidence in the standards. This is equally true whether their adoption of the standard will be voluntary or mandatory. We detail the development of international (ISO/IEC) standards showing that international standards, by virtue of their very rigorous development processes and the international makeup of their development committees, do present practical solutions to the problems that beset the rather young and, in parts, immature discipline of software engineering. To illustrate this rigor, this article will describe the procedures adopted by the ISO/IEC Joint Technical Commmittee for Information Technology, JTC1. It will discuss the subcommittees of JTC1 and, in particular, the work groups within Subcommittee 7 (SC7)—Software Engineering. Our article is structured as follows: The structure of ISO and its subcommittees, International Standards: Practical or Just Theoretical? F E A T U R E A R T I C L E
{"title":"International standards: practical or just theoretical?","authors":"Hugo Rehesaar","doi":"10.1145/240819.240820","DOIUrl":"https://doi.org/10.1145/240819.240820","url":null,"abstract":"m Standards in most disciplines have developed over a very long period of time. The world of information technology (IT) is, however, relatively young. Nonetheless, numerous IT standards have already been developed under the auspices of ISO/IEC JTC1, its many subcommittees, and their 56 member nations. The rigor of the procedures for developing these standards ensures that standards published by JTC1 represent world opinion in their form, structure, and content. These procedures also ensure that the standards fulfill a specific need, and thus are practical. nternational standards play an important role in the maturation process of software development and in the furthering of software engineering as a formal discipline. While standards are an accepted part of mature disciplines, such as (physical) engineering and most of the trades, they are not yet well-established in the area of software development and engineering. Although the telecommunications industry leads the way in the development and universal acceptance of information technology standards, it too is still immature. The multitude of mobile and cellular phone standards within the United States serves as an example. In many countries, acceptance of standards, international or local, is not automatic; they are, in fact, not always welcome. Often, this is due to a lack of understanding of how standards are developed. Indeed, the process of developing international standards is understood by few. Many within the standards development arena see the process as being overly bureaucratic. Many outside the arena doubt the ability of a standard to represent the user community. Still others see standardization as one of those things that just happen—too complex to even try to understand. In order to gain wide acceptance of international standards, it is essential that potential users understand the development process, and thus gain some degree of confidence in the standards. This is equally true whether their adoption of the standard will be voluntary or mandatory. We detail the development of international (ISO/IEC) standards showing that international standards, by virtue of their very rigorous development processes and the international makeup of their development committees, do present practical solutions to the problems that beset the rather young and, in parts, immature discipline of software engineering. To illustrate this rigor, this article will describe the procedures adopted by the ISO/IEC Joint Technical Commmittee for Information Technology, JTC1. It will discuss the subcommittees of JTC1 and, in particular, the work groups within Subcommittee 7 (SC7)—Software Engineering. Our article is structured as follows: The structure of ISO and its subcommittees, International Standards: Practical or Just Theoretical? F E A T U R E A R T I C L E","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"32 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":"122103120","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}
Ⅵ In 1985, Sun Microsystems began to develop its formal software processes (the company was then just three years old). These software processes now cover all steps of a product (from the point of view of a variety of functional areas), from inception through end of life. This article is a brief overview of the software processes that we have created and continue to develop at Sun. The need for this constant development is due to the fact that Sun's market environment is undergoing rapid and constant change, to which the company must respond. process is a method for implementing change. Change can be an initiation (change from nothing to something), revision (change from something to something else), or elimination (change from something to nothing). A software process must be able to address work of great complexity and must itself be malleable in order to continue to be effective. That is, it must provide a known, approved, and effective means to make change happen. A formal process should make it easier to do business, improve quality, and simplify training. Processes do not have to be complex in themselves, but a process is usually not established as an important and identifiable pattern of actions with sequenced approvals unless the change to which it applies is complex. Since Sun's corporate culture promotes individualism and experimentation (" to ask permission is to seek denial " is one of Sun CEO Scott McNealy's favorite aphorisms), we call the core of our software infrastructure a " framework. " The image is that of a stable and open structure which can hold a wide variety of successful styles, interpretations, and implementation methods. Sun is a hardware company at heart. Nonetheless, we recognize that it is the suite of software products which motivate customers to choose one system (the combined hardware-software product) over another. Thus, two of Sun's " planets " (wholly owned subsidiary companies) are almost entirely devoted to software. These planets function as independent software companies, but always within the context of the larger hardware-oriented corporation. This fundamental hardware orientation was apparent from the inception of Sun's first software-only process. It was created eleven years ago in response to a strong request from our manufacturing department for a written and orderly mechanism for the transmission, or " release, " of a software product from development engineering into manufacturing. After many energetic attempts to cram the …
{"title":"Software process framework at Sun","authors":"Katy Dickinson","doi":"10.1145/240819.240830","DOIUrl":"https://doi.org/10.1145/240819.240830","url":null,"abstract":"Ⅵ In 1985, Sun Microsystems began to develop its formal software processes (the company was then just three years old). These software processes now cover all steps of a product (from the point of view of a variety of functional areas), from inception through end of life. This article is a brief overview of the software processes that we have created and continue to develop at Sun. The need for this constant development is due to the fact that Sun's market environment is undergoing rapid and constant change, to which the company must respond. process is a method for implementing change. Change can be an initiation (change from nothing to something), revision (change from something to something else), or elimination (change from something to nothing). A software process must be able to address work of great complexity and must itself be malleable in order to continue to be effective. That is, it must provide a known, approved, and effective means to make change happen. A formal process should make it easier to do business, improve quality, and simplify training. Processes do not have to be complex in themselves, but a process is usually not established as an important and identifiable pattern of actions with sequenced approvals unless the change to which it applies is complex. Since Sun's corporate culture promotes individualism and experimentation (\" to ask permission is to seek denial \" is one of Sun CEO Scott McNealy's favorite aphorisms), we call the core of our software infrastructure a \" framework. \" The image is that of a stable and open structure which can hold a wide variety of successful styles, interpretations, and implementation methods. Sun is a hardware company at heart. Nonetheless, we recognize that it is the suite of software products which motivate customers to choose one system (the combined hardware-software product) over another. Thus, two of Sun's \" planets \" (wholly owned subsidiary companies) are almost entirely devoted to software. These planets function as independent software companies, but always within the context of the larger hardware-oriented corporation. This fundamental hardware orientation was apparent from the inception of Sun's first software-only process. It was created eleven years ago in response to a strong request from our manufacturing department for a written and orderly mechanism for the transmission, or \" release, \" of a software product from development engineering into manufacturing. After many energetic attempts to cram the …","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"23 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":"134450181","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}
m In recent years, the increased use of software in critical applications such as nuclear power plants, medical systems, transportation systems, financial systems, and environmental systems has necessitated the development of guidelines to ensure that this software meets certain criteria for prudent performance. Each of these applications carries some form of risk, with welldefined consequences. A standard developed jointly by IEC TC 56/WG10 and ISO/IEC JTC1/WG9 has the concept of integrity level as its unifying theme. The integrity level is a “negotiated” containment of risk based on an integrity target established by the parties concerned. Risk cannot be contained in the software alone, as software operates in a system as one of its functions. Risk must be addressed from a system perspective to determine its magnitude and the means to contain it. For the standard under discussion, TC 56/WG10 provides the system perspective, while ISO/IEC JTC1/WG9 provides the software perspective. This article describes the requirements for the standard, the concept of operations for integrity-level process, the key features of the standard, and the means to produce the systems and software integrity-level standard. The article also describes a proposed program of work, based on the integrity-level concept, being pursued jointly by the two working groups. he purpose of this article is to describe how integrity-level standards are used; describe the system and software-level program; describe how a set of integrity-level standards is being developed; and describe the key features of the basic standard in the joint system and software integrity-level program.
{"title":"International standards on system and software integrity","authors":"L. Tripp","doi":"10.1145/240819.240827","DOIUrl":"https://doi.org/10.1145/240819.240827","url":null,"abstract":"m In recent years, the increased use of software in critical applications such as nuclear power plants, medical systems, transportation systems, financial systems, and environmental systems has necessitated the development of guidelines to ensure that this software meets certain criteria for prudent performance. Each of these applications carries some form of risk, with welldefined consequences. A standard developed jointly by IEC TC 56/WG10 and ISO/IEC JTC1/WG9 has the concept of integrity level as its unifying theme. The integrity level is a “negotiated” containment of risk based on an integrity target established by the parties concerned. Risk cannot be contained in the software alone, as software operates in a system as one of its functions. Risk must be addressed from a system perspective to determine its magnitude and the means to contain it. For the standard under discussion, TC 56/WG10 provides the system perspective, while ISO/IEC JTC1/WG9 provides the software perspective. This article describes the requirements for the standard, the concept of operations for integrity-level process, the key features of the standard, and the means to produce the systems and software integrity-level standard. The article also describes a proposed program of work, based on the integrity-level concept, being pursued jointly by the two working groups. he purpose of this article is to describe how integrity-level standards are used; describe the system and software-level program; describe how a set of integrity-level standards is being developed; and describe the key features of the basic standard in the joint system and software integrity-level program.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"18 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":"127232508","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}
Ⅵ International standardization activities are often thought to be undertaken only when the subject is mature. It is further presumed that as concensus takes so long to achieve, the technology concerned will often have moved far ahead by the time the standard is published. In one area of information systems activities, however, the reverse is the case: the standards-makers are working at the leading edge of the subject. The work in question is that of ISO/IEC JTC1 Subcommittee 7, Working Group 12, which is concerned with standardizing methods for sizing software. This methodology is important in software development for a range of practical purposes such as productivity measurement, effort estimation, controlling the scope of a project as it progresses, etc. Various sizing methods exist, and it is clearly desirable to achieve some common international agreement on the best approach. The first step taken towards standardizing sizing methods has been to seek the underlying principles of software sizing, and to define these in a 'meta' standard, rather than to attempt to define a single international software sizing standard. This approach has brought new challenges, not the least of which has been agreeing on abstract concepts across diverse languages and cultures. But the result has been new insights into how to size software , which it is difficult to believe could have been achieved other than through such an international forum. There are clear lessons to be learned about the value of this way of working; it is equally clear that attention must be paid to the dissemination and promotion of new ideas so that they can be quickly taken up in the market place, and their benefits made available to the user community. hould the development of international standards in a fast-moving area such as information technology be pursued at the leading edge of its expanding technology and ideas, or should standards be developed only when the subject is well understood, stabilizing and matur-ing? And does it matter in practice which path is pursued? The common perception is that most standardization takes place well back from the leading edge. The development of standards for technologies as diverse as programming languages such as COBOL, operating systems such as Unix, and hardware and telecommunications generally, has proceeded at a pace which left those standards, by the time they were agreed on and published well out of date. To those in industry eagerly following …
{"title":"Standardizing at the leading edge","authors":"C. Symons","doi":"10.1145/240819.240822","DOIUrl":"https://doi.org/10.1145/240819.240822","url":null,"abstract":"Ⅵ International standardization activities are often thought to be undertaken only when the subject is mature. It is further presumed that as concensus takes so long to achieve, the technology concerned will often have moved far ahead by the time the standard is published. In one area of information systems activities, however, the reverse is the case: the standards-makers are working at the leading edge of the subject. The work in question is that of ISO/IEC JTC1 Subcommittee 7, Working Group 12, which is concerned with standardizing methods for sizing software. This methodology is important in software development for a range of practical purposes such as productivity measurement, effort estimation, controlling the scope of a project as it progresses, etc. Various sizing methods exist, and it is clearly desirable to achieve some common international agreement on the best approach. The first step taken towards standardizing sizing methods has been to seek the underlying principles of software sizing, and to define these in a 'meta' standard, rather than to attempt to define a single international software sizing standard. This approach has brought new challenges, not the least of which has been agreeing on abstract concepts across diverse languages and cultures. But the result has been new insights into how to size software , which it is difficult to believe could have been achieved other than through such an international forum. There are clear lessons to be learned about the value of this way of working; it is equally clear that attention must be paid to the dissemination and promotion of new ideas so that they can be quickly taken up in the market place, and their benefits made available to the user community. hould the development of international standards in a fast-moving area such as information technology be pursued at the leading edge of its expanding technology and ideas, or should standards be developed only when the subject is well understood, stabilizing and matur-ing? And does it matter in practice which path is pursued? The common perception is that most standardization takes place well back from the leading edge. The development of standards for technologies as diverse as programming languages such as COBOL, operating systems such as Unix, and hardware and telecommunications generally, has proceeded at a pace which left those standards, by the time they were agreed on and published well out of date. To those in industry eagerly following …","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"16 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":"126195990","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}
Ⅵ Standards are designed to promote the efficient use of technology; they can be seen as structured and prepackaged , agreed-upon best practices for specific technologies. Teaching can be viewed as a technology transfer process, and the use of standards can facilitate this process. This paper discusses the uses of both ISO standards and work-in-progress documents in designing and teaching graduate courses in software engineering , it also discusses the approach selected to illustrate to graduate students how an accepted body of knowledge is developed and agreed upon by a group of domain experts. The teaching method involves class simulations of the review process of ISO work sessions and international voting. Lessons learned from both learning and teaching perspectives are also presented. oftware engineering course materials are often based on either textbooks or fairly specialized and research oriented academic papers. Both are useful; however, they often reflect the personal views of individual experts—their own experience , perspectives and biases. In other engineering disciplines, teaching material is based on a common body of knowledge agreed upon by certification bodies, such as professional engineering boards, which review and approve the curriculum of engineering disciplines taught at the university level. Furthermore, standards are key components of the engineering disciplines. Unfortunately, in software engineering there is not yet an agreed-upon core body of codified knowledge, no certification body and, until fairly recently, a scarcity of accepted standards addressing specific software engineering topics. Consequently, for both undergraduate and graduate courses in software engineering, there is a lack of teaching material based on software engineering standards. A handful of countries have developed some national standards in software engineering. However, these national standards sometimes reflect strong cultural biases which make them difficult to use in an international context. Fortunately, some international standards on software engineering are making their way through the ISO subcommittee on software engineering (ISO/IEC JTC1/SC7); within this subcommittee there are nine subgroups currently working on software engineering topics. This means that, although only 14 software engineering standards have been published to date, a vast array of material is available (as of June 1996) in draft format, through national standards bodies: 4 draft international standards (DIS), 10 committee drafts (CD) and 20 working drafts (WD), plus an unspecified number of documents that have not yet reached the working draft stage. Standards are designed to promote the efficient use of technology, and can be seen as …
{"title":"Teaching software engineering using ISO standards","authors":"A. Abran","doi":"10.1145/240819.240825","DOIUrl":"https://doi.org/10.1145/240819.240825","url":null,"abstract":"Ⅵ Standards are designed to promote the efficient use of technology; they can be seen as structured and prepackaged , agreed-upon best practices for specific technologies. Teaching can be viewed as a technology transfer process, and the use of standards can facilitate this process. This paper discusses the uses of both ISO standards and work-in-progress documents in designing and teaching graduate courses in software engineering , it also discusses the approach selected to illustrate to graduate students how an accepted body of knowledge is developed and agreed upon by a group of domain experts. The teaching method involves class simulations of the review process of ISO work sessions and international voting. Lessons learned from both learning and teaching perspectives are also presented. oftware engineering course materials are often based on either textbooks or fairly specialized and research oriented academic papers. Both are useful; however, they often reflect the personal views of individual experts—their own experience , perspectives and biases. In other engineering disciplines, teaching material is based on a common body of knowledge agreed upon by certification bodies, such as professional engineering boards, which review and approve the curriculum of engineering disciplines taught at the university level. Furthermore, standards are key components of the engineering disciplines. Unfortunately, in software engineering there is not yet an agreed-upon core body of codified knowledge, no certification body and, until fairly recently, a scarcity of accepted standards addressing specific software engineering topics. Consequently, for both undergraduate and graduate courses in software engineering, there is a lack of teaching material based on software engineering standards. A handful of countries have developed some national standards in software engineering. However, these national standards sometimes reflect strong cultural biases which make them difficult to use in an international context. Fortunately, some international standards on software engineering are making their way through the ISO subcommittee on software engineering (ISO/IEC JTC1/SC7); within this subcommittee there are nine subgroups currently working on software engineering topics. This means that, although only 14 software engineering standards have been published to date, a vast array of material is available (as of June 1996) in draft format, through national standards bodies: 4 draft international standards (DIS), 10 committee drafts (CD) and 20 working drafts (WD), plus an unspecified number of documents that have not yet reached the working draft stage. Standards are designed to promote the efficient use of technology, and can be seen as …","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"43 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":"121543697","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}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：