Showing papers in "IEEE Software in 2002"
TL;DR: Whether or not many software organizations admit it, they face the challenge of sustaining the level of competence needed to win contracts and fulfill undertakings.
Abstract: Software organizations' main assets are not plants, buildings, or expensive machines. A software organization's main asset is its intellectual capital, as it is in sectors such asconsulting, law, investment banking, and advertising. The major problem with intellectual capital is that it has legs and walks home every day. At the same rate experience walks out the door, inexperience walks in the door. Whether or not many software organizations admit it, they face the challenge ofsustaining the level of competence needed to win contracts and fulfill undertakings.
753 citations
TL;DR: The article illustrates, with a home integration system example, how FORM brings efficiency into product line development.
Abstract: The feature-oriented reuse method analyzes and models a product line's commonalities and differences in terms of product features and uses the analysis results to develop architectures and components. The article illustrates, with a home integration system example, how FORM brings efficiency into product line development.
519 citations
TL;DR: This article describes an extensible tool that uses lightweight static analysis to detect common security vulnerabilities (including buffer overflows and format string vulnerabilities).
Abstract: Most security attacks exploit instances of well-known classes of implementation flaws. Developers could detect and eliminate many of these flaws before deploying the software, yet these problems persist with disturbing frequency-not because the security community doesn't sufficiently understand them but because techniques for preventing them have not been integrated into the software development process. This article describes an extensible tool that uses lightweight static analysis to detect common security vulnerabilities (including buffer overflows and format string vulnerabilities).
507 citations
TL;DR: Some of the technological challenges of building today's complex Web software applications, their unique quality requirements, and how to achieve them are discussed.
Abstract: Web applications have very high requirements for numerous quality attributes. This article discusses some of the technological challenges of building today's complex Web software applications, their unique quality requirements, and how to achieve them.
347 citations
TL;DR: The concepts, activities, and practices described here can lead to successful product line development.
Abstract: Software product lines are emerging as a viable, important software development paradigm. Based on the Software Engineering Institute's research and experience, the concepts, activities, and practices described here can lead to successful product line development. How-to's, success stories, and lessons learned expand on the approach.
241 citations
TL;DR: A systematic process from requirements elicitation through formal specification, user interface prototyping, rigorous design, and coding is used to deliver a highly reliable system that meets all its throughput and usability goals.
Abstract: Praxis Critical Systems recently developed a secure certification authority for smart cards that had to satisfy performance and usability requirements while meeting stringent security constraints. The authors used a systematic process from requirements elicitation through formal specification, user interface prototyping, rigorous design, and coding to ensure these objectives' achievement. They show how a process that achieves normal commercial productivity can deliver a highly reliable system that meets all its throughput and usability goals.
239 citations
TL;DR: The EU and European governments have been funding product family development projects for years and the topics each has addressed, and the main results obtained thus far.
Abstract: The EU and European governments have been funding product family development projects for years. This article overviews the different projects, the topics each has addressed, and the main results obtained thus far.
197 citations
TL;DR: The authors show how to use Bayesian networks, a graphical modeling technique, to predict software defects and-perform "what if" scenarios.
Abstract: Software measurement can play an important risk management role during product development. For example, metrics incorporated into predictive models can give advance warning of potential risks. The authors show how to use Bayesian networks, a graphical modeling technique, to predict software defects and-perform "what if" scenarios.
181 citations
TL;DR: Six theses are introduced to illuminate the problems of pursuing SPI and highlight the differences between disciplined versus creative work and procurer risks versus user satisfaction.
Abstract: Two dichotomies characterize software process improvement efforts and approaches: disciplined versus creative work and procurer risks versus user satisfaction. Based on these perspectives, the authors introduce six theses to illuminate the problems of pursuing SPI.
179 citations
TL;DR: The authors describe their experiences with applying PMA techniques for collecting and analyzing experience in software organizations.
Abstract: Postmortem analysis (PMA) is a practical method for initiating knowledge management by capturing experience and improvement suggestions from completed projects. It requires little effort and quickly provides initial results, making it suitable even for small- and medium-size projects and companies. The authors describe their experiences with applying PMA techniques for collecting and analyzing experience in software organizations.
165 citations
TL;DR: This article describes a flexible, model-driven approach for engineering Web applications that succeeds through a focus on user interface design and usability that integrates readily with lightweight or agile development processes under compressed development schedules.
Abstract: This article describes a flexible, model-driven approach for engineering Web applications that succeeds through a focus on user interface design and usability. Its simple, model-driven techniques work well for novel applications and integrate readily with lightweight or agile development processes under compressed development schedules.
TL;DR: How to optimize a product line's economic benefits by considering the adoption context and using product line scoping techniques is discussed.
Abstract: An organization faces many challenging decisions when transitioning to product line development: What is the best way to adopt a product line approach? How can we avoid disrupting regular product development? Once adopted, how should we evolve the product line? The article discusses how to optimize a product line's economic benefits by considering the adoption context and using product line scoping techniques.
TL;DR: The authors discuss the value of variability in product lines and describe their approach to modeling and using variability, which evolved from their work at Bosch.
Abstract: Although the product line approach for automotive systems is promising because it gains significant economies of scope, it requires systematic planning and continuous management of variability throughout the development process. The authors discuss the value of variability in product lines and describe their approach to modeling and using variability, which evolved from their work at Bosch.
TL;DR: This article surveys the experience software engineers in a wide, range of industries have had in deploying agile methods.
Abstract: The software industry seems to be embracing yet another change to the way it does business. Because of their emphasis on agility and time-to-market, many programming shops are moving to agile methods. Unlike more traditional approaches, these methods focus on generating early releases of working products using mostly collaborative techniques such as pair programming, refactoring, and having customers work on site as team members. Programmers use these releases-which are working products, not prototypes-to demonstrate features and functions to stakeholders involved in their use, marketing, and support. This article surveys the experience software engineers in a wide, range of industries have had in deploying agile methods.
TL;DR: An informal overview of the situation of European companies regarding requirements engineering is given and whether the same problems still exist today, even though potential solutions have been provided in the literature for some time is investigated.
Abstract: This article gives an informal overview of the situation of European companies regarding requirements engineering. It reviews what progress the industry has made with respect to the requirements-related problems identified years ago and calls attention to the gap between RE practice and the solutions provided by research. The authors aim to determine whether the same problems still exist today, even though potential solutions have been provided in the literature for some time.
TL;DR: The success stories of successful software product line deployments often read like epic adventures as mentioned in this paper, but along the journey there is risk, hardship, sacrifice, heroes, antagonists, love lost, love found, and fortuitous events of both happy and tragic consequences.
Abstract: S tories of successful software product line deployments often read like epic adventures. In the end, there is triumph of inspirational proportions, but along the journey there is risk, hardship, sacrifice, heroes, antagonists, love lost, love found, and fortuitous events of both happy and tragic consequences. For example, for Cummins to achieve its impressive software product line successes, it stopped all product deployments for six months while it rearchitected its engine control software, support technology, organizational charts, and processes. Imagine the consequences if, after an extended production shutdown, unanticipated events had led to project failure. Although these epics make for great, inspiring reading, many software organizations need to operate on a more predictable and less dramatic story line. They can’t afford to slow or stop production for six months to reinvent themselves, even if the potential payoff is huge. For most organizations, the risks, timetables, efforts, and costs experienced by the pioneers represent an adoption barrier to software product line practice. For software product lines to become part of mainstream software engineering culture, organizations need software product line strategies with low adoption barriers. They need low-risk strategies that afford small upfront effort, incremental transition from current practices, and rapid return on investment. Several organizations have recognized this need and are successfully creating technology and techniques that lower the adoption barrier to software product lines (see www.biglever.com, www.esi.es/Projects/Reuse/projects.htm, and www.iese.fhg.de/Business_Areas/ Product_Line_Development). These new approaches offer two things not found in the epic proactive software product line approaches. The first is lightweight technologies and techniques that specifically support software product line engineering. The second is a variety of adoption models for establishing and operating a software product line practice. Lightweight software product line technologies and techniques minimize the paradigm shift between conventional software Although these epics make for great, inspiring reading, many software organizations need to operate on a more predictable and less dramatic story line.
TL;DR: This special issue focuses on the technical, managerial, and organizational activities related to introducing practices that emphasize proactive reuse, interchangeable components, and multiproduct planning cycles to construct high-quality products faster and cheaper.
Abstract: E li Whitney revolutionized the manufacturing of rifles using interchangeable parts Henry Ford did the same for automobiles, integrating the idea of interchangeable parts and an assembly line A growing number of software development organizations are adopting approaches that emphasize proactive reuse, interchangeable components, and multiproduct planning cycles to construct high-quality products faster and cheaper Standard methods, referred to as software product line or software family practices, have developed around these approaches This special issue focuses on the technical, managerial, and organizational activities related to introducing these practices guest editors’ introduction
TL;DR: A process-oriented perspective on large student projects guides students in integrating end-to-end life-cycle skills and provides consistency of experience among projects.
Abstract: A process-oriented perspective on large student projects guides students in integrating end-to-end life-cycle skills and provides consistency of experience among projects. After conducting 49 Capstone projects, the authors learned that they must cultivate a process culture, that agile processes provide a bridge from ad hoc programming assignments to organized project work, and that process requires a suitable infrastructure of tools and process expertise.
TL;DR: There is a "sweet spot" where modeling efforts can provide significant benefit without incurring the costs of onerous documentation, and two Internet startup companies adopting effective and efficient modeling and documentation practices are described.
Abstract: This article describes the experiences of two Internet startup companies adopting effective and efficient modeling and documentation practices. Both organizations successfully developed agile approaches for enterprise architectural modeling, one taking a communal team-based approach and the other a chief-architect approach. They adopted similar strategies for project-level modeling, adopting highly iterative and incremental approaches that focused on modeling and not on the resulting models themselves. There is a "sweet spot" where modeling efforts can provide significant benefit without incurring the costs of onerous documentation.
TL;DR: One company's solution was to develop a needs-based approach that would deliver knowledge just in time, but the results of these events could never be packaged and reused for future projects.
Abstract: Rarely has a professional field evolved as quickly as software development. Software organizations are continuously struggling to keep abreast of new technologies frequently changing customer requirements; and increasingly complex software architectures, methods, and tools. Recently, many organizations have come to understand that to succeed in the future, they must manage and use knowledge more effectively at individual, team, and organizational levels. Efficient creation, distribution, and reuse of up-to-date knowledge are critical success factors that unfortunately remain difficult to achieve in practice. Knowledge-sharing events between group members have proven to be a better way of sharing knowledge than the database, but the results of these events could never be packaged and reused for future projects. One company's solution was to develop a needs-based approach that would deliver knowledge just in time.
TL;DR: It is explained how the team found that testing was critical to the success of building Evant's application at speed while maintaining high quality.
Abstract: This article documents the experiences of Evant's Extreme Programming team with testing XP. Testing is fundamental to XP but is a practice that often falls by the wayside in today's fast-paced Web application development culture. From the beginning, Evant adhered to each of XP's principles, and testing was no exception. This article explains how the team found that testing, positioned as the drive behind development, was critical to the success of building Evant's application at speed while maintaining high quality.
[...]
TL;DR: State machines make it easy to eliminate duplication, honoring the DRY principle, and let you write more expressive code, because you can specify intent and implementation independently.
Abstract: We are surrounded by real-world state machines: ballpoint pen retractor mechanisms, vending machines, washing-machine controllers, digital watches. They are a trivial but underused technology that can simplify how we implement programs that must track how they got to their current state before handling a new event. However, many programmers feel that state machines are only useful when they're developing communication protocol stacks, which is not an everyday activity. This is unfortunate. State machines can be appropriate in surprising circumstances. Correctly applied, they will result in faster, more modular, less coupled, and easier to maintain code. State machines make it easy to eliminate duplication, honoring the DRY principle. They also let you write more expressive code, because you can specify intent and implementation independently. These are all good, pragmatic, reasons to investigate them further, so let's look at some simple state machine implementations and problems they can solve.
TL;DR: The author examines the seven most common myths or misconceptions behind this missing link between testing and requirements engineering, and asserts that the authors can save a great deal of time and money if testers are involved in testing requirements.
Abstract: The author asserts that we can save a great deal of time and money if testers are involved in testing requirements. If the requirements have some consistent quality criteria, testers can raise questions and find problems before we turn them into code. A strong link between testing and requirements engineering can benefit both sides, but often this link is missing. The author examines the seven most common myths or misconceptions behind this missing link.
TL;DR: The current Internet and intranet development climate with earlier releases is compared and the 10 greatest risks are identified and the just do it attitude of the past few years has done as much harm as good to software engineering profession.
Abstract: This article contrasts the current Internet and intranet development climate with earlier releases and identifies the 10 greatest risks. Software engineers need to strike a balance between the technologies that many in the Internet world depend upon, on the one hand, and the tried and true processes that promote risk management and help us achieve business goals, on the other. The just do it attitude of the past few years has done as much harm as good to the software engineering profession. While a few good practices have emerged for Internet development, many time-tested software engineering practices were jettisoned based on the faulty belief that teams don't have time to put these practices to work. By looking at the list of deadly risks, we can recognize our mistake.
TL;DR: The paper considers how the mobile phone company initiated and used a product line to develop and deliver mobile browser products.
Abstract: Product lines must be product and application driven instead of reuse or platform driven, at least, that is the lesson learned at Nokia. The paper considers how the mobile phone company initiated and used a product line to develop and deliver mobile browser products. These products let mobile phone or personal digital assistant users access services over wireless telecommunications networks.
TL;DR: The primary design principles on which EROS is built, the impact these principles had on the design, the application structure that naturally emerged from the resulting system, and the how this affected the system's security and testability are described.
Abstract: Design principles are one of the most advocated ideas in software construction, but they are rarely systematically applied. They are particularly critical in secure, reliable systems. EROS, an operating system built from the ground up, provides formally verifiable security, practical reliability, and high performance. This article describes the primary design principles on which EROS is built, the impact these principles had on the design, the application structure that naturally emerged from the resulting system, and the how this affected the system's security and testability.
TL;DR: In an effort to improve software development and acquisition processes and explicitly reuse knowledge from previous software projects, DaimlerChrysler created a software experience center (SEC).
Abstract: In an effort to improve software development and acquisition processes and explicitly reuse knowledge from previous software projects, DaimlerChrysler created a software experience center (SEC). The authors report on challenges the company faced in creating the SEC.
TL;DR: The author encourages requirements analysts to create more valuable and competitive products by inventing requirements rather than expecting customers to ask for them.
Abstract: We often hear the complaint "The customer didn't tell us the project requirements." Here, the author takes the opposite view and encourages requirements analysts to create more valuable and competitive products by inventing requirements rather than expecting customers to ask for them.
TL;DR: Drawing from a large empirical study, the author presents examples of traceability's role in facilitating critical knowledge management processes.
Abstract: Knowledge management involves the collection, assimilation, and use of the explicit and tacit knowledge spread throughout an organization. In software engineering, process knowledge is any explicit or tacit knowledge about the activities, steps, and procedures involved in creating software solutions. As the glue that links fragmented sources of knowledge, traceability helps create, store, retrieve, transfer, and apply process knowledge in software development organizations. Drawing from a large empirical study, the author presents examples of traceability's role in facilitating critical knowledge management processes.
[...]
TL;DR: The authors discuss the benefits of using the Introductory Team Software Process in a computing curriculum and its role in preparing students to work as industrial software engineers.
Abstract: Few computer science programs offer the software engineering training developers need. Team-based courses are essential to this training and can be structured in various ways. The authors discuss the benefits of using the Introductory Team Software Process in a computing curriculum and discuss its role in preparing students to work as industrial software engineers.