Architectural modifications to deployed software

We discuss the nuts and bolts of industrial large-scale software modification projects. These projects become necessary when system owners of deployed systems hit architectural barriers. The mastery of such projects is key to the extension of the best-before date of business-critical software assets. Our discussion comprises the process for problem analysis, pricing and contracting for such projects, design and implementation of tools for code exploration and code modification, as well as details of service delivery. We illustrate these concerns by way of a real-world example where a deployed management information system required an invasive modification to make the system fit for future use. The chosen project is particularly suited for a complete treatise because of its size (just 90,000 LOC), and the nature of the relevant architectural modification (namely, a form of data expansion). We share the lessons that we learned in this and other architectural modification projects.     

Inside the Windows security push

The Microsoft Windows development team spent two months in 2002 analyzing product design, code, and documentation to fix security issues. The results of this security push include a new process and several lessons learned for future projects.     

Useful business cases: value creation in IS projects

Business cases have become popular as part of managing value creation in IS projects. Nevertheless, business cases are often poorly linked to value creation activities and organizations struggle to develop business cases that are useful and express more than simple cost savings. This action research study seeks to improve the usefulness of business cases in IS projects. We used collaborative action research with Danish municipalities to improve their practices when developing and using business cases and to change their perceptions of what constitutes a good business case that is useful during implementation and value creation. This article presents lessons learned from our action research, lessons that we incorporated into a business case method and subsequently evaluated with IS managers. There are three lessons on (1) improving the content of business cases, (2) how to develop business cases, and (3) the use of business cases in subsequent value creation. These lessons summarize our findings and the contributions are that we in the business case method propose to (1) include minimal contents, (2) develop social commitment, and (3) structure for dynamic use during value creation. We discuss the lessons and contributions related to research on IS business cases and value creation.     

CP-6: quality and productivity measures in the 15-year life cycle of an operating system

The CP-6 operating system and its compilers, databases, communications, and end-user interfaces were designed, developed, tested, and installed at customer sites in three years from the date the project began. This paper describes the history of this project, the methodology used to produce the 4.7 million lines of code, and the metrics covering development productivity and software quality over 18 releases in the last 12 years. The rigorous methodology and standards used throughout the project, which cover the full lifecycle of design, development, and support, include a statistical database covering development manpower, lines of code produced, and error reports covering 12 years in customer installations. The project achieved software development productivity rates twice as high as those of comparable projects, and error rates half those of comparable projects for product software. The key lessons learned may be applied to other software development projects.     

Improving students’ programming quality with the continuous inspection process: a social coding perspective

College students majoring in computer science and software engineering need to master skills for highquality programming. However, rich research has shown that both the teaching and learning of high-quality programming are challenging and deficient in most college education systems. Recently, the continuous inspection paradigm has been widely used by developers on social coding sites (e.g., GitHub) as an important method to ensure the internal quality of massive code contributions. This paper presents a case where continuous inspection is introduced into the classroom setting to improve students’ programming quality. In the study, we first designed a specific continuous inspection process for students’ collaborative projects and built an execution environment for the process. We then conducted a controlled experiment with 48 students from the same course during two school years to evaluate how the process affects their programming quality. Our results show that continuous inspection can help students in identifying their bad coding habits, mastering a set of good coding rules and significantly reducing the density of code quality issues introduced in the code. Furthermore,we describe the lessons learned during the study and propose ideas to replicate and improve the process and its execution platform.     

Managing object-oriented software development

Managing object-oriented projects is subtly different than managing non-object-oriented ones. Object-oriented projects employ a different unit of decomposition, they encourage an incremental and iterative process, and quantitatively, they demand different kinds of measures. This paper examines the nature of managing object-oriented projects, and offers a variety of lessons learned from a number of real projects.Portions of this article are adapted from [Booch 1995].     

Software process evolution at the SEL

The Software Engineering Laboratory of the National Aeronautics and Space Administration's Goddard Space Flight Center has been adapting, analyzing, and evolving software processes for the last 18 years (1976-94). Their approach is based on the Quality Improvement Paradigm, which is used to evaluate process effects on both product and people. The authors explain this approach as it was applied to reduce defects in code. In examining and adapting reading techniques, we go through a systematic process of evaluating the candidate process and refining its implementation through lessons learned from previous experiments and studies. As a result of this continuous, evolutionary process, we determined that we could successfully apply key elements of the cleanroom development method in the SEL environment, especially for projects involving fewer than 50000 lines of code (all references to lines of code refer to developed, not delivered, lines of code). We saw indications of lower error rates, higher productivity, a more complete and consistent set of code comments, and a redistribution of developer effort. Although we have not seen similar reliability and cost gains for larger efforts, we continue to investigate the cleanroom method's effect on them     

Using Prezi to Structure Online Videos for Information Literacy Instruction: A Case Study

This case study describes how librarians at Radford University use Prezi, a free, cloud-based, online presentation software, as a platform to structure the content of short online videos focused on various research skills. By utilizing Prezi's flexible formatting, templates, and panning and zooming features, librarians are able to visually illustrate the relationships between varying concepts. This article discusses the online video creation process, best practices, and lessons learned from delivering structured information literacy instruction in the video medium.     

Toward a reference process for developing wireless Internet services

Wireless Internet services such as mobile Web applications promise an enormous market potential. The field is characterized by extreme time-to-market pressure and insufficient knowledge about development procedures and technical constraints. This results in insufficient guidance for project managers and software developers on selecting appropriate development processes, techniques, methods, and tools. In addition, there is an enormous lack of knowledge about the effects (such as effort consumption, defect injection) of such technologies that hinders the transfer of innovative technologies into practice. This article describes an initial reference process by summarizing essential technologies for the development of wireless Internet services and experience with these technologies on the levels of life cycle processes, engineering processes, and managerial processes. The reference process is based on a comprehensive literature survey and the execution of development projects for wireless Internet services. The goal of the article is to provide domain-specific guidance for project managers and software developers with accompanying lessons learned from the past.     

Augmented reality projects in the automotive and aerospace industries

The 2003 International Symposium on Mixed and Augmented Reality was accompanied by a workshop on potential industrial applications. The organizers wisely called it potential because the real use of augmented reality (AR) in an industrial context is still in its infancy. Our own experience in this field clearly supports this viewpoint. We have been actively involved in the research, development, and deployment of AR systems in the automotive, aviation, and astronautics industries for more than five years and have developed and implemented AR systems in a wide variety of environments while working at DaimlerChrysler in Germany. In this article we have selected 10 AR projects from those we have managed and implemented in the past to examine the main challenges we faced and to share some of the lessons we learned.     

Process Management in Practice Applying the FUNSOFT Net Approach to Large-Scale Processes

Management of business and software processes are areas of increasing interest, which evolved nearly independently from each other. In this article we present an approach to process management that has been applied to business and software processes and which, thereby, enabled cross-fertilization between both areas. The goal of this article is to report lessons learned in industrial as well as academic business and software process management projects.     

Exploring agile values in method configuration

The Method for Method Configuration (MMC) has been proposed as a method engineering approach to tailoring information systems development methods. This meta-method has been used on a variety of methods, but none of these studies have focused on the ability to manage method tailoring with the intention to promote specific values and goals, such as agile ones. This paper explores how MMC has been used during three software development projects to manage method tailoring with the intention to promote agile goals and values. Through content examples of method configurations we have shown that it is possible to use MMC and its conceptual framework on eXtreme Programming and we report on lessons learned with regard to maintaining coherency with the overall goals of the original method.     

Integration issues elucidated in large-scale information systems development

This article explores some basic issues in system integration by examining the integration process with information systems. The article begins with a discussion of the domain of interest. Terms are defined, the software process is reviewed, and two system categories are established. It is shown that software is materially different from hardware. Moreover, these differences present opportunities for reducing the integration effort. Several methods that take advantage of software's special characteristics are identified, and a case study of one environment provides some empirical evidence that reveal the benefits that may follow. The article concludes with some observations regarding the transfer of the lessons learned with information systems to other application domains-both hardware and software.This work was supported in part by the U.S. Navy, Space and Naval Warfare Systems Command (SPAWAR) under contract N00039-89-C-001, task VMAR9 with the Office of Naval Research (ONR).     

Longitudinal use of method rationale in method configuration: an exploratory study

Organizations that implement a company-wide method to standardize the way that systems development is carried out still have a need to adapt this method to specific projects. When adapting this method the end results should align with the basic philosophy of the original method. To this end, goal-driven situational method engineering has been proposed. However, there are no longitudinal studies on systems developers’ use of such approaches and their intentions to balance their need of adaptation with the basic philosophy of the original method. This paper explores how goal-driven method configuration has been used by two project teams in six successive systems development projects, with the intention to balance the goals and values of a specific method with the systems developers’ need for method adaptation. We do that through the use of method rationality resonance theory. Through content examples of method configurations, we report on (a) lessons learned from the project teams’ work on balancing the goals of the company-wide method with their needs and (b) theoretical development of the method rationality resonance theory.     

Using structured benchmarking to fast-track CMM process improvement

Sikorsky Aircraft designs and manufactures helicopters. In today's environment of glass cockpits, fly-by-wire control systems, and special missions, we are also in the integration business-which, from this article's perspective, translates into embedded software. We develop large systems in-house, such as the Comanche Mission Equipment Package, comprising hundreds of thousands of lines of code, and we are deeply involved in enhancing large legacy systems for our Black Hawk and Seahawk platforms. Sikorsky Aircraft in pursuit of a Capability Maturity Model rating, determined that software benchmarking would help its process improvement and assessment effort. The article describes how Sikorsky prepared for benchmarking trips, structured its questionnaire, aggregated results and evaluated lessons learned     

An architectural model for software testing lesson learned systems

ContextSoftware testing is a key aspect of software reliability and quality assurance in a context where software development constantly has to overcome mammoth challenges in a continuously changing environment. One of the characteristics of software testing is that it has a large intellectual capital component and can thus benefit from the use of the experience gained from past projects. Software testing can, then, potentially benefit from solutions provided by the knowledge management discipline. There are in fact a number of proposals concerning effective knowledge management related to several software engineering processes.ObjectiveWe defend the use of a lesson learned system for software testing. The reason is that such a system is an effective knowledge management resource enabling testers and managers to take advantage of the experience locked away in the brains of the testers. To do this, the experience has to be gathered, disseminated and reused.MethodAfter analyzing the proposals for managing software testing experience, significant weaknesses have been detected in the current systems of this type. The architectural model proposed here for lesson learned systems is designed to try to avoid these weaknesses. This model (i) defines the structure of the software testing lessons learned; (ii) sets up procedures for lesson learned management; and (iii) supports the design of software tools to manage the lessons learned.ResultsA different approach, based on the management of the lessons learned that software testing engineers gather from everyday experience, with two basic goals: usefulness and applicability.ConclusionThe architectural model proposed here lays the groundwork to overcome the obstacles to sharing and reusing experience gained in the software testing and test management. As such, it provides guidance for developing software testing lesson learned systems.     

Supporting Vicarious Learning With Collaborative Lessons Learned Programs

Vicarious learning allows an observer to improve his decision making and modify his actions through observing others' past actions and resulting consequences. As organizations become larger and more disconnected, it becomes an increasing challenge to meaningfully share lessons learned allowing people to learn vicariously from both good and adverse experiences of others. In an effort to promote vicarious learning across disconnected groups, organizations create lessons learned programs to share information. The goal of a lessons learned program is to improve organizational effectiveness by avoiding costly errors "before" reoccurring in other parts of the organization. This type of antecedent learning requires collaboration between the people at the source and those receiving the lesson, as well as any human intermediaries involved with the process, to amplify the benefits of lessons learned. This paper makes explicit the connection between vicarious learning and collaborative lessons learned programs and develops a lessons learned process model using the theory of knowledge creation. The evaluation of four case studies reveals that a lessons learned program operates most effectively when the information is targeted to recipients who would find it useful and when human collaboration is acknowledged and supported by intermediaries     

Electronic Publishing at Routledge

This article describes how an independent commercial academic publisher initiated its electronic publishing programme. It outlines the range of electronic activities under development and some of the issues addressed during the creation of electronic resources. Case studies of two early projects are included: a multimedia teaching too, A Right to Die? The Dax Cowart Case; and an SGML textbase, the Arden Shakespeare CD-ROM. In addition, the Routledge Encyclopedia of Philosophy is discussed as an example of the second generation of electronic projects at Routledge, highlighting lessons learned from previous projects and some of the issues relating to the production of a simultaneous print and electronic resource.     

Cultivation and engineering of a software metrics program

Abstract. This paper reports from a case study of an organization that implements a software metrics program to measure the effects of its improvement efforts. The program measures key indicators of all completed projects and summarizes progress information in a quarterly management report. The implementation turns out to be long and complex, as the organization is confronted with dilemmas based on contradictory demands and value conflicts. The process is interpreted as a combination of a rational engineering process in which a metrics program is constructed and put into use, and an evolutionary cultivation process in which basic values of the software organization are confronted and transformed. The analysis exemplifies the difficulties and challenges that software organizations face when bringing known principles for software metrics programs into practical use. The article discusses the insights gained from the case in six lessons that may be used by Software Process Improvement managers in implementing a successful metrics program.     

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