The current ACM and IEEE Computer Society recommended guidelines for graduate software engineering programs (GSwE2009) were created in 2009 by an international group of experts from industry, government and academia. We report here on some of the early experiences using GSwE2009 to create a new curriculum in software assurance and to create and/or improve 4 different academic programs in 3 countries. All of these experiences have been positive, confirming the validity and usefulness of GSwE2009.

This panel will discuss recent trends in graduate software engineering programs, including adoption of GSwE2009, cooperative programs between schools, increasing use of distance education formats, and specialization of programs for industry partners. Panelists will also discuss the evolving relationship of software engineering to other disciplines, such as computer science and systems engineering.

The computer science capstone experience is designed to bridge the gap from university expectations to those of industry. Yet trying to solve this problem with a single course sequence, even one spanning the senior year, has some shortcomings, in terms of learning outcomes which can be achieved, and also instructional strategies that can be employed. We describe here an alternative plan which first provides a junior year of practice on a client-based project integrated with learning design and other related topics, followed by a senior year in which students can work more independently to hone these skills on a harder year-long project with another client. This two-year sequence, with scaffolding provided at first that is gradually removed, has proven to be especially effective in preparing undergraduates for a career in the soft- ware industry. The approach also integrates well with the need for these students to become proficient at working in engineering teams.

Evolving software products is a tricky business, especially when the domain is complex and changing rapidly. Like other fields of engineering, software engineering productivity advances have come about largely through abstraction, reuse, process, and automation (e.g., moving from assembly language to third generation languages offered increased productivity through better abstraction). For canonical or domain applications, model-based engineering (MBE) of software provides a systematic approach for producing software systems that leverage all of these avenues of productivity. Specifying or modeling software at higher levels of abstraction and connecting these representations with previously developed (reusable) components provides a repeatable assembly and transformation process that can often be automated. Since 2004, we have explored MBE for generating software from the high-level for sophisticated agent-based systems, low-level complexity in the details of software-defined radios, and more recently with the maturation of emergent systems found in social networking (i.e., Facebook-like systems). While productivity is a key benefit of MBE in software, there have been few studies that examine productivity. In this paper, we present our experience in these efforts and reflect on some productivity implications. Our experience shows that MBE introduces some complexities early in the product life cycle, but provides a stable basis for better productivity through systematic abstraction, reuse, process, and automation.

This paper proposes a requirements-driven security engineering approach for modeling, specifying, and analyzing application-specific security requirements that are formally derived into security design specifications preserving security requirements properties. The approach adopts and non-trivially extends the goal-oriented KAOS (Knowledge Acquisition in automated Specifications) framework developed by Lamsweerde to formally construct a complete, consistent, and clear security requirements model. The resulting model is then extended using the B method to produce security design specifications and further implementation while preserving requirements properties. In our approach, we firstly transform the KAOS requirements model to an abstract B model and secondly, we refine the model using B refinement mechanism to generate design specifications and implementation. This unique treatment of secure software engineering is systematic, constructive and considers security early in the development lifecycle while ensuring no loss of the security requirements properties of completeness, consistency and clarity at later development phases. Moreover, our approach allows for requirement traceability at the various phases of development.

Abstract We introduce a Capabilities‐based approach for constructing large‐scale systems such that they are change‐tolerant. The inherent complexity of software systems increases their susceptibility to change when subjected to the vagaries of user needs, technology advances, market demands, and other change‐inducing factors. Despite the inevitability of change, traditional requirements engineering strives to develop systems based on a fixed solution; a mostly unsuccessful approach as evidenced by the history of system failures. In contrast, we utilize Capabilities—functional abstractions that are neither as amorphous as user needs nor as rigid as system requirements—to architect systems that accommodate change with minimum impact. These entities are designed to exhibit the desirable characteristics of high cohesion, low coupling, and balanced abstraction levels and are generated by a two‐phased process called Capabilities Engineering. Phase I mathematically exploits the structural semantics of a function decomposition graph—a representation of user needs—to formulate change‐tolerant Capabilities. Phase II optimizes these Capabilities to comply with schedule and technology constraints. In this paper, we present the overall framework of this process and detail the algorithm to identify Capabilities. In addition, we empirically evaluate the change tolerance of Capabilities resulting from Phase I. For this we examine the ripple effect of needs change on a real‐world Course Evaluation System based on the original requirements‐based design and the corresponding Capabilities‐based design. Our experimental results indicate, with statistical significance, that the Capabilities‐based design is less impacted by change and thereby improves the change tolerance of the system when subjected to needs volatility. Copyright © 2008 John Wiley & Sons, Ltd.

With the advent of potent network technology, software development has evolved from traditional platform-centric construction to network-centric evolution. This change involves largely the way we reason about systems as evidenced in the introduction of 'network-centric operations (NCO). Unfortunately, it has resulted in conflicting interpretations of how to map NCO concepts to the field of software architecture. In this paper, we capture the core concepts and goals of NCO, investigate the implications of these concepts and goals on software architecture, and identify the operational characteristics that distinguish network- centric software systems from other systems. More importantly, we use architectural design principles to propose an outline for a network-centric architectural style that helps in characterizing network-centric software systems and that provides a means by which their distinguishing operational characteristics can be realized.

Performance is a key aspect of non-functional software requirements. While performance cross-cuts much of the software functionality, it is frequently difficult to express in traditional software development representations. In this paper we propose a framework for evaluating software performance using aspect-oriented programming (AOP) and examine its strengths and limitations. The framework provides a mechanism for supporting software performance evaluation prior to final software release. AOP is a promising software engineering technique for expressing cross-cutting characteristics of software systems. We consider software performance as a cross-cutting concern since it is not confined only a few modules, but often spread over multiple functional and non-functional elements. A key strength of our framework is the use of a code instrumentation mechanism of AOP - AspectJ code for performance analysis is separated from Java code for functional requirements. Java code is executable regardless of Aspect J code and can be woven together with AspectJ code when performance is evaluated. Our performance evaluation modules, written in AspectJ are semi-automatically or automatically generated from the UML [1] models with annotated performance profiles. The AspectJ code generator facilitates performance evaluation by allowing performance requirements that have been specified in UML models to be analyzed. The UML diagrams can then be improved by reflecting the feedback from the results of the performance analysis.

Support Vector Machines are used to combine the outputs of multiple entity extractors, thus creating a composite entity extraction system. The composite system has a significantly higher f-measure than any of the component systems. Compared to a standard voting technique for combining the results of multiple entity extractors, the SVM approach produces comparable precision and recall statistics but tends to utilize fewer of the component entity extractors, thus providing superior computational efficiency, which is critical in practical applications. In this paper, we present our experimental results of comparing a standard voting technique with SVM that each aggregate four entity extractors. We also describe our future plans of integrating agent-based technology into our experimental testbed where we examine the evolution of composite techniques as part of the analysis stream. Given that much of the improvement comes from tuning the algorithms to the data stream with a human-in-the-loop, we are considering the merits of employing cognitive agents that are strategically embedded in the workflow for processing data. As we tune the algorithms for better performance on the data streams, we envision agents learning the patterns of data streams and apply the appropriate tuning to ensure optimality.

The Cognitive Agent Architecture (Cougaar) is a distributed agent architecture framework originally developed to build large scale logistics applications for the Department of Defense. In order to facilitate rapid development of complex military and commercial Cougaar applications, we are devising "recipes" on how to automate the Cougaar application development process. The envisioned Cougaar Model Driven Architecture (CMDA) system will capture requirements from the user and automatically generate related software artifacts such as requirement, design, code and test cases. The automated generation of software artifacts, even if partial in nature, should considerably increase the productivity of Cougaar developers. Recognizing the sophistication of the Cougaar framework and the limitations of current transformation technologies, we have systematically developed an approach that combines component assembly in the large with transformations in the small. The approach’s ability to generate accurate software artifacts depends largely on how user requirements are captured and transformed. The CMDA system employs innovative approaches and techniques to enable users represent their requirements properly. This paper briefly describes the CMDA system, its user interface and the various inputs captured from the user.

Software development can be thought of as the evolution of abstract requirements into a concrete software system. The evolution, achieved through a successive series of transformations, is inherently a complex process. The inherent complexities, that often make these transformations sub-optimal, are further aggravated by inefficient capture and usage of requisite information during transformation. While some understanding of software may be reasonably clear at a given time, the future dependencies may not be fully understood or accessible. The clarifications obtained over time make the system more concretely understood, but there may be software information leaks (SILs) as some relevant information is lost. Some key SILs may be due to failure to be fully acquainted with dependencies between various software artifacts. In this paper, our objective is to define SILs as concept, codify an essential set of canonical leaks, and introduce solutions for dealing with some of them.

With the relentless growth in software, automated support for visualizing and navigating software artifacts is no longer a luxury. As packaged software components and middleware occupy more and more of the software landscape, interoperability relationships point to increasingly relevant software change impacts. Packaged software now represents over thirty-two percent of the software portfolio in most organizations benchmark (Rubin, 2001). While traceability and dependency analysis has effectively supported impact analysis in the past, they fall short today as their webs of dependency information extend beyond most software engineers ability to comprehend them. This paper describes research for extending current software change impact analysis to incorporate software architecture dependency relationships. We discuss how we address the extensive dependency information involved, extending impact analysis using software visualization, and outline our approach to employing the software impact analysis virtual environment.

As software engineering practice evolves to respond to demands for distributed applications on heterogeneous platforms, software change is increasingly influenced by middleware and components. Interoperability dependency relationships now point to more relevant impacts of software change and necessarily drive the analysis. Software changes to software systems that incorporate middleware components like Web services expose these systems and the organizations they serve to unforeseen ripple effects that frequently result in failures. Current software change impact analysis models have not adequately addressed this trend. Moreover, as software systems grow in size and complexity, the dependency webs of information extend beyond most software engineers ability to comprehend them. This paper examines preliminary research for extending current software change impact analysis to incorporate interoperability dependency relationships for addressing distributed applications and explores three dimensional (3D) visualization techniques for more effective navigation of software changes.

Software change impact analysis has gained considerable attention with recent challenges of the Year 2000 Date situation. As the software community recognizes the growing need to identify consequences of these changes, impact analysis is making its way into the software process. Dependencies between software life cycle objects are becoming more numerous and complex as many software systems grow beyond a million of lines of code. Software change efforts are plagued with widely varying estimates for implementing software changes, since the impacts of the change are not readily known in advance. The introduction of software change impact analysis into the software process adds more fidelity to software change visibility, enabling more accurate software change estimates. The paper examines where impact analysis is applied during software changes and describes how impact analysis can be addressed in the software process.

With all the recent media attention on the Year 2000 Date problem, many software maintainers are questioning what all the fuss is about. More ofen than not, the software part of the problem appears to be nothing more than a typical data element expansion with its associated & conversion (scrub) and testing. While the impact of a date change may be larger than some, it is clearly not drastic as compared with implementing intelligent objects on a relational database or even introducing a client-server architecture. In this panel, we bring together several recognized Year 2000 date experts to discuss the challenge from the maintenance perspective. It is interesting that these experts have already “e significant contributions in the software maintenance field and ofer considerable insight into key issues many software organizations face with the Year 2000. Panelist include: Thomas Backman of the MITRE Corporation who has assessed the Year 2000 situation for the Department of Defense under the direction of Anita Jones (Director of Defense Research and Engineering); Shawn Bohner of the Mitretek Systems supports public sector agencies and associations in addressing the Year 2000 situation and other software system modernization issues; Elliot Chikofsky of DMR Group who leads the IEEE Computer Society Millennium Task Force serving as the focal point for Year 2000 solutions; Peter de Jager, sponsored by Data Dimensions is a recognized authority and highly regarded speaker on Year 2000; and Nicholas Zvegintzov of Sofiare Management Network, recognized speaker and author who challenged the Year 2000 community to examine the problem objectively in his American Programmer article entitled, ‘5% Year 2000 ar a Racket and Ruse.”

The term impact analysis is used with many meanings. A three-part framework for characterizing and comparing diverse impact analysis approaches is defined. The parts correspond to how an approach is used to accomplish impact analysis, how an approach does impact analysis internally, and the effectiveness of the impact analysis approach. To illustrate the framework's application, five impact analysis approaches are illustrated according to it.>

The authors introduce a software maintenance process model that emphasizes impact analysis and forms a framework for software maintenance metrics support. Schedule, resource, and other constraints frequently subvert efforts to build and maintain a software product. using direct graphs, the authors suggest traditional process and product metrics, as well as new impact analysis metrics that address software work-product traceability and inter-work-product dependencies. Management can use these and other metrics to understand and control the maintenance process dynamically. As changes are requested, measurements can be made, impact assessed, and implementation decisions made. Moreover, the more the impact is understood, the better the change can be controlled; hence risks are minimized.>