Barry Boehm
Barry W. Boehm (May 16, 1935 – August 20, 2022) was an American software engineer, TRW Emeritus Professor of Software Engineering at the Computer Science Department of the University of Southern California, and known for his many contributions to software engineering.
Quotes
[edit]- Poor management can increase software costs more rapidly than any other factor. Particularly on large projects, each of the following mismanagement actions has often been responsible for doubling software development costs.
- Barry Boehm (1981) as cited in: Tyson Gill (2002) Planning Smarter: Creating Blueprint-Quality Software Specifications. p. 14
- Software Engineering Economics is an invaluable guide to determining software costs, applying the fundamental concepts of microeconomics to software engineering, and utilizing economic analysis in software engineering decision making.
- Barry W. Boehm (1981) Software engineering economics. Abstract.
- If a project has not achieved a system architecture, including its rationale, the project should not proceed to full-scale system development. Specifying the architecture as a deliverable enables its use throughout the development and maintenance process.
- Barry Boehm (1995); quoted in: L. Bass, P. Clements, and R. Kazman (1998) Software Architecture in Practice, Addison Wesley Longman. Chapter 2
- What we see in both software development and military operations is a tendency for the pendulum to swing back and forth between extremes. Yet in most cases, we need a balance between armor and discipline and between mobility and agility. Actually, though, I would say that the leaders in both the agile and plan-driven camps occupy various places in the responsible middle. It’s only the over-enthusiastic followers who overinterpret “discipline” and “agility” to unhealthy degrees.
- Tom DeMarco and Barry Boehm. "The agile methods fray." Computer 35.6 (2002): 90-92.
- Agile development methodologies promise higher customer satisfaction, lower defect rates, faster development times and a solution to rapidly changing requirements. Plan-driven approaches promise predictability, stability, and high assurance. However, both approaches have shortcomings that, if left unaddressed, can lead to project failure. The challenge is to balance the two approaches to take advantage of their strengths and compensate for their weaknesses.
- Barry Boehm and Richard Turner. "Observations on balancing discipline and agility." Agile Development Conference, 2003. ADC 2003. Proceedings of the. IEEE, 2003.
Software engineering economics. (1984)
[edit]Boehm, Barry W. "Software engineering economics." Software Engineering, IEEE Transactions on 1 (1984): 4-21.
- The dictionary defines "economics" as "a social science concerned chiefly with description and analysis of the production, distribution, and consumption of goods and services." Here is another definition of economics which I think is more helpful in explaining how economics relates to software engineering.
- Economics is the study of how people make decisions in resource-limited situations.
- This definition of economics fits the major branches of classical economics very well.
- Macroeconomics is the study of how people make decisions in resource-limited situations on a national or global scale. It deals with the effects of decisions that national leaders make on such issues as tax rates, interest rates, foreign and trade policy.
- Microeconomics is the study of how people make decisions in resource-limited situations on a more personal scale. It deals with the decisions that individuals and organizations make on such issues such as how much insurance to buy, which word processor to buy, or what prices to charge for their products or services.
- p. 4
- If we look at the discipline of software engineering, we see that the microeconomics branch of economics deals more with the types of decisions we need to make as software engineers or managers.
- p. 4
- Throughout the software life cycle, there are many decision situations involving limited resources in which software engineering economics techniques provide useful assistance.
- p. 4
- Economic principles underlie the overall structure of the software lifecycle, and its primary refinements of prototyping, incremental development, and advancemanship. The primary economic driver of the life-cycle structure is the significantly increasing cost of making a software change or fixing a software problem, as a function of the phase in which the change or fix is made.
- p. 4
A spiral model of software development and enhancement. (1988)
[edit]Boehm, Barry W. "A spiral model of software development and enhancement." Computer 21.5 (1988): 61-72.
- “Stop the life cycle-I want to get off!”
- “Life-cycle Concept Considered Harmful.”
- “The waterfall model is dead.”
- “No, it isn’t, but it should be.”
- These statements exemplify the current debate about software life-cycle process models. The topic has recently received a great deal of attention.
- p. 61
- The spiral model presented in this article is one candidate for improving the software process model situation. The major distinguishing feature of the spiral model is that it creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process. It incorporates many of the strengths of other models and resolves many of their difficulties.
- p. 61
- The Code-and-Fix Model. The basic model used in the earliest days of software development contained two steps:
- 1. Write some code.
- 2. Fix the problems in the code.
- Thus, the order of the steps was to do some coding first and to think about the requirements, design, test, and maintenance later. This model has three primary difficulties: (a) After a number of fixes, the code became so poorly structured that subsequent fixes were very expensive. This underscored the need for a design phase prior to coding. (b) Frequently, even well designed software was such a poor match to users' needs that it was either rejected outright or expensively redevelopment...
- p. 61-62
- The stagewise and waterfall models. As early as 1956, experience on large software systems such as the Semi-Automated Ground Environment (SAGE) had led to the recognition of these problems and to the development of a stagewise model to address them.
- p. 63
Software risk management: principles and practices (1991)
[edit]Boehm, Barry W. "Software risk management: principles and practices." Software, IEEE 8.1 (1991): 32-41.
- Like many fields in their early stages, the software field has had its share of project disasters: the software equivalents of Beauvais Cathedral, the S.S. Titanic, and the "Galloping Gertie" Tacoma Narrows Bridge. The frequency of these disaster projects is a serious concern: a recent survey of 600 firms indicated that 35% of them had at least one "runaway' software project.
- p. 32
- Most post-mortems of these software disaster projects have indicated that their problems would have been avoided or strongly reduced if there had been an explicit early concern with identifying and resolving their high-risk elements. Frequently, these projects were swept along by a tide of optimistic enthusiasm during their early phases, which caused them to miss some clear signals of high risk issues which proved to be the project's downfall later.
Enthusiasm for new software capabilities is a good thing. But it needs to be tempered with a concern for early identification and resolution of a project's high-risk elements, so that people can get these resolved early and then focus their enthusiasm and energy on the positive aspects of their software product.- p. 32
Software Cost Estimation with Cocomo II with Cdrom (2000)
[edit]Boehm, Barry W., Ray Madachy, and Bert Steece. Software Cost Estimation with Cocomo II with Cdrom. Prentice Hall PTR, 2000.
- Success in all types of organization depends increasingly on the development of customized software solutions, yet more than half of software projects now in the works will exceed both their schedules and their budgets by more than 50%.
- Abstract.
