Information Systems Overview Organizing Complex Projects Around Risks Arising From System Dynamic Behavior Neil Siegel Sector Vice-President & Chief Engineer.

Slides:



Advertisements
Similar presentations
European Research Policy: from coordination and cooperation to integration and the ERA Dr. Maria Nedeva MIoIR, MBS. The University of Manchester EULAKS.
Advertisements

Chapter 10 Software Testing
Lecture 2 Team Coordination 1 ICS 126 Team Coordination Team Formation and Organization Group Management Meeting Techniques Large software systems require.
Designing educational opportunities for the emergency manager of the C21 st Neil Britton and John Lindsay.
CSE 436—Personal Software Processes, Software Development Models Ron K. Cytron 3 October 2005.
Project management Project manager must;
Alternate Software Development Methodologies
1 In-Process Metrics for Software Testing Kan Ch 10 Steve Chenoweth, RHIT Left – In materials testing, the goal always is to break it! That’s how you know.
How to: Design and Develop an Application to Ensure its Quality James Hippolite Senior.NET Developer Telecom New Zealand Limited James Hippolite Senior.NET.
CS Software Engineering Process and Practice Welcome! Leon Sterling and Ed Kazmierczak {leon,
Marzano Art and Science Teaching Framework Learning Map
“Not Fully Specified (Project) Objectives” CS524 – Software Engineering I Azusa Pacific University Professor Dr. Sheldon X. Liang Fall I 2007 Ernie Rosales.
1 Independent Verification and Validation Current Status, Challenges, and Research Opportunities Dan McCaugherty IV&V Program Manager Titan Systems Corporation.
Software Testing Using Model Program DESIGN BY HONG NGUYEN & SHAH RAZA Dec 05, 2005.
Copyright 2005 Northrop Grumman Corporation 0 Private/Proprietary Level 1 Human – system integration 15 March 2006 Neil Siegel Sector Vice-President, Technology.
Copyright 2005 Northrop Grumman Corporation 0 Critical Success Factors for system-of-system architecture / engineering 25 October 2006 Neil Siegel Sector.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
Software Reuse: A Conceptual View Presented By: Youssef Alaoui Mdeghri Abdelouhab Taoufiq El Yazid Alaoui Yazidi.
IT Project Management, Third Edition Chapter 11 Chapter 1: Introduction to Project Management.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
Purpose of the Standards
Defining the Activities. Documents  Goal Statement defines why helps manage expectations  Statement of Work what gets delivered defines scope  Software.
The Research Process. Purposes of Research  Exploration gaining some familiarity with a topic, discovering some of its main dimensions, and possibly.
Using A Defined and Measured Personal Software Process Watts S. Humphrey CS 5391 Article 8.
Project Management and Scheduling
Effective proposal writing Session I. Potential funding sources Government agencies (e.g. European Union Framework Program, U.S. National Science Foundation,
Architecture, Implementation, and Testing Architecture and Implementation Prescriptive architecture vs. descriptive architecture Prescriptive architecture:
Don Cole Risk Assessment and Mitigation Project Management for ARA Engineers and Scientists.
What is Business Analysis Planning & Monitoring?
© 2005 Prentice Hall14-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Chapter 4 Requirements Engineering
Copyright Course Technology 1999
1 Chapter 2 Socio-technical Systems (Computer-based System Engineering)
Chapter 2 The process Process, Methods, and Tools
Fourteenth Lecture Hour 9:30 – 10:20 am, Sunday, September 16 Software Management Disciplines Project Control and Process Automation (from Part III, Chapter.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 2Slide 1 Chapter 2 Computer-Based System Engineering As modified by Randy Smith.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Topic (1)Software Engineering (601321)1 Introduction Complex and large SW. SW crises Expensive HW. Custom SW. Batch execution.
Interaction Design Process COMPSCI 345 S1 C and SoftEng 350 S1 C Lecture 5 Chapter 3 (Heim)
1 Software testing. 2 Testing Objectives Testing is a process of executing a program with the intent of finding an error. A good test case is in that.
Requirements Engineering CSE-305 Requirements Engineering Process Tasks Lecture-5.
~ pertemuan 2 ~ Oleh: Ir. Abdul Hayat, MTI 06-Mar-2009 [Abdul Hayat, The Project Management and IT Context, Semester Genap 2008/2009] 1 THE PROJECT MANAGEMENT.
Military Psychology: Teams and Teamwork Dr. Steven J. Kass.
1 Requirements Management - General concepts - Noureddine Abbadeni King Saud University College of Computer and Information Sciences Based on “Software.
Slide 1 Project Management Chapter 4. Slide 2 Objectives ■ Become familiar with estimation. ■ Be able to create a project workplan. ■ Become familiar.
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
Introduction to Systems Analysis and Design
Today’s Agenda  HW #1  Finish Introduction  Input Space Partitioning Software Testing and Maintenance 1.
Chapter 3 Project Management Chapter 3 Project Management Organising, planning and scheduling software projects.
QA Methodology By Rajib Roy Independent Consultant Qcon.
Enabling Reuse-Based Software Development of Large-Scale Systems IEEE Transactions on Software Engineering, Volume 31, Issue 6, June 2005 Richard W. Selby,
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
1 Chapter 8 Building the Analysis Model (1) Analysis Concepts and Principles.
Chapter 1: Fundamental of Testing Systems Testing & Evaluation (MNN1063)
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Test status report Test status report is important to track the important project issues, accomplishments of the projects, pending work and milestone analysis(
Chapter 2 : The Project Management and Information Technology Context Information Technology Project Management, Fourth Edition.
Evaluate Phase Pertemuan Matakuliah: A0774/Information Technology Capital Budgeting Tahun: 2009.
Understanding Frequent Root Causes of System-development Failure 7 March 2012 Neil Siegel Vice-President & Chief Engineer.
Unit – I Presentation. Unit – 1 (Introduction to Software Project management) Definition:-  Software project management is the art and science of planning.
Project Management Why do projects fail? Technical Reasons
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
1 Chapter 2 SW Process Models. 2 Objectives  Understand various process models  Understand the pros and cons of each model  Evaluate the applicability.
Chapter 5 – System Modeling Lecture 1 1Chapter 5 System modeling.
Software Project Planning and Tracking
Chapter 2: The Project Management and Information Technology Context
Software Project Sizing and Cost Estimation
Failure and Design Jaime Baber October 12, 2000
Software Processes.
Presentation transcript:

Information Systems Overview Organizing Complex Projects Around Risks Arising From System Dynamic Behavior Neil Siegel Sector Vice-President & Chief Engineer Northrop Grumman 9 March 2011

Agenda Scope Hypothesis The design-based technique Research results Summary 2

Scope of proposed study This study aims to assess the efficacy of one particular method of improving the outcomes on complicated, large-scale, software-intensive system development projects 3

“Bottom-line up front” 4

Systems are important to society, but many system development efforts fail 5 What do we mean by “fail”: –Do not produce a product that meets the original specifications –Produce such a product only after taking significantly more time and/or money than originally expected. –In the extreme, many such projects are cancelled before completion Failure is apparently common: –(Glass 2001) cites data indicating that only about 16% of the system development projects that he surveyed were listed as successful by their own developers –(Johnson 2006) cites data from the Standish Group, which describes results from a 2004 survey: just 29% of development projects succeeded

Scope of the systems of interest Complex emergent behavior, as described by (Rechtin 1991) Interactions with physical devices (physically-moving mechanisms, other time-sensitive mechanical devices, etc.) Stressing asynchronous stimuli (such as extraordinary high data-ingest rates, or highly-stressed communications structures) Extraordinarily high availability / reliability requirements Development efforts of large size Systems that need to display much early progress through prototyping and re-use 6

Hypotheses During the development phase of a large- scale, complex computer-based system, the use of a specific design-based technique that centralizes the control of the dynamic behavior of a system will lower the density of those defects that are attributable to unplanned adverse dynamic system behavior 7

Partitioning the work I propose using the design process to partition the work into different “skill bins”, so as to provide better ways to assign people to tasks. –This allows a particular difficult task (control and management of the system’s dynamic behavior) to be partitioned away from most of the development team. Under current methods, the “hard” parts of the work can be disseminated into a large portion of the tasks 8

How I accomplish that partitioning The System Architecture Skeleton 9

Results 10

All 6 periods / all 4 cases 11

Defect density “ Use of the design-based technique will reduce the density of defects attributable to errors in managing system dynamic 12 Project YYYY, periods I-III contractor tests, attributable problem reports by month. behavior”

13 Cost performance also tracks the dependent variable

14 Summary & interpretations

15 The data indicate that the proposed design- based technique may in fact lead to better outcomes. Indicated by a materially-lower density of defects (on the order of four times lower) that were attributable to errors in controlling system dynamic behavior Summary & interpretations

The design-based technique considered herein only applies to projects where such centralization is possible –The study did demonstrate that this set of projects is not vanishingly small This specific technique, however, is only one possible technique for creating a partitioning of a project into easy and difficult portions –Future studies could propose and assess other such techniques. 16 Summary & interpretations

Implications for practice Control structures may be more important than generally recognized New goal for the design process 17

Questions? 18

NGIS clearance approval number: ISHQ