The Internet of Things (IoT) integrates a variety of cyber-physical systems; systems that are safety-critical and those that are not. Each of these systems is composed from assets that may have been intended to integrate successfully, but they have not necessarily been verified as doing so before the product is instantiated. Because assets are commonly shared among a family of cyber-physical products, Software Product Line (SPL) methods are crucial for the success of these systems if they are to be built economically without compromise to safety. Verification of the SPL architectures will help to ensure the safety of these systems is not compromised by any of the numerous assets that can be swapped in and out as new products are configured. The contribution of this work is an illustration of how software architectures might be annotated embedding verification information of the architecture supporting a compositional approach to verification.

This panel will address issues surrounding software ecosystems. We have chosen individuals who will present a differing set of views on the topic.

The goal of this research is to understand the various dimensions along which the architectures in an ecosystem should scale to support successful software-intensive products. We used a case study approach in which we first identified characteristics of scalability from the research literature and then examined ecosystems to determine the extent to which their primary architectures possessed these characteristics. We also examined the architectures of the platform extensions. We found that each architecture exhibited those characteristics although through different mechanisms and to different degrees.

Business and market goals drive an organization's creation and operation of a software product line. Effective product production is critical to the success of that product line and must also be driven by those business and market goals.

The ecosystem, within which a software product line resides, is a network of organizations producing and consuming software assets and the linkages among those assets. The complexity of the relationships among the elements in the ecosystem requires analytic techniques to predict the effects of strategic decisions on the network of suppliers, buyers, collaborators, and ecosystem. The STRategic Ecosystem Analysis Method (STREAM) guides the collection of data and structures a model that can be queried.

Why does it change?

The ecosystem, within which a software product line resides, is a network of organizations producing and consuming software assets and the linkages among those assets. The complexity of the relationships among the elements in the ecosystem requires analytic techniques to predict the effects of strategic decisions on the network of suppliers, buyers, collaborators, and ecosystem. The STRategic Ecosystem Analysis Method (STREAM) guides the collection of data and structures a model that can be queried. The flow of the tutorial session will follow the outline of the method with detailed descriptions of each step.

Business and market goals drive an organization's operation of a software product line strategy. Effective product production is critical to the success of that product line and must also be driven by those business and market goals. This tutorial outlines a method for coordinating the core asset development and product production.

The tutorial will be driven by a set of scenarios that will set the context for several threads of discussion. These scenarios will reflect different domains and organizational types. Each of the scenarios will illustrate an aspect of one or more of the topics 1--6 listed above. For example, John McGregor has had experience with product lines in which there are many suppliers of core assets and multiple independent builders of products. A scenario like this would provide the context for topic number 4, communication.

Courses about various software engineering practices, e.g. testing and architecture, all ultimately relate to a process for applying the practice. We have used that process as the organizing principle for undergraduate and graduate software engineering courses. The Software Process Engineering Meta-model (SPEM) provides a means for engineering a process for the specific practice being studied and even tailoring that process to the specific needs of a project. We have used the Eclipse Process Framework, an implementation of the SPEM, as a tool to allow instructors to create, modify and reuse a baseline electronic textbook as well as for students to collect, organize, and represent information in a form most meaningful to them. We present examples and data from one undergraduate introduction to software engineering course and two graduate courses in verification and validation and software architecture gathered over several years.

The objective of this workshop is to bring together researchers and practitioners to report and discuss the challenges and opportunities for integrating quantitative methods in product line engineering with the objective of achieving both technical and business goals. In particular, we are seeking contributions that, on the one hand, deal with product line estimation and metrics for the effective management of product line projects, and on the other hand, provide some insight into new trends in value-based product line engineering.

The production method for a software product line is the coordinated set of processes, models, and tools chosen to implement the essential product line activities of core asset development and product development. This paper shows how the task of engineering a production method for a product line can be facilitated by applying concepts from the domain of method engineering. A case study of an industrial product line illustrates how its production method was engineered to achieve specific business goals.

Production planning gives early guidance concerning how products should be built and hence how core assets should be designed. The production strategy addresses business goals through product building. The production method implements the production strategy by delineating exactly how a product is built from core assets. The production plan instantiates the production method for a specific product. In this tutorial we will layout production planning in a software product line and provide examples from a number of different product lines.

Many software product line organizations have been in operation for a sufficiently long time for products and assets to be refurbished and even retired. There is much experience in the management and operation of product lines that has not been communicated. Our goal is to provide information about both strategic and tactical actions needed for the continuing operation of a successful software product line organization. It is time to look beyond the issues of adoption to focus on the care and feeding of the on-going organization.

A good estimation tool offers a "model" of a project and is usually used to estimate cost and schedule, but it can also be used to help make trade decisions that affect cost and schedule as well as to estimate risks and opportunities. It was evident that Rolls-Royce needed a cost model to underpin decisions when they launched a Software Product Line initiative. The first generation cost model was based on COCOMO II, which represents the software product as a single size measure (Source Lines of Code) but makes limited use of the architecture or any characteristics of the product being developed. The next generation of the cost model, currently under development, is intended to account for the quality attributes of the core assets and the resulting products in order to estimate their impact on cost and net-benefit to the business. The objective of this paper is to describe our current efforts to integrate key quality attributes into the SPL cost model. We describe the quality attributes selected, the reason for their selection and the benefits we expect to obtain after integrating them into the model.

Component Based Software Engineering (CBSE) is a technique for designing and assembling systems from existing parts that has important implications for a number of software engineering practices. The basic principles of CBSE, including modularity, substitutability, and composition are important throughout the SE curriculum. The ability to build a component and have confidence that it will function predictably in different environments requires a variety of skills. In this paper we present hands-on projects that use the recently released SEI PSK tool suite to implement exercises in several courses across the computing curriculum, including courses in: software engineering, computational theory, operating systems, programming languages, and verification and validation.

Summary form only given. Most software product line organizations recognize the need for two roles: core asset developers and product builders. These roles may both be assumed by an individual or each may be assumed by persons who are in different administrative units, in different geographic locations, or of vastly different skill levels. Production planning is used in many industries to coordinate the efforts of external suppliers who supply parts and to structure the assembly line where products are produced. The need for coordination in a software product line organization is even greater than in hard goods manufacturing because product production is less constrained by physical properties or industrial standards. Our research has shown that organizations that fail to plan production are more likely to fail than those that do plan. The goal of this tutorial is to provide participants with techniques for conducting production planning.

Software product line engineering (SPLE) has shown to be a very successful paradigm for developing a diversity of similar software products at low cost, in short time, and with high quality.

Agile software development and software product line engineering are both successful approaches to the development of software-intensive products, but can the planning driven approach of product lines be effectively integrated with the opportunistic approach of agile techniques? This is a difficult question to answer since each broad strategy refers to a family of possible methods.

Summary form only given. Testing consumes a significant percentage of the resources required to produce software intensive products. The exact impact on the project is often hard to evaluate because testing activities are distributed over the entire scope of the development effort. In this article we take a comprehensive end-to-end view of the testing activities and roles that should be present in a software product line organization. The Software Engineering Institute (SEI) identifies three areas of responsibility in a product line organization we relate these to testing: organizational managers have responsibility for establishing the test strategy for the organization in general and the product line in particular. These activities are directly related to the business goals and scope of the product line. Technical managers have responsibility for planning the numerous test activities needed to implement the test strategy. These activities are planned in concert with the development activities to coordinate milestones and resources. Software engineers have responsibility for implementing the planned activities. They select the specific test cases necessary to achieve specific test coverage levels and implement any software needed to apply the test cases to the software under test.

The Architecture Expert (ArchE) is a software architecture design assistant under development at the Software Engineering Institute (SEI). It embodies knowledge of quality attributes and the relation between the achievement of quality attribute requirements and architecture design. In this paper, we describe the use of ArchE in a graduate level software architecture class at Clemson University. The discussion combines aspects of using ArchE as a tool to produce architectures and using ArchE to teach about architecting. The students were positive about the use of ArchE although critical of ArchE's immaturity. The instructor was also positive about the use of ArchE.

Companies such as Toyota have achieved significant competitive advantage by treating product production as a system that can be planned and optimized. Software product line organizations can achieve similar advantage when they explicitly coordinate the actions of core asset and product developers. We describe a technique for planning the production system for a software product line organization. The technique encompasses a production strategy, which relates the production goals of the product line to the method of core asset and product development; and a production method, which coordinates the development of core assets with the production of products. The results of the technique are documented in a production plan, which guides the product developers through the steps of production. Data gathered from representatives of SPLC Product Line Hall of Fame members and our experience working with product line organizations are used to illustrate problems and specify solutions.

Testing consumes a significant percentage of the resources required to produce software intensive products. The exact impact on the project is often hard to evaluate because testing activities are distributed over the entire scope of the development effort. In this tutorial we take a comprehensive end-to-end view of the testing activities and roles that should be present in a software product line organization.

The idea of developing software systems by putting software modules together has been a goal for many software researchers and practitioners for a long time. This goal is within sight due to the increased adoption of component-based software engineering, the development of component standards, and their wide acceptance by industry. Component-based development is an approach to developing a software system by assembling and composing already built software components. It promises reusable and plug-and-playable software system development environments. The component concept is not new and has been perceived in several different ways by software researchers in academics and practitioners in industry. The different perspectives from diverse researchers and practitioners have led to a plethora of definitions of component and different component specification and implementation models. In this paper, we briefly review several of these different views and definitions on software components. We then present the Interoperable Component Specification Model (ICSM) for the Web services environment.

No abstract available.

Article Free Access Share on A goal-oriented approach to laboratory development and implementation Authors: Brenda C. Parker Dept. of Computer Science, Middle Tennessee State University, Murfreesboro, TN Dept. of Computer Science, Middle Tennessee State University, Murfreesboro, TNView Profile , John D. McGregor Dept. of Computer Science, Clemson University, Clemson, SC Dept. of Computer Science, Clemson University, Clemson, SCView Profile Authors Info & Claims SIGCSE '95: Proceedings of the twenty-sixth SIGCSE technical symposium on Computer science educationMarch 1995 Pages 92–96https://doi.org/10.1145/199688.199738Online:15 March 1995Publication History 18citation211DownloadsMetricsTotal Citations18Total Downloads211Last 12 Months2Last 6 weeks1 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

Although there is much interest in creating libraries of well-designed, thoroughly-tested classes that can be confidently reused for many applications, few class testing techniques have been developed.In this paper, we present a class testing technique that exploits the hierarchical nature of the inheritance relation to test related groups of classes by reusing the testing information for a parent class to guide the testing of a subclass.We initially test base classes having no parents by designing a test sui~e that tests each member fmction individually and also tests the interactions among member functions.To &sign a test suite for a subclass, our algorithm incrementally up~tes the history of its parent to reject both the modijied, inherited attributes and the subclass's newly akjined attributes.Only those new attributes or @'cted, inherited attributes are tested and the parent class' test suites are reused, if possible, for the testing.Inherited attributes are retested in their new context in a subclass by testing their interactions with the subclass's newly dejined attributes.We have incorporated a data jlow tester into Free Software Founalzion, Inc's C-++ compilers and are using it for our experimentation.

A working group, representing ACM, DPMA, and IEEE-CS, was formed to draft a set of guidelines, including criteria, for the accreditation of computer information systems' undergraduate programs. The guidelines and criteria are summarized below.Faculty: Typically a minimum of 4 faculty, with 3 full time, are needed. Normally, 25% of a faculty member's time should be available for scholarly activity and development. Teaching loads should not exceed 12 hours and should not exceed 4 courses with 2 preparations.Curriculum: Curricular assume a 120 semester hour, four year, baccalaureate program. The program should consist of approximately 30% computer information systems, 20% business, at least 40% in general education and up to 10% other.Forty to 60 percent of the CIS portion should cover a broad core that includes a) computer concepts and software systems, b) program, data, and file structures, c) data management,d) data and computer communications, and e) systems analysis and design. Students should be exposed to a variety of programming languages and be proficient in one structured language. The remaining courses should cover breadth and depth.Resources: Appropriate computing facilities must exist for students and faculty. Adequate software and documentation must be available.Students: Established standards and procedures must insure that graduates have the requisite qualifications to function as CIS professionals.Institutional Support: Adequate support must be provided to support the faculty, department office administration, and library. Faculty support includes leave programs, reasonable teaching loads, competitive salaries, and travel support.

The purpose of this paper is to report on some experiences in the planning and implementation of an introductory course on computer graphics. The course focused on topics of concern to the computer science major interested in developing graphics system software.