The Architecture Lecture

September 2006

Cem Kaner

CSE 1001

NDIA Top 5 Software IssuesWorkshop Address

Kristen BaldwinSoftware Engineering & Systems Assurance

DirectorateOffice 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-budget1

– 2000-2004: schedule overruns up 21%, cost overruns up 11%2

– 2005: 50% of SW projects still late, over budget2

• National concern– PITAC identifies SW as “major vulnerability” 3

– Cyber security attacks rising 20+% per year3

– 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 cost4

• 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% (2001-2004)5

– DoD SEI core funding relatively level for past decade5

– In contrast, total federal government support to universities up 50%5

1 Copyright © 1995 The Standish Group International, Inc. All Rights Reserved2 Copyright © 2005 The Standish Group International, Inc. All Rights Reserved3 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 Studies5 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 outputsInput Output

Structure of a computer program

The program receives inputs, processes them

and yields outputs-------------

Monolithic program: One big method -- main() –

does everything.

Input Output

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

Input OutputMain

SubSub

Sub

Sub

Sub

Sub

Sub

Look at the inputs and outputs

Interface with humans

Interface with devices

Interface with other systems Input &

output

Input & output

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 / OCommunication

devicesI / 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 / OCommunication

devicesI / 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