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

2. Dennis J. Frailey 8/7/20012 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. Dennis J. Frailey 8/7/20013 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. Dennis J. Frailey 8/7/20014 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. Dennis J. Frailey 8/7/20015 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. Dennis J. Frailey 8/7/20016 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. Dennis J. Frailey 8/7/20017 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. Dennis J. Frailey Backup Slides

9. Dennis J. Frailey 8/7/20019 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. Dennis J. Frailey 8/7/200110 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. Dennis J. Frailey 8/7/200111 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. Dennis J. Frailey 8/7/200112 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.