Skip to main content

Currently Skimming:

2 Summary of Workshop Discussions
Pages 4-39

The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.


From page 4...
... • What kinds of management and measurement approaches could guide program managers and developers? Synergies Across Software Technologies and Business Practices Enable Successful Large-Scale Systems Context matters in trying to determine the characteristics of successful approaches -- different customer relationships, goals and needs, pacing of projects, and degree of precedent all require different practices.
From page 5...
... • Different systems and software engineering organizations have different goals and needs. Product purposes vary -- user empowerment, business operations, and mission capabilities.
From page 6...
... • Gaining advantages from lack of fault proneness in reused components by achieving high levels of code, design, and requirement reuse. One example of code reuse was this: Across 25 NASA ground systems, 32 percent of software components were either reused or modified from previous systems (for spacecraft, reuse was said to be as high as 80 percent)
From page 7...
... This is an example of true design reuse rather than code reuse. In addition to these synergies, it was suggested that other types of analyses could also contribute to successful projects.
From page 8...
... . • Aligning big V waterfall-like systems engineering life-cycle models with incremental/spiral software engineering life-cycle models.
From page 9...
... • Defining research and technology roadmaps for systems and software engineering. • Collaborating with foreign software developers.
From page 10...
... From a strategic perspective, a very large-scale system is an environment where operational systems have the ability to share information among geographically distributed systems with appropriate security and to act on the shared information to achieve their desired business goals and objectives. From an operational perspective, a very large-scale system is an environment where each operational subsystem performs its own functions autonomously, consistent with the overall strategy of the very large-scale system.
From page 11...
... and would evolve into a dynamic concept of operation by assembling separate building blocks to meet operational goals. The system manager should ask: What problem will the system solve?
From page 12...
... ? DoD Software Engineering and System Assurance An overview of various activities relating to DoD software engineering was given.
From page 13...
... It will focus on supporting acquisition; improving the state of the practice of software engineering; providing leadership, outreach, and advocacy for the systems engineering communities; and fostering resources that can meet DoD goals. These are elements of DoD's strategy for software, which aims to promote world-class leadership for DoD software engineering.
From page 14...
... • Creation of opportunities and partnerships through an established network of government software points of contact; chartering the NDIA Software Committee; information exchanges with government, academia, and industry, and planning a systems and software technology conference. Top issues emerging from the NDIA Defense Software Strategy Summit in October 2006 included establishment and management of software requirements, the lack of a software voice in key system decisions, inadequate life-cycle planning and management, the high cost and ineffectiveness of traditional software verification methods, the dearth of software management expertise, inadequate technology and methods for assurance, and the need for better techniques for COTS assessment and integration.
From page 15...
... ; examples of forthcoming technologies would be teams of autonomous robots or teams of small, fast surface ships. Characteristics of these systems exemplify the challenges of uncertainty and scale; they include • Large scale -- tens of thousands of functional and performance requirements, 10 million lines of code, and 100 to 1,000 software configuration items; • Simultaneous conflicting performance requirements -- real-time processing, bounded failure recovery, security; • Implementation diversity -- programming languages, operating systems, middleware, complex deployment architectures, 20-40 year system life cycles, stringent certification standards; and • Complex deployment architectures -- systems of systems; mixed wired, wireless and satellite networks; multi-tiered servers; personal digital assistants (PDAs)
From page 16...
... See also: Government Accountability Office (GAO) , 2005, "Tactical aircraft: F/A-22 and JSF acquisition plans and implications for tactical aircraft modernization," Statement of Michael Sullivan, Director, Acquisition and Sourcing Management Issues, Testimony Before the Subcommittee on AirLand, Committee on Armed Services, U.S.
From page 17...
... Brooks, 1995, The Mythical Man-Month: Essays in Software Engineering, A ­ ddison-Wesley Professional, New York.
From page 18...
... New systems have more resource sharing, which leads to hidden dependencies. There is limited design time support to understand or reduce interactive complexity.
From page 19...
... SESSION 3: AGILITY at Scale Panelists: Kent Beck and Cynthia Andres, Three Rivers Institute Moderator: Douglas Schmidt This session addressed the application and applicability of extreme programming's "agile techniques" to very large, complex systems from
From page 20...
... Values and Sponsorship Participants noted that extreme programming (XP) -- an agile software development methodology -- was one of the first methodologies to be explicit about the value system behind its approach and about what is fundamental to this perspective on software development.11 Different development approaches have their own underlying values.
From page 21...
... The perception or image of the work can be crucial to attracting new hires, who may know that the organization's work involves a lot of processes, requires great care, and takes a long time, but not necessarily that it is also interesting and creative work. Trust, Communication, and Risk Speakers argued that much of the effort in extreme programming comes down to finding better ways of building trust.
From page 22...
... • Testing sooner.  The longer a bug lives, the more expensive it becomes. One way of addressing that situation and improving the overall effectiveness of development is finding ways to validate software sooner, such as by developer testing.
From page 23...
... The presentations began by describing the goals and activities of two federal programs in software assurance and went on to explore present and future approaches. Software Assurance Considerations and the DHS Software Assurance Program The U.S.
From page 24...
... Participants noted the need for more comprehensive diagnostic capabilities and standards on which to base assurance claims. Two suggestions were made: • The software assurance tool industry has not been keeping pace with changes in software systems -- tools that provide point solutions are available, but much of the software industry cannot apply them.
From page 25...
... industry.15 In addition to the gaps and shortcomings identified at that software summit, a recent PITAC report on national priorities for cybersecurity listed security software engineering and software assurance as among the top ten goals.16 Software assurance contributes to trustworthy software systems. The goals of the DHS Software Assurance (SwA)
From page 26...
... This is particularly challenging in areas such as software assurance, where there is rapid evolution of technologies, practices, and related standards. In the future, the goal is for customers to have expectations for product assurance -- including information about evaluated products, suppliers' process capabilities, and secure configurations of software -- and for suppliers to be able to distinguish themselves by delivering quality products with the requisite integrity and to be able to make assurance claims based on relevant standards.
From page 27...
... Unfortunately, it was argued, assurance is gained today the same way as it was 30 years ago. Various mechanisms for gaining confidence in general-purpose software are also being used for DoD software: functional testing, penetration testing, design and implementation analysis, advanced development environments, trusted developers, process, discipline, and so forth are mechanisms to build confidence.
From page 28...
... Participants mentioned a variety of ideas being pursued in industry and academia in response to business and government needs in the area of software assurance: anomaly identification, model checking, repeatable methodology for assurance analysis and evaluation, and intermediate representation of executable code.19 Suggested research areas mentioned during this discussion include these: • Assurance composition, • Verifiable compilation, • Software annotation, • Model checking, • Safe languages and automated migration from unsafe languages, • Software understanding, and • Measurable attributes that have strong correlation to assurance. More broadly, participants suggested that it will be important to understand how to build confidence from all of these (and other approaches)
From page 29...
... Discussion identified some necessary changes in the long run: • University curricula.  It was argued that university programs should do a better job of teaching secure coding practices and training future developers to pay attention to security as part of software development. If the mindset of junior developers does not change, the problem will not be solved.
From page 30...
... There is too much disagreement and ideology surrounding development processes. However, there can be some commonality around aspects of good development processes.
From page 31...
... for tool use and effectiveness -- what tool was used, what the tool can and cannot find, what the tool did and did not find, the amount of code covered, and that tool use was verified by a third party. Software Security: Building Security In Discussions in this session focused on software security as a systems problem as opposed to an application problem.
From page 32...
... They work for COTS software, require relatively little expertise, and are aimed at protecting installed software from harm and malicious code. System software security works from the inside out, with input into and analysis of design and implementation, and requires a lot of expertise.
From page 33...
... • What are the emerging software challenges for large-scale enterprises and interconnected enterprises? • What do you see as emerging technology developments that relate to this?
From page 34...
... However, there may well exist what one speaker called "conservation laws of complexity." That is, in a complex interconnected system, complexity cannot 25  Examples of systems where assumptions did not match real life include the Titanic, the Tacoma Narrows bridge, and the Estonian ferry disaster.
From page 35...
... It was also argued that traditional management does not work for complex software development, given the lack of inspection and control. Control requires determinism, which is ultimately an illusion.
From page 36...
... Another factor is that there are more software components to integrate and assemble. Pooling of the world's software capital stock is creating heretofore unimaginably creative applications.
From page 37...
... Web services based on abstraction-encapsulation-reuse are a new approach to applying structure-oriented engineering tradition to information technology (IT)
From page 38...
... This is a core motivational component of the Web 2.0 mash-up focus. Another approach to ad hoc integration uses access to massive amounts of information -- with no reasonable set of predefined, parameterized interfaces, annotation and search will be used as the integration paradigm.
From page 39...
... SUMMARY OF WORKSHOP DISCUSSIONS 39 • Economics.  What are realistic costing/charging models and implementations? • Social networking.  How does one apply social networking technology to help?


This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More information on Chapter Skim is available.