Search

A study of a large company's software development projects indicates that quality often suffers if team members have worked together previously. Thus, in many cases, temporary teams might be best.

For many years, software engineering researchers and practitioners have tried to determine, define, and redefine the role of software architects. But we still haven't reached a real consensus. The popularity of agile methods such as Scrum and Kanban, with their clear focus on team collaboration, threatens many roles traditionally assigned to individual experts. Some organizations are even challenging the raison d'etre of the software architect role. However, researchers' experiences developing connected-vehicle software revealed two reasons why successful projects still often assign architecture-related responsibilities to individual experts acting as software architects. First, the experts help effectively manage complexity; second, they act as knowledge multipliers when development must scale up.

Software architects are key assets for successful development projects. However, not much research has investigated the challenges they face in large-scale distributed projects. So, researchers investigated how architects at Ericsson were organized, their roles and responsibilities, and the effort they spent guarding and governing a large-scale legacy product developed by teams at multiple locations. Despite recent trends such as microservices and agile development, Ericsson had to follow a more centralized approach to deal with the challenges of scale, distribution, and monolithic architecture of a legacy software product. So, the architectural decisions were centralized to a team of architects. The team extensively used code reviews to not only check the code's state but also reveal defects that could turn into maintainability problems. The study results also suggest that the effort architects spend designing architecture, guarding its integrity and evolvability, and mentoring development teams is directly related to team maturity. In addition, significant investment is needed whenever new teams and locations are onboarded.

In baseball, the practice of sabermetrics uses data to make objective decisions about which players to draft, which players to play, how much to pay players, and which personnel trades between teams make the most sense. Applying such thinking to software projects might help software teams find hidden value and operate more efficiently and effectively.

International software firms face particular software process challenges in terms of competing interests and process variations across organizational units and geographical sites. To address this, Ericsson developers applied a general industrial approach to mass customization that focused on four key tactics: adaptive, cosmetic, transparent, and collaborative mass customization. On the basis of this experience, they discovered the strengths, weaknesses, and best deployment conditions for each tactic, and learned several lessons along the way.

Project retrospectives can be powerful tools for project teams to collectively identify communication gaps and practices to improve for future projects. However, even if project members take the time for a retrospective, it can be hard to correctly remember and jointly discuss past events in a constructive way. Fact-based timelines that visualize a project's events offer a possible solution.

Educating software engineers is a long-standing challenge. This article addresses the issue by examining the overlap between the software engineering educational standards (SE 2004 and GSwE 2009) and one of the most well-known software process improvement models (CMMI-DEV). The resulting data are useful to both industry and academia for improving the software engineering practice. The software industry can take advantage of these results when setting up process improvement goals and training programs, and academia can use the findings to round out software engineering core knowledge in undergraduate and graduate programs.

Software vendors typically release updates and upgrades of their software once or twice a year. Users are then faced with the question of whether the upgrade is worth the price and the trouble. The software industry doesn't provide much evidence that it's worthwhile to upgrade to new releases. The authors propose the use of process mining to prove that upgrading to the next release provides quantifiable benefits to the end user. Process mining capitalizes on the fact that event logs capture information about processes. These events can be used to make processes visible and show the benefits of using a software product's next release. Three groups benefits from this process: end users, software suppliers, and researchers. The authors applied process mining to a medical software product and captured empirical data from 1,400 cases. The data shows that the new version was 11 percent more efficient than the old release.

Software analytics guide practitioners in decision making throughout the software development process. In this context, prediction models help managers efficiently organize their resources and identify problems by analyzing patterns on existing project data in an intelligent and meaningful manner. Over the past decade, the authors have worked with software organizations to build metric repositories and predictive models that address process-, product-, and people-related issues in practice. This article shares their experience over the years, reflecting the expectations and outcomes both from practitioner and researcher viewpoints.

This column is all about stories, and this one is as exciting as a paperback whodunit. The details are all included, and I hate to spoil it, but there's a happy ending. The story is about something old--designing and implementing a new system when the old one was really old (two decades!) and something new--using outside research consultants to save the day with a secret sauce. Enjoy!

Insufficient team collaboration often challenges global software engineering projects. Group awareness can improve teams' trust, relationships, and efficiency. This article surveys the key technologies and tools that support group awareness and collaboration. The insights on technologies derive from discussions and presentations at related conferences, including the IEEE-sponsored International Conference on Global Software Engineering (ICGSE).

For projects that rely on empirical process control and deliver frequently working versions of software, developers and project managers regularly need to examine the status of their software quality. This study illustrates that simple goal-oriented changes or extensions to the existing data of projects' respective defect tracking systems could provide valuable and prompt information to improve their software quality assessment and assurance.

To successfully collaborate in a creative design session, software developers must achieve and maintain a shared focus, encourage and challenge each other, and manage their working relations, even in stressful situations. This article describes six key ways professional software developers do this using examples from a video study of professional developers designing at a whiteboard.

Small to medium-sized software enterprises (SME) increasingly participate in offshoring activities. Detecting market niches and deploying highly flexible software development approaches are seen as key competitive abilities of SME. Therefore, it is of major importance to learn how offshoring affects these capabilities which are closely related to organizational learning. We present case studies from two German companies that engage in offshoring of software development. By comparing the cases with each other, we highlight the different structures the companies chose for their development work and how these structures were enacted in practice. Furthermore, we show how related practices affect strategic and operational aspects of Argyris et al.'s (1985) conception of single- and double-loop learning. Our case studies show that organizational learning is a problem for SME engaged in offshoring and that an inability for double-loop learning can even lead to failures in case of organizational restructuring.

A simple method measuring new effective lines of code showed that between 19 and 40 percent of code written on three projects wasn't in the final release. Generally, productivity is a function of input effort and output size. A strong understanding of software productivity, coupled with a good estimate of software size, is key to predicting project effort and, ultimately, producing reliable project duration estimates, schedules, and resource needs. Project managers and engineers often measure or predict the size of released software-the volume of software in the marketed product. However, the final release doesn't include reworked code-code that was changed or deleted during development.

The basic work unit in innovative software organizations is the team rather than the individual. Such teams consist of "a small number of people with complementary skills who are committed to a common purpose, set of performance goals, and approach for which they hold themselves mutually accountable". Work teams have many advantages, such as increased productivity, innovation, and employee satisfaction. However, their implementation doesn't always result in organizational success. It isn't enough to put individuals together and expect that they'll automatically know how to work effectively as a team. Lack of redundancy and conflict between team and individual autonomy are key issues when transforming from traditional command-and-control management to collaborative self-managing teams.

Errors in software updates can cause regressions failures in stable parts of the system. The Binary Change Tracer collects data on software projects and helps predict regressions in software projects.

Suppose you're a software team manager who's responsible for delivering a software product by a specific date, and your team uses a code integration system (referred to as a build in IBM Rational Jazz and in this article) to integrate its work before delivery. When the build fails, your team needs to spend extra time diagnosing the integration issue and reworking code. As the manager, you suspect that your team failed to communicate about a code dependency, which broke the build. Your team needs to quickly disseminate information about its interdependent work to achieve a successful integration build. How can you understand your team's communication? Social-network analysis can give you insight into the team's communication patterns that might have caused the build's failure.

The amount of software in consumer electronics has grown from thousands to millions of lines of source code over the past decade. Up to a million of these products are manufactured each month for a successful mobile phone or television. Development organizations must meet two challenging requirements at the same time: be predictable to meet market windows and provide nearly fault-free software. Software reliability is the probability of failure-free operation for a specified period of time in a specified environment. The process of finding and removing faults to improve the software reliability can be described by a mathematical relationship called a software reliability growth model (SRGM). Our goal is to assess the practical application of SRGMs during integration and test and compare them with other estimation methods. We empirically validated SRGMs' usability in a software development environment. During final test phases for three embedded software projects, software reliability growth models predicted remaining faults in the software, supporting management's decisions.

Software projects in small-and medium-sized enterprises (SMEs) produce similar work products when building interactive software systems. For each project, software engineers create requirements, design specifications, source code, data schemes, and so forth, gain experience with these work products, and create associated products such as test cases for the source code or inspection plans for the requirements. All of this constitutes knowledge that the engineers can reuse in new variants of the software system.

In this article, the author describes the efforts since 1993 to improve software process and achieve a predictable software development cycle. This process improvement went through three stages involving 16 projects

One major reason software development projects fail is that the development process is invisible. Managers tend to rely on meetings and reports to understand project status and make decisions, leading to mismanagement due to inaccurate or incomplete information. Software projects typically collect information during development using different tools and store it in repositories. We present a statistical process control (SPC) method of defining, collecting, and analyzing software metrics from software repositories for MDD process control and improvement (PCI). This method, which we call mining software repositories (MSR), can help us change the traditional, static, record-keeping use of software data repositories to a new, active use for predicting and planning various aspects of MDD projects

Good software cost models can significantly help software project managers. With good models, project stakeholders can make informed decisions about how to manage resources, how to control and plan the project, or how to deliver the project on time, on schedule, and on budget. Real-world data sets, such as those coming from software engineering projects, often contain noisy, irrelevant, or redundant variables. We propose that cost modelers should perform data-pruning experiments after data collection and before model building. Such pruning experiments are simple and fast.

The Capability Maturity Model for software has become a major force in software development process improvement. We looked at the role of process improvement in the context of a small organization. Although the Capability Maturity Model integration is replacing the CMM, we focused on the older CMM. We had to look at more than which CMM key process areas apply to small businesses. Our overall goal was to institute good software development practices, we used the language of the CMM to gain the management's cooperation. Applying these practices is essential to managing growth, yet undertaking this effort without prior experience could impede a small company's innovative nature. This case study's purpose was to investigate the success factors of a software process improvement effort for a small software development organization.

The perception that software projects have unusually high failure rates has fueled the debate on software process. In the 1990s, the Standish Group estimated that the total economic toll of cancelled or overrun software projects could reach several tens of billions of dollars in terms of wasted effort and opportunity costs. Worse yet, even when delivered on time and on budget, software rarely has any significant salvage value when it fails to meet user needs. This article argues for an economic basis for rationalizing process selection decisions. It demonstrates how, under conditions of uncertainty, learning and flexibility affect such decisions. Uncertainty is a critical driver in process selection because it's ubiquitous in software development and it determines the degree of flexibility and learning needed to maximize economic value.

Conventional wisdom in the software engineering research community says that metrics can make project management more effective. Software metrics range from internal product attributes such as size, complexity, and modularity to external process attributes such as effort, productivity, and reliability. Software project telemetry facilitates local, in-process decision making.

At Landmark Graphics, we have worked with various software practices and processes and over the last several years have begun to better comprehend some of the guidelines that define "barely sufficient" for our software projects. One thing has become quite apparent: what's barely sufficient for one project can be insufficient for another yet overly bureaucratic for another. As we looked at our project history, we found that two primary attributes influenced the type of process we used: complexity and uncertainty. To better quantify these attributes, we devised a scoring model and plotted each project's results on a four-quadrant graph. We have developed an approach to help determine what process practices are "barely sufficient" for any given project. We start with a core set of common practices. Then, depending on complexity and uncertainty, we can recommend additional practices. By identifying these project drivers, we can provide earlier guidance to project teams so that they can start with a process that's close to appropriate.

The popular and well-tested software process frameworks such as the Software Engineering Institute's Capability Maturity Model and ISO 9001, details key process areas for software development. Focusing more on continuous improvement in code development processes, generic-process frameworks such as the CMM lack key process areas (KPA) that address capabilities for managing distributed software projects, such as establishing mutual knowledge and managing geographically dispersed social networks. We identify 24 new KPAs that address the wide-ranging capabilities needed for managing distributed software development and arrange them in an evolutionary order similar to the CMM framework. The evolutionary or phased approach in improving software management capabilities helps firms systematically assess their situations and plan for improvements. We also report the results of a statistically tested maturity assessment survey and test the overall rigor of our model against industry expert opinion and objective data collected from real-world projects implemented at SAP AG, a leading global-enterprise software firm.

Project management is an important part of software development, both for organizations that rely on third-party software development and for those whose software is developed primarily in-house. Moreover, quantitative survey-based research regarding software development's early, nontechnical aspects is lacking. To help provide a project management perspective for managers responsible for in-house software development, we conducted a survey in an attempt to determine the factors that lead to successful projects. We chose a survey because of its simplicity and because we hoped to find relationships among variables. Also, a survey let us cover more projects at a lower cost than would an equivalent number of interviews or a series of case studies. Our results provide general guidance for business and project managers to help ensure that their projects succeed.

The real problem small organizations face is managing the relationship between their environment and how this environment enables or inhibits an improvement initiative's success. Little is understood about which factors affect a software process improvement initiative in a small organization and how the organization's environment determines these factors. To help small organizations make decisions about adopting better process practices, we analyzed the relationship between a small organization's environment and its successful implementation of the Capability Maturity Model for Software (SW-CMM) level 2. The project helped us identify the organizational characteristics affecting the initiative. As we'll see, some aspects of process improvement are easier when the organization is small.

Open source projects have resulted in numerous high-quality, widely used products. Understanding the defect-handling strategies such projects employ can help us use the publicly accessible defect data from these projects to provide valuable quality-improvement feedback and to better understand the defect characteristics for a wider variety of software products. We conducted a survey to understand defect handling in selected open source projects and compared the particular approaches taken in different projects. We focused on defect handling instead of the broader quality assurance activities other researchers have previously reported. Our results provided quantitative evidence about the current practice of defect handling in an important subset of open source projects.

Task allocation during the construction stage of software engineering is complex and challenging. First, engineers must chart a path between the often conflicting objectives of time and quality. Second, a huge productivity variance exists across the spectrum of practicing software developers. Properly handling this variance amid those time and quality pressures is a tricky management problem. Multiobjective optimization might provide the answer. This emerging research area generates optimal solutions for projects with many objectives. An experienced decision-maker analyzes these solutions and selects the best one. Here, we describe such an approach and demonstrate it with a problem involving the allocation of software construction tasks among a team of software developers with varying degrees of skill.

Software process improvement has been on the agenda of both academics and practitioners, with the Capability Maturity Model as its de facto method. Many companies have invested large sums of money in improving their software processes, and several research papers document SPI's effectiveness. SPI aims to create more effective and efficient software development and maintenance by structuring and optimizing processes. SPI assumes that a well-managed organization with a defined engineering process is more likely to produce products that consistently meet the purchaser's requirements within schedule and budget than a poorly managed organization with no such engineering process. We discuss about the measuring the ROI in software process improvement.

Software development projects don't get funded unless they return clearly defined value to the business. Demands for shorter investment periods, faster time-to-market, and increased agility require new, radical software development approaches. These approaches must draw on the expertise of both software architects and financial stakeholders and open the traditional black box of software development to rigorous financial analysis. We can accomplish this only by positioning software development as a value-creation activity in which business analysis is integral. The incremental funding method is a financially informed approach to software development. IFM maximizes returns by delivering functionality in "chunks" of customer-valued features, carefully sequenced to optimize the project's net present value (NPV). We derived the IFM concepts from several years' experience in winning competitive contracts for large-systems integration and application development projects.

Research on over 18 years of software projects reveals that developing large systems involves substantially more activities and a greater variety of specialized personnel than developing smaller systems. Perhaps the most significant observation is that good quality control is the best overall indicator of a successful project. Schedule delays and cost overruns most often occur when you discover during testing that the application has so many bugs that it doesn't work. Projects using QA teams, formal design and code inspections, and pretest defect tracking always had shorter testing cycles and therefore were more likely to be deliverable on schedule.

The authors report detailed data and analyses on productivity and quality from 29 Hewlett-Packard projects. While some software development models' characteristics affect performance negatively when considered alone, their impact disappears when considered in combination with other attributes. So, processes should be thought of as coherent systems of activities rather than as a series of individual practices that can be implemented piecemeal.

Software process comprises activities such as estimation, planning, requirements analysis, design, coding, reviews, and testing, undertaken when creating a software product. Effective software process management involves proactively managing each of these activities. Statistical process control tools enable proactive software process management. One such tool, the control chart, can be used for managing, controlling, and improving the code review process.

US companies increasingly began outsourcing software development work to countries such as India, which touts low personnel costs and plentiful technical expertise, during the dotcom shakeout. Today, the trend shows no sign of stopping. It has changed the landscape for US software professionals, reshaping how companies plan projects and choose employees. US software developers will not be going the way of the dinosaurs, analysts say, but they will need to cleverly manage their careers and thoroughly understand the new environment. At the same time, businesses are learning more about offshore outsourcing's challenges. The author discusses the growing debate about its merits.

Solving the problem of failed project ownership is not merely a process of assigning developers to subsystems. This article describes four code ownership models, ranging from one individual owning an entire system to the collective ownership that is a core extreme programming practice. No single code ownership model is best. In fact, many projects would benefit from dynamically adjusting the ownership model over time as development progresses through, for example, the four phases of the unified process.

To succeed, a software quality improvement (SQI) initiative must reflect organizational culture and the values that compose it. A study to define these values in software organizations includes proposals for implementing them.

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.

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.

Lockheed Martin's C-130J Avionics/Software Integrated Product Team (IPT) creates software that runs a wide variety of systems on the C-130J aircraft. This team develops embedded safety-critical real-time air vehicle software and a ground-based data analysis system for aircraft analysis. The IPT operates within the infrastructure of the C-130J Software Factory, which consists of Sun workstations and PCs networked to Web servers, a configuration management server, an aircraft simulator implemented in software, and laboratories are composed of the aircraft's hardware mounted in equipment racks for easy access. The article discusses the IPT's diverse education and training needs, focusing on how to address shortfalls in conventional computer science and engineering education that result in mismatched expectations between the new hire and the company.

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.

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.

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.

Requirements engineering might be the single most important part of any software project. Based on their field study of 15 RE teams in nine software organizations, the authors identify the RE practices that clearly contribute to project success, particularly in terms of team knowledge, resource allocation, and process. They then summarize the best practices exhibited by the most successful teams.

The International Software Benchmarking Standards Group maintains a repository of data from numerous organizations' completed software projects. The ISBSG Data Repository has many uses, including project benchmarking, best-practice networking, and summary analyses. The repository, open to the public, has provided research data on several topics, including function points structure, project duration, and cost estimation.

Recently, the Software Productivity Consortium conducted a benchmarking study of process asset libraries. The report provided a significant set of ideas for organizations seeking to create new PALs or improve existing ones. Even the participants with the most "best practices" found gems among other participants' best practices for use in their continuous improvement efforts. The article discusses why we chose a benchmarking approach, the process we used in conducting this study, and key lessons we learned for future studies.