Restoring a legacy: lessons learned

Rebuilding a legacy system has some parallels to the restoration of a work of art. The authors draw upon this comparison to illustrate the challenges they faced in redesigning a telephony system. The restoration involved far more than updating the code, the development team also had to understand the existing architecture, add new functionality, and develop a long-term hardware migration plan. The technical and managerial lessons learned should prove valuable to those involved in similar projects     

Rapid prototyping: lessons learned

Opinions on rapid prototyping as a practical development tool vary widely, with conventional wisdom seeing it more as a research topic than a workable method. The authors counter this notion with results from 39 case studies, most of which have used this approach successfully     

MySQL: lessons learned on a digital library

In recent years, the open source products have achieved enterprise-level quality. In response, enterprises have become more interested in migrating from proprietary, commercial products to open source. Businesses around the world commonly use the two leading open source relational DBMSs, MySQL and PostgreSQL. The Los Alamos National Laboratory's Research Library has used MySQL databases for years. However, a recent project to develop a comprehensive database of scientific journal articles and citation information revealed its unique strengths and features.     

Teaching PSP: challenges and lessons learned

Software engineering educators need to provide environments where students learn about the size and complexity of modern software systems and the techniques available for managing these difficulties. Five universities used the personal software process to teach software engineering concepts in a variety of contexts.     

Ada and real-time robotics: lessons learned

The Supervisory Telerobotics Laboratory (Steler) at the Jet Propulsion Laboratory (JPL) has developed a prototype telerobotic system to demonstrate the type of technology that will be used aboard Space Station Freedom Although the concept of telerobotics for space exploration is not new, the Steler system broke new ground in its demonstration of the feasibility of a local-remote architecture, including ground-remote control, for space applications. A remote space environment poses some interesting computational challenges to ground-remote control of space applications. A remote site has limited computation facilities, is burdened by minimal bandwidth and by round-trip communication delays of as much as 8 seconds, and yet is expected to respond quickly, predictably, and with recoverability to any anomalous situation. Additional design constraints are imposed by NASA's limitations on software, including on-board programs for the robot, being uploaded to the remote site without prior flight qualification. The authors discuss the use of Ada to meet the computational requirements of this project     

UML formal semantics: lessons learned

The article below presents the insights gained during a number of years of research dedicated to the formalisation of the Unified Modeling Language.     

Usability testing in a competive market: lessons learned

Abstract

Usability testing is a relatively new and rapidly developing field. Newcomers to usability testing typically enter the profession with a knowledge of social science research methods and the belief that usability testing is conducted in a lab using thinking aloud techniques to identify usability defects. Our practice of usability testing at Mead Data Central has shown that these core beliefs represent an approach of limited utility in designing products like the LEX1S®NEXIS® research systems. In this paper, we describe our experiences in conducting traditional usability testing and how we used the results of those efforts to develop more effective methods of testing for Mead Data Central's products and customers.     

Cognitive skills training: lessons learned

This paper describes lessons we have learned about presenting cognitive skills training. We have used ShadowBox as our training approach (Klein and Borders in J Cogn Eng Decis Mak 10:268–280, 2016), but the lessons apply regardless of specific techniques employed. We analyze key takeaways and lessons learned throughout the course of multiple ShadowBox projects. We explain how the original ShadowBox mission statement has evolved based on these lessons learned. Recommendations are offered for others who are engaged in cognitive skills training.     

Interactive remote instruction: lessons learned

This paper describes experiences with the use of the interactive remote instruction (IRI) system which was used to teach a computer science graduate course at Old Dominion University during the Fall 1995 semester. Through the use of high-speed networks and high performance workstations, IRI creates a virtual classroom so that geographically dispersed students can fully participate in a class. Central to this system is the availability of a personal workstation to each student through which the class is taken. Placing a workstation at each student's disposal opens the opportunity for student interaction and group collaboration. We compare this approach with other educational settings and describe lessons learned from instructor, student and technical perspectives. We also describe changes we are putting in place for an expanded usage in the coming fall semester using fiberoptic cable supporting a WAN internet protocol.     

Design measurement: some lessons learned

The author extracts from several measurement projects some of the important lessons he has learned about measurement in general and design measurement in particular. He synthesizes from these lessons a design-measurement framework in an attempt to communicate his personal measurement experience to other software engineers. The lessons he has learned fall into three areas: (1) how measurement must be applied in individual experiments or case studies; (2) how measurement can help continuously improve an organization's state of the practice; and (3) why measurement requires automated support.<>     

Mixing real and virtual conferencing: lessons learned

This paper describes a conference which linked several remote location sites via a virtual environment so that the virtual audience could follow the presentations and interact with real presenters. The aim was to assess the feasibility of linking distributed virtual audiences to an ongoing conference event. The conference consisted of an annual gathering of researchers and developers of a global information technology consultancy firm based in India. This firm developed a virtual environment specifically for distributed collaboration across sites. During the conference, researchers gathered various types of data, including participant observations, interviews, capture of the virtual environment and a survey of the audience. These data are analysed in the paper. The main finding is that a number of ‘low tech’ improvements could be made to the operation of the system that could greatly enhance this type of virtual conferencing. A related finding is that the visual fidelity of the environment and of the avatars plays a lesser role than other factors such as audio quality. Given the paucity of research on how virtual conferencing can substitute for travel, plus the urgency of this topic for environmental reasons, a number of suggestions are made for the implementation of remote virtual conference participation.     

Handhelds go to school: lessons learned

Working in conjunction with teachers, researchers have developed a series of projects exploring the potential for using wireless handheld devices to enhance K-12 classroom instruction.     

ERP requirements engineering practice: lessons learned

Standard off-the-shelf requirements engineering processes have become a key to conceptualizing any integrated, corporate-wide solution based on packaged enterprise resource planning software. A generic RE model offers defined processes, suggests process stakeholders, specifies steps to accomplish tasks, indicates task dependencies, and provides standard tool support for ERP RE. Essentially, any off-the-shelf RE process is about composition and reconciliation: you start with a general set of business process and data requirements, then explore standard ERP functionality to see how closely it matches your organization's process and data needs.     

Requirements engineering within a large-scale security-oriented research project: lessons learned

Requirements engineering has been recognized as a fundamental phase of the software engineering process. Nevertheless, the elicitation and analysis of requirements are often left aside in favor of architecture-driven software development. This tendency, however, can lead to issues that may affect the success of a project. This paper presents our experience gained in the elicitation and analysis of requirements in a large-scale security-oriented European research project, which was originally conceived as an architecture-driven project. In particular, we illustrate the challenges that can be faced in large-scale research projects and consider the applicability of existing best practices and off-the-shelf methodologies with respect to the needs of such projects. We then discuss how those practices and methods can be integrated into the requirements engineering process and possibly improved to address the identified challenges. Finally, we summarize the lessons learned from our experience and the benefits that a proper requirements analysis can bring to a project.     

分布式蠕虫蜜罐部署策略分析

蜜罐的捕获能力来自于其数量和分布位置,在同一网络拓扑中,运用合理的部署策略,可以部署最少的蜜罐,在最短的时间内捕获到蠕虫样本。本文讨论了蜜罐以及蠕虫扫描策略的研究内容,对红色代码蠕虫进行了深入的分析,根据随机扫描扫描策略建立了蜜罐部署策略模型,针对红色代码这种网络蠕虫的扫描策略,在模拟环境下对蜜罐部署策略进行了验证。     

Developing groupware for requirements negotiation: lessons learned

Defining requirements is a complex and difficult process, and defects in the process often lead to costly project failures. There is no complete and well-defined set of requirements waiting to be discovered in system development. Different stakeholders: users, customers, managers, domain experts, and developers, come to the project with diverse expectations and interests. Requirements emerge in a highly collaborative, interactive, and interdisciplinary negotiation process that involves heterogeneous stakeholders. At the University of Southern California's Center for Software Engineering, we have developed a series of groupware implementations for the WinWin requirements negotiation approach. The WinWin approach involves having a system's success-critical stakeholders participate in a negotiation process so they can converge on a mutually satisfactory or win-win set of requirements. The WinWin groupware system, which has evolved over four generations, enables and facilitates heterogeneous stakeholder participation and collaboration. Each generation reflects an increase in our understanding of what is needed for successful WinWin groupware operations and technology support. The authors present the major lessons they learned during WinWin's development     

Introducing XP into Greenfield Projects: lessons learned

ThoughtWorks introduced XP into an organization and successfully completed a bleeding-edge technology project with client staff that had no previous experience using an agile development approach. This article illustrates not only how XP helped make the project a success, but also gives other lessons learned regarding the introduction of XP at client sites.