The Changing Nature of Software Development

The Changing Nature of Software Development There are now many ways to develop and sell software products. This means that the scope of the estimation problem is much larger now than it was in the early days of software development. In the 1960s, all software was custom built. Projects had dedicated staff. Companies were usually paid on a level of effort basis (cost plus, or time and materials). Today, there are many ways to build software (custom coding, integration of pre-built components, generation of code using tools, etc.). The project environment is more varied as well. Large, complex software products need a wider range of skills. Organizational structures are flatter and more fluid. Workers are often dispersed and may be hired only for short periods of time when particular skills are needed. The business environment has also become more complex. There are new ways of selling software and data, increased liabilities for defective products, and new accounting practices. The following paragraphs briefly describe these areas. Each area presents challenges to software estimators. The technology used to build systems will continue to evolve rapidly. This technology includes hardware platforms, operating systems, data formats, transmission protocols, programming languages, methods, tools, and commercial off-theshelf (COTS) components. The half-life of software engineering knowledge is typically less than three years. Project teams will use new development processes such as rapid application development (RAD) and COTS integration to grow software systems. These processes will continue to evolve rapidly as we learn. (Unless an organization is at Software Engineering Institute Capability Maturity Model® Level 5, it may not be able to evaluate and inject new technology at the rate needed to keep up.) Such constant and rapid changes mean that little relevant historical data will be available to help estimate future software projects and to develop new cost estimation models. This may challenge CMM® criteria relating to estimating, planning, and tracking that require the use of historical data and assume a stable process. Technology and processes alone do not determine how businesses will develop software, license products, etc. There is an interaction with the legal and business domains. For example, Paul Strassman discusses possible ways of acquiring software as summarized in Table 1. Strassman observes that outsourcing or renting software (data processing) capability frees an organization from the details of business support functions, and allows it to focus on business objectives and growth. For additional information, see www.strassman.com Scott McNealy of Sun Microsystems proposes putting everyday applications on the Internet for all to use for free [1]. Such external influences will affect how software is built and sold. Future software estimators will have to estimate the costs of tradeoffs between development, operating, and maintenance costs. This will require more knowledge of financial practices such as return on investment, discounted value, etc. Barry Boehm covers such topics in Part III of his classic book [2]. Another factor that estimators must confront is the people who will produce the software. Projects need experts in multiple application and solution domains in order to build the large, complex systems. They may also have to receive guidance from experts in the legal, regulatory, and business domains. No single person can understand all of these domains, nor can one individual keep up with them all. This means that development teams will be more interdisciplinary. Because all of these experts are not needed continuously, project teams (and possibly entire companies) may consist of a core of permanent experts and groups of temporary workers hired just in time. The permanent staff would include managers, project control, chief engineers, etc. The temporary workers would include analysts, designers, engineers, testers, support staff, and various domain experts. It will be challenging to assemble and manage such diverse, dynamic teams. Advances in telecommunications, networking, and support software (groupware) can help such teams function even though they are geographically and temporally dispersed. Such organizational structures affect estimators because they impact parameters such as the average staff capability, experience, and turnover. There will also be a growing need for estimates of quality (defects), reliability, and availability, as well as the usual cost and schedule estimates. Developers and customers will become more interested in ensuring the safety and reliability of complex software systems such as those used for financial and medical applications. Estimating such characteristics is especially challenging for systems built using COTS components.