future challenges for se

7/28/2019 Future Challenges for SE

1/10


2/10

In such cases, using a sequential,requirements-specification-firstwaterfall model w illgenerally be a recipe for a nonr espo nsive system and a great deal of expens ive rework. It willbe better to accept that y our project will start at the left of a Con e of Uncertainty, as show n inFigure 2. This figure was derive d from several years of experience in preparing costestimates at vario us stages of system definition at TR W [Boehm , 19811. It was dubbed the

Cone o f Uncertainty by S teve McConnell in [McConnell , 19981.4x I

RelativeSize

Range

CompletedPrograms\t

SA FE SD

Proposals

.size (SLOC)+ Cost ($ )

Product DetailConcept of Rqts Design Design AcceptedOperation Spec. Spec. Spec. Software

A A A A A A

Feasibility Plans Product Detail De veland Design Design andRq ts Tes t

Phases and Milestones

Figure 2. The Cone o f Uncertainty in Software Cost and Size Estimation

The best w ay to narrow a Con e of Uncertainty is to buy inform ation to avoid risk.This involves identifying candidate investments in reducing uncertainty such as prototyping,simulating, modeling, benchmarking, reference checking,COTS evalu ation, or market trendanalysis; analyzing their relative costs and benefits, and choosing the m ost cost-effectiveways to reduce your uncertainty an d risk.

How ever, it will also be im portant to organize future projects w ith en ough agility tobe able to adapt to the a dditional emergen ce of new sources of unpr edicta ble change. As 1'11discuss further below , this involve s building agility and adaptability into your projects'staffing, organization, product architectures, and process architectures.

2. Rapid Change.

Go ne are the days when peop le could spend their entire careers do ing the same thingin the sam e ways. A strong case can be m ade that the most significant challenges facing2 1''century organizations will be their ability to adapt to rapid and unp redictable change in m orerapid and appropriate ways than their comp etitors. Evidence of this accelerated pace ofchange can be see n such books as T he World is Flat [Friedman, 20051, showin g theaccelerated pace of chang ein cons um er preferences, international comp etition , and businesspractices.


3/10


4/10

Users

Many features

Changeable requirements

Applicationscompatibility

Hlgh levels of sewice

Voice in acqulsltion

Flexlble contract

Early availability

Maintainers

Ease of transition

Ease of maintenan ce

Applications compatibility

Voke In acquisition

PC: ProcessPD: ProductPP: PropertyS: Success

M rslon caNeffectlven ea

Limited dwelopm ent budget. ahedule

Government standards compllance

Polltical correctnesst

Dwelopmentvlslbility and control

Rigorous contact

Developers

Flexible cmtrac t

Ease of me etlng budget an d schedule

Stable requirements

Freedom of choke: process'

i

Lk&reedom of choke: team

iFreedom of chdce: COTYrwr o .I

- The gray lines show model clashes from the MasterNet system.

Figure 3. Key Stakeholder Value Propositions and Their Potential Conflicts

The acquirers will have limited resources, and their success will depend on having abusiness case for each feature; and having a completely stabilized set of requirements. Thedevelopers' success will depend on minimizing the risk of overrunning the budget andschedule, which will imply having the ability to make infrastructure decisions and to reuse

previously-developed software. The maintainers' success will depend on how well thesystem and its software are designed and structured for ease o f maintenance, and howcompatible they are with the other artifacts being maintained.

The gray lines in Figure 3 show actual conflicts among stakeholder dependabilityvalue propositions that were not resolved in one of the classic failed software projects, theBank of America Master Net system, as discussed in [Boehm et al., 20001. The black lineswere additional conflicts we found in analyzing other failed projects. The S, PD, PC, and PPannotations on the lines indicate whether a line primarily reflected conflicts among theproject's success models, product models, process models, or property models. Oneimplication of the diversity of model clashes on failed projects is that current "model-drivendevelopment" initiatives need to consider more than just product models. A recent empiricalstudy on model clashes by one of our Ph.D, graduates found that product-product modelclashes were only about 30% of the total number of model clashes found [Al-Said, 20031.

The fact that there are so many potential conflicts among even the four main success-critical stakeholders means that there are many potential win-lose situations that a project canget into. A win-lose situation usually turns into a lose-lose situation, as happened with thecancellation of the MasterNet project when the Acquirers found that their budget was beingoverrun, the Users were unhappy with the system's performance, and the Maintainers were


5/10


6/10


7/10

5. Interde~endence: No Man, Artifact. or Svstem Is an Island

In the large-scale software-intensive systems of systems (SISOS) discussed above, thecomponent systems no longer have the luxury of operating autonomously. They act oninformation from other SISOS elements and supply information for them. Where before they

may not have been concerned with such issues as interoperability and network security, nowthey are necessary considerations. Each component system is no longer an island, entire ofitself, and the SISOS is not an island either. Many of them must interoperate with over 100separately evolving systems, with which they need to stay synchronized.

But beyond this, it is important to recognize that applies not only to the SISOS and itselements, but also to the processes, methods, and tools used to define, design, develop,deploy, and evolve it. No set of requirements, designs, or plans is an island. Nor cansoftware engineering, hardware engineering, or human factors engineering be considered asislands. They all need to be engineered concurrently. And this concurrency needs to beincrementally synchronized and stabilized to avoid divergence, chaos, or analysis paralysis.Figure 5 provides one vision for how to do this, based on a recent National Research Councilstudy on human-system integration [Pew and Mavor, 20071.

General/DoD Milestones

Activity cateqory

System

Figure 5. Representative Levels of Effort by Phase


8/10

The recent Software Engineering Institute report on Ultra-Large-Scale Systems [SEI,20061 makes a good case that such SISOS are best considered as ecosystems, which containinternal ecologies among their component systems, and which participate in externalecologies within which they need to stay viable. The report includes numerous goodrecommendations for improving SISOS acquisition, requirements engineering, design,multidimensional and dynamic quality assurance, and evolution.

A hr th er important point in defining this kind of ecosystem is that considerably moreeffort is needed up front to avoid getting its concurrently-engineered requirements, designs,and plans pointed toward avoiding an ecological crisis. Increasing interdependence and therapid pace of change mean thinking about not just the first derivative but also the second andmaybethird derivatives. The best book I've read recently is "The Logic of Failure" [Dorner, 19961.It shows through a wealth of examples and ecology simulation games that people with theirbuilt-in fight-or-flight survival skills have a horrible track record in managing ecologies, butthat they can get better at managing ecologies with practice and with better tools forunderstanding side effects.

The need for more up-front investment is corroborated by the analysis summarized inFigure 6, [Boehm-Turner, 20041. It shows that the "sweet spot" for "how much up-frontarchitecting and risk resolution effort is enough" increases as the size of the SISOS increases.This effort is not just in writing specifications and plans, but more importantly in exercisingmodels, simulations, prototypes, and partial SISOS implementations before committing to goforward into SISOS development.

I Percent of Time A dded for Architecture and Risk Resolubon

Figure 6. Large SISOS Need More Time for Architecture and Risk Resolution


9/10

6. Conclusions.

In the 2 1 century and beyond, software will provide the sensing, communications,and decision support capabilities that enable people to become aware, to understand, and to

collaborate in addressing the problems and opportunities they will have from local andpersonal levels to global levels. At each level, software capabilities will strongly determinehow well people will be able to understand each other and come together to find ways tomake their local and global situations more mutually satisfactory and sustainable into thefuture.

If this software and the collaboration it supports ~ are done well, the~ wor ld ould have aGolden Age-going we 1 beyond the-dreams of the Athenian and Renaissance philosophers. Ifit is done poorly, it will exacerbate tensions and mistrust, obfuscate mutual understanding,and cut off many of the options for joint gain that enable people to negotiate mutuallysatisfactory and sustainable agreements.

This is not to say that software is a silver bullet for resolving social problems. Someof the limits to software perfectability are imposed by limits to social perfectability. Anexample is provided by Conway's Law, which states that the structure of a software productreflects the structure of its sponsoring and development organizations. The converse ofConway's Law then states that we will be able to create perfect software as soon as we learnhow to create perfect organizations - which seems unlikely to happen soon [Boehm, 20071.

But it is to say that making incremental improvements in developing better softwarewill have significant leverage in incrementally making the world a better place. And it is tosay that being a software engineer in the 21S' century will be one of the most challenging andrewarding careers available to people. The challenges we have discussed above ofsimultaneously dealing with uncertainty and emergence, rapid change, dependability,diversity, and interdependence will often be-formidable, but ~ i l l ~ a ~ s o e opportunities tomake siglllficant ~ on tf ib ut i~ ns hat will make a difference for the better.


10/10

References

A1 Said, M., Identifying, Analyzing. and Avoiding Software Model Clashes, USC Ph.D.Dissertation, 2003.

Boehm, B., "Being a Software Engineer in the Software Century," in R. Selby (ed.), Software

Engineering: Barry W. Boehrn's Lifetime Contributions to Software Development,Management, and Research, Wiley 2007, pp . 797 - 806.Boehm, B., Software Engineering Economics, Prentice Hall, 198 1

Boehm, B., Port, D., and A1 Said, M ., "Avoiding the Model Clash Spiderweb," Computer,Nov. 2000, pp. 120 - 122.

Boehm, B., Turner, R., Balancing Agility and Discipline, Addison Wesley, 2004.Domer, D. The Logic of Failure. Basic Books, 1996Friedman, T. , The World Is Fl at , Farrar, Straus, and Giroux, 2005.Hall, E.T., Beyond Culture. New York: Anchor BooksIDoubleday, 1976Highsmith, J. , Agile Software Development Ecos~stems, ddison Wesley, 2002.Hofstede, G., Culture an d Organizations, McGraw Hill, 1997.McConnell, S ., Software Project Suwival Guide, Microsoft Press, 1 998.

Pew, R., and Mavor, A., Human-System Integration in the System Development Process: ANew Look, National Academies Press, 2007.

Software Engineering Institute, Ultra-Large-Scale Systems, CMUISEI, Pittsburgh, PA, 2006.

future challenges for se

Documents