Search

For a successful software project, acceptable quality must be achieved within an acceptable cost, demonstrating business value to customers and satisfactorily meeting delivery timeliness. Testing serves as the most widely used approaches to determine that the intended functionalities are performed correctly and achieve the desired level of services; however, it is also a labor-intensive and expensive process during the whole software life cycle. Most current testing processes are often technique-centered, rather than organized to maximize business value. In this article, we extend and elaborate the '4+ 1' theoretical lenses of Value-based Software Engineering (VBSE) framework in the software testing process; propose a multi-objective feature prioritization strategy for testing planning and controlling, which aligns the internal testing process with value objectives coming from customers and markets. Our case study in a real-life business project shows that this method allows reasoning about the software testing process in different dimensions: it helps to manage the testing process effectively and efficiently, provides information for continuous internal software process improvement, and increases customer satisfaction, which makes winners of all success-critical stakeholders (SCSs) in the software testing process. [ABSTRACT FROM AUTHOR]

Negotiating stakeholder WinWin relationships among software quality requirements is a technique that emerged during the 1990's in order to overcome the difficulties arising from contract-oriented specification compliance (popular in the 1970's) and service-oriented customer satisfaction (popular in the 1980's). Obstacles to adoption of negotiated win-win relationships include coordination of multiple stake- holder interests and priorities, reasoning of complicated dependencies, and scalability of an exponentially increasing resolution option space. Conflict identification and resolution techniques are key success factors to overcome the obstacles. This paper describes two exploratory knowledge-based tools (called "QARCC" and "S-COST")* for conflict identification and resolution and how they were used in the digital library projects of a USC Software Engineering class during the 1996/97 school year. A comparative analysis with the artifacts surfaced by stakeholders and the artifacts generated and analyzed by QARCC and S-COST focused on the conflict resolution process, stakeholders' roles and their relationships to quality artifacts, and tool effectiveness. We conclude that the tools helped stakeholders: (1) surface and negotiate conflicts; (2) identify conflicts among functional and quality requirements; and (3) generate, visualize, and negotiate potential resolution options for the conflicts. [ABSTRACT FROM AUTHOR]

In this experiment, seven software teams developed versions of the same small-size (2000-4000 source instruction) application soft- ware product. Four teams used the Specifying approach. Three teams used the Prototyping approach. The main results of the experiment were the following. 1) Prototyping yielded products with roughly equivalent performance, but with about 40 percent less code and 45 percent less effort. 2) The prototyped products rated somewhat lower on functionality and robustness, but higher on ease of use and ease of learning. 3) Specifying produced more coherent designs and software that was easier to integrate. The paper presents the experimental data supporting these and a number of additional conclusions. [ABSTRACT FROM AUTHOR]

This paper summarizes the current state of the art and recent trends in software engineering economics. It provides an overview of economic analysis techniques and their applicability to software engineering and management. It surveys the field of software cost estimation, including the major estimation techniques available, the state of the art in algorithmic cost models, and the outstanding research issues in software cost estimation. [ABSTRACT FROM AUTHOR]

This paper reports the results of an experiment in applying large-scale software engineering procedures to small software projects. Two USC student teams developed a small, interactive application software product to the same specification; one using Fortran and one using Pascal. Several hypotheses were tested, and extensive experimental data collected. The major conclusions were as follows. • Large-project software engineering procedures can be cost-effectively tailored to small projects. • The choice of programming language is not the dominant factor in small application software product development. • Programming is not the dominant activity in small software product development. • The "deadline effect" holds on small software projects, and can be used to help manage software development. • Most of the code in a small application software product is devoted to "housekeeping." The paper presents the experimental data supporting these conclusions, and discusses their context and implications. [ABSTRACT FROM AUTHOR]

For the last 4 years, we have been experimenting with the parallel agile (PA) approach. PA achieves significant schedule compression by leveraging parallelism; large teams of developers can independently and concurrently develop scenarios from initial concept through code. This paper summarizes our experience in defining and evolving PA by applying it to four representative emergent‐technology applications: location‐based advertising, picture sharing, bad driver reporting, and a VR/AR game project. In comparison with the mainstream architected agile process that we had been using on similar systems, the PA process has consistently achieved significant speedups in system development while simultaneously reducing defects. PA uses storyboards and prototypes to define both sunny‐day and rainy‐day scenarios, defines requirements for each use case, and decomposes each use case into a conceptual model‐view‐controller (MVC) pattern. PA also uses code generation from UML models to rapidly construct a domain‐driven microservice architecture at the inception of a project. This microservice architecture is then used to enable prototype code to interact with a live database during requirements definition. PA then uses automatic test case generation from the same UML model. The paper summarizes the overall challenge of software schedule compression, identifies managed parallel development as generally the most powerful but least‐practiced strategy for schedule compression, and summarizes the key elements required to support parallelism. It then summarizes the key techniques for scaling up PA, using a previous million‐line command and control project as an example. We have used MS‐degree graduate student projects to gather productivity data because the university environment has afforded us the opportunity to explore massively parallel development over an extended time period. We are now working with a large company to modernize their main legacy system using the PA methods. The prospective looks good as many of the techniques used (eg, domain models, use case analysis, and MVC decomposition) have been proven to be effective in industry on a wide range of projects for multiple decades. The new techniques (eg, executable domain models, and visual modeling of sprint plans) should also serve to make integration and project management work better on large development efforts. [ABSTRACT FROM AUTHOR]