The Architecture Lecture September 2006 Cem Kaner CSE 1001

NDIA Top 5 Software Issues Workshop Address Kristen Baldwin Software Engineering & Systems Assurance Directorate Office of the Deputy Under Secretary of Defense Acquisition and Technology August 24, 2006 VERSION 1.0

SYSTEMS AND SOFTWARE ENGINEERING DIRECTORATE, USD(A&T) Need for DoD focus on Software Engineering Increasing rate of software overruns –1994: 16.2% of SW projects completed on-time, on-budget 1 – : schedule overruns up 21%, cost overruns up 11% 2 –2005: 50% of SW projects still late, over budget 2 National concern –PITAC identifies SW as “major vulnerability” 3 –Cyber security attacks rising 20+% per year 3 –2 of 10 priority areas: “Secure Software Engineering and Software Assurance” and “Metrics, Benchmarks, and Best Practices” 3 DoD software performance –Emerging results from SW Industrial Base study: virtually every ACAT ID program in last 5 yrs has had SW problem resulting in delay, test failure, or added cost 4 AT&L program support review findings –2 ½ yrs of reviews demonstrated systemic SW problems across programs, linked to SE execution Lack of full and adequate SE planning and execution Lack of clearly defined roles and responsibilities Policy decisions having major impact on SW development Testing issues Defense software investment –DARPA CS R&D funding to universities down 50% ( ) 5 –DoD SEI core funding relatively level for past decade 5 –In contrast, total federal government support to universities up 50% 5 1 Copyright © 1995 The Standish Group International, Inc. All Rights Reserved 2 Copyright © 2005 The Standish Group International, Inc. All Rights Reserved 3 President’s Information Technology Advisory Committee Report to the President, February 2005, “Cyber Security: A Crisis of Prioritization” 4 Pierre Chao, Senior Fellow and Director of Defense-Industrial Initiatives, Center for Strategic and International Studies 5 National Science Foundation WebCASPAR database

SYSTEMS AND SOFTWARE ENGINEERING DIRECTORATE, USD(A&T) Lack of Integrated requirement, design, analysis, coding and verification development environment. Lack of tools to detect design, coding and requirement deficiencies early for object oriented design using full embedded system simulation with H-I-L. Lack of tools to capture and estimate software development costs. Lack of qualified automated code generators for design tools. Testing environments in general do not accurately capture the characteristics of the product (engine system, aircraft system). What does industry (integrators) view as the current problems in SW development?* *From 2006 DDR&E SW Producibility Workshop

Defining Programming ● A program is a set of instructions for a computer -- or -- ● A program is a communication about a problem and a proposed solution, among many stakeholders distributed in space and time, that includes instructions for a computer.

Structure of a computer program The program receives inputs, processes them and yields outputs InputOutput

Structure of a computer program The program receives inputs, processes them and yields outputs Monolithic program: One big method -- main() – does everything. InputOutput

The program receives inputs, processes them and yields outputs It uses subroutines (methods) to divide the task into manageable pieces Problems got too complex for monolithic programs, so we tried various flavors of modular, structured programming InputOutput Main Sub

Look at the inputs and outputs Interface with humans Interface with devices Interface with other systems Input & output Processing

Interfacing with the world is complex Interface with humans I / O Processing UI devices I / O Interface with system devices I / O Interface with other systems I / O Communication devices I / O

Interfacing with the world is complex Processing Rules / models for dealing with humans Rules / models for dealing with each type of external system Rules / models for dealing with each type of device

Complexity ● There are many types of humans, with different roles / needs / expectations and so different interface rules / models will be appropriate under different circumstances: – Example, the information about a financial database you might present to a tax auditor might be different from the information you present to the data entry clerk or the executive who is doing business planning based on the data. (Who should see negotiating notes, for example?) ● Input can come from one entity (e.g. one person, or through one system) but be delivered on behalf of some other entity. ● The rules for one external system (e.g. Visa credit card payments) might be different for the rules for another external system (American Express credit card payments) even if the basic transaction is intended to be the same.

Interfacing with the world is complex Processing Rules / models for dealing with humans Rules / models for dealing with each type of external system Rules / models for dealing with each type of device One of the advantages of object-oriented development is that we create models of things (objects) that include specifications of what we can do with those things (methods) and how to do them. We can define analogous methods for many different types of objects, making it easier to extend a program to new stakeholders, devices or systems.

Interfacing with the world is complex Interface with humans I / O Processing UI devices I / O Interface with system devices I / O Interface with other systems I / O Communication devices I / O Interface with test system that can supply any inputs and accept any outputs that would otherwise be targeted to some other subsystem I / O