DoD Software Engineering Science and Technology Summit Software Technology Needs

1. DoD Software Engineering Science and Technology SummitSoftware Technology Needs Dennis J. Frailey Principal Fellow, Raytheon D-Frailey@Raytheon.com

2. Summary of Major Problems • Overwhelming SW Issues of Concern to DoD Programs • Size and complexity of software systems • megasystems / systems of systems • Information issues such as security and analysis/fusion • especially with open systems and wireless technologies • Interoperability among diverse systems • including legacy systems • Quality, testability, maintainability, and other “ilities” • More severe requirements than commercial world • Major Trends in Software and Software-based Systems • Network-centric / distributed systems • Growing role of middleware • Plug and play characteristics • Distribution of security and other functionality

3. Software Product Technology Needs • Complexity of systems / megasystems - is OO enough? • how to know needs; specify, model & design solutions; build scenarios • end-to-end quality of service / middleware standards and capabilities • Information issues • security against attack (information warfare) • secure data interchange • information analysis and fusion • Interface issues • dynamic and negotiated; flexible; yet secure and reliable • “Ility” issues • Developing, validating autonomous, non-deterministic components • Unique reliability, safety, security, and other “ility” requirements • Address DoD-specific, severe or special requirements in: • Human/Computer I/F • High performance real time • Robotics in real world / hostile environments • etc. etc. etc. (not enough room on the slide)

4. Software Processes / Tools • Productivity / cycle time improvement • Simulation based acquisition (including distributed systems) • May tie to verification and validation problems • Middleware tools; processes to incorporate • Reuse via families, standards, abstraction, interoperable architectures • True evolutionary development paradigms (for SYSTEMS) • Collaborative work environments • COTS - processes and tools for using effectively, evaluating, etc. • Modeling languages for DoD problems (e.g., force structure) that can be used directly in simulation, automatic application generation, testing • Tools, standards and processes for data interchange and interoperability •  Technology obsolescence / upgrade / maintenance… • Using low quality COTS in high quality applications • Work with commercial industry to advance design methods for embedded / autonomous systems

5. Software Management • Program management and system engineering awareness of software and system complexity issues • Education programs • Integration of disciplines and process orientation • Clear position on CMM, CMMI, IPD and IPTs • Commitment to process improvement initiatives • Program managers undoing the work of procurement managers • Standards and tools for metadata • Develop management techniques for megasystems •  Management data bases and data exchange must be standardized and designed to resist obsolescence (archival techniques, data exchange techniques)

6. Technology Transition. • System engineering definition / body of knowledge • Scalability, re-hostability techniques for new technologies • Encourage common, supported, proven tools and training • Support new approaches but make sure they work in the real world • Rapid algorithm implementation • Proof by simulation or analysis for software changes and upgrades •  Define and support good product line standards & domain standards • E.g., standards-based architectures and reuse frameworks such as JTA • Verification and validation techniques for massive systems • Influence standards and research agendas for middleware, real time systems, user interfaces, and other technologies where the commercial world will achieve much of what DoD needs

7. Major Solution Elements • We must use COTS, reuse and standards • help align the commercial world to support DoD needs • It’s a system engineering problem! • Systems engineering and SW engineering must work together • Tools, methods, cultures, etc - get rid of stovepipes • Understanding needs • Capture/codify system engineering and program management knowledge • Then train system engineers and program managers for software-intensive programs • Tie to CMMI • The world will continue to change • Continuing education and training of everyone to keep up with technology changes

8. Backup Slides

9. Non-Technical, Socio-Political Barriers • Contracting & purchasing practices that encourage stovepiping and inhibit cooperation • Organizational approaches and business models that isolate functions and offices that need to cooperate • Lack of decision-making authority and adequate understanding at high enough levels to affect the entire scope of a megasystem • Parochial decision making • “Optimal” solutions for individual organizations that achieve sub-optimal results for the system • Example: incompatibilities between the branches of the armed service • Need unprecedented levels of interaction between SW developers, system acquirers, military strategists, and end users

10. DoD vs Commercial Interests • Similar needs for size, complexity, productivity, interoperability, performance • Different needs for “ilities” (defining, measuring, achieving) • Reliability, robustness, affordability, dependability • Safety critical in hostile environments -> formal methods such as ADLs • Standardization • Classification issues • Maintainability, supportability, health assessment • Security (different profiles -- not 24/7 but more intense) • Quality of network, software, system, service • Military forces often work in environments that lacks fixed assets • What should DoD do to make it come out right? • Commercial world will make it small and fast • Control and confidence and QOS-enabled are areas that commercial world will not necessarily do in a DoD acceptable manner • Need to influence the commercial world to solve these problems (push the R&D aspects) -- they don't see the problems. Want to align rather than to redirect the commercial world. • Domain-specific aspect will always be proprietary.

11. Research Comments • Understand large scale distributed systems, such as total ship computing environment or national missile defense • Left alone, to their own devices, they will not solve the problems of people building systems - they will solve elegant problems in the abstract • Must have less isolation from reality in research communities • Solve tomorrow's problems rather than today's and yesterday's • Motivate/educate researchers to learn what the new challenges are • Articulate what is important about software to decision makers • Give academic researchers the background to understand the problems • Focus on embedded systems and software technologies, high confidence, systems of systems, fault tolerance, glue-ware research (ARP/RARP), etc. • Emphasize higher level programming abstractions (such as MOBIES) • Use large, targeted programs rather than toy programs • Not all funding agencies are chartered for things on this scale • Agencies with large programs must be directed • put the right people in the right positions in these agencies • give them the right kinds of targets

12. Government Comments • Acquisition vs program offices with respect to process expectations • Contractors are told they must have SEI level 3 or 4 to qualify, then there is no support for level 3/4 practices on the program • Need appropriate skills in government reps to IPTs on major projects • Procurements are too easily influenced by academic, “gee whiz” approaches and departures from tried and true things that work • Program managers must be educated on what are the right things to expect and ask for on major SW programs • What do you want first? CMM level 3/4/5 or CMMI? Contractors need clear and consistent direction.