JVB-STC'97- 1 #*#* Successful Adoption and Use of Object Oriented Technologies STC ‘97 April 30, 1997 Jim Van Buren.

Slides:



Advertisements
Similar presentations
A presentation from June 20, 2000 Jim Brosseau The ‘How-To’ of Software Process Improvement.
Advertisements

Object-Oriented Software Development CS 3331 Fall 2009.
CS487 Software Engineering Omar Aldawud
Software Engineering CSE470: Process 15 Software Engineering Phases Definition: What? Development: How? Maintenance: Managing change Umbrella Activities:
CSE 470 : Software Engineering The Software Process.
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
CLEANROOM SOFTWARE ENGINEERING
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
W5HH Principle As applied to Software Projects
Object-Oriented Metrics. Characteristics of OO ● Localization ● Encapsulation ● Information hiding ● Inheritence ● Object abstraction.
© Prentice Hall CHAPTER 9 Application Development by Information Systems Professionals.
R R R CSE870: Advanced Software Engineering (Cheng): Intro to Software Engineering1 Advanced Software Engineering Dr. Cheng Overview of Software Engineering.
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
COMP2002 Lecturecopyright DMU 2001 COMP2002 Managing OT Projects.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Software Quality: An Overview From the Perspective of Total Quality Management By Kan, Basili and Shapiro.
Capability Maturity Model
1 First, some interesting numbers: ~2,000 ~80 2 >200 [To be defined on March 23]
Using Six Sigma to Achieve CMMI Levels 4 and 5
SEI´S Software Product Line Tenets Linda M. Northrop Software Engineering Institute IEEE Software July/August 2002.
Chapter 4 Interpreting the CMM. Group (3) Fahmi Alkhalifi Pam Page Pardha Mugunda.
CPTE 209 Software Engineering Summary and Review.
Chapter 2 The process Process, Methods, and Tools
Dillon: CSE470: SE, Process1 Software Engineering Phases l Definition: What? l Development: How? l Maintenance: Managing change l Umbrella Activities:
CLEANROOM SOFTWARE ENGINEERING.
N By: Md Rezaul Huda Reza n
Software Project Management Introduction to Project Management.
GENERAL CONCEPTS OF OOPS INTRODUCTION With rapidly changing world and highly competitive and versatile nature of industry, the operations are becoming.
1 Chapter 2 The Process. 2 Process  What is it?  Who does it?  Why is it important?  What are the steps?  What is the work product?  How to ensure.
Software System Engineering: A tutorial
What is a life cycle model? Framework under which a software product is going to be developed. – Defines the phases that the product under development.
Introduction to Software Engineering LECTURE 2 By Umm-e-Laila 1Compiled by: Umm-e-Laila.
Identify steps for understanding and solving the
Rational Unified Process Fundamentals Module 5: Implementing RUP.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
Software Engineering - I
Manag ing Software Change CIS 376 Bruce R. Maxim UM-Dearborn.
Software Product Line Material based on slides and chapter by Linda M. Northrop, SEI.
CEN5011, Fall CEN5011 Software Engineering Dr. Yi Deng ECS359, (305)
Chapter 4 프로세스 모델 Process Models
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
Copyright © Craig Larman All Rights Reserved 1 Software Economics: The Motivation for Object Technologies and Iterative Development.
Chapter 2 Object-Oriented Paradigm Overview. Getting Acquainted with the Class Project Read the requirements specification carefully Make note of any.
1 Chapter 8 Building the Analysis Model (1) Analysis Concepts and Principles.
1 #*#* Transitioning Your Organization to an Object-Oriented Methodology.
SOFTWARE ENGINEERING. Objectives Have a basic understanding of the origins of Software development, in particular the problems faced in the Software Crisis.
 Many models have been proposed to deal with the problems of defining activities and associating them with each other  The first model proposed was the.
1 The Requirements Problem Chapter 1. 2 Standish Group Research Research paper at:  php (1994)
Introduction to OPEN Sidney Nogueira 12/11/2003.
Project Management Strategies Hidden in the CMMI Rick Hefner, Northrop Grumman CMMI Technology Conference & User Group November.
Class-oriented metrics – Weighted methods per class, depth of the inheritance tree, number of children, coupling, response for class, lack of cohesion.
 System Requirement Specification and System Planning.
Product Line Architecture. Systems Systems often come in families: basic, regular, professional, enterprise,… Can we share components? Is architecture.
Advanced Software Engineering Dr. Cheng
CLE Introduction to Agile Software Acquisition
Pragmatics 4 Hours.
Chapter 24: Architecture Competence
IT Architecture Technical blueprint for evolving a corporate infrastructure resource that can be shared by many users and services processing systems hardware.
Software Metrics 1.
Introduction to Design Patterns
Software Life Cycle “What happens in the ‘life’ of software”
Software Processes (a)
Tour VII: Change Management
INFORMATION SYSTEMS PLAN
CS310 Software Engineering Lecturer Dr.Doaa Sami
Use of CMMI in an Acquisition Context Using CMMI for Process Improvement at USAF Space and Missile Systems Center (SMC) Dr. Jack R. Ferguson
Quality Assurance for Component-Based Software Development
Software Maintenance Part1 Introduction. Outlines What Is Software Maintenance Purposes of Maintenance Why We Need It Maintenance Difficilties Some Tips.
Presentation transcript:

JVB-STC'97- 1 #*#* Successful Adoption and Use of Object Oriented Technologies STC ‘97 April 30, 1997 Jim Van Buren

JVB-STC'97- 2 #*#* Objective u Presentation of Model for Adoption of OT by DoD Organizations v For Non-OO capable DoD organizations v Training Issues v Development Process Issues v OO Management Issues

JVB-STC'97- 3 #*#* Outline u Background v Object Oriented Definitions v Technology Adoption u OO Technology Adoption v DoD Adoption Context v Training v Development Process v Management v Pushing Adoption 

JVB-STC'97- 4 #*#* Why OO? u Maintainability Advantages u Time to Market u Required by COTS Libraries u Reuse u... v Organizational Change v Existing System Meets Requirements v... v Resource Cost (Memory and Processing Time) Why Not OO?

JVB-STC'97- 5 #*#* Encapsulation Underlying Concept behind OO u An object’s interface is the only way the object can be manipulated or used u Clients know only about an object’s interface u Encapsulates Data and Methods v Allows Objects and their clients can be written in different languages v Allows Objects and their clients can run on different machines v Isolates inevitable maintenance changes v Enables Geographically Distributed Development by loosely coupled teams v Enables Evolutionary Development v Enables Reuse

JVB-STC'97- 6 #*#* What is OO Development? u Conceptualize and Abstract Requirements u Analysis (Develop Models) u Design (Create Architectures) u Evolve Application (Iteratively) u Identify Classes u Identify Objects u Identify Relationships u Specify Interfaces u Write Code u Fix Application (Iteratively) Macro Micro Both are Valid Views! Both are Necessary!

JVB-STC'97- 7 #*#* Technology Adoption u The STSC helps U.S. Air Force organizations identify, evaluate, and adopt technologies that improve software product quality, production efficiency, and predictability.” Adapted From: Fowler & Przybylinski, 1988 AdoptEvaluateIdentify Time Contact Awareness Understanding Evaluation Trial Use Commitment Adoption Institutionalization

JVB-STC'97- 8 #*#* Technology Adoption Based on SEI’s IDEAL Model OT is increasingly a potential solution Tailor and use “standard” STSC OT adoption plan. Pilot OT

JVB-STC'97- 9 #*#* Outline  u Background v Object Oriented Definitions v Technology Adoption u OO Technology Adoption v DoD Adoption Context v Training v Development Process v Management v Pushing Adoption

JVB-STC' #*#* DoD Adoption Context Project Attributes u Functionality Errors not Tolerated u Schedule Predictable u Maintainable Very long software lifetime u Community expects Reviews and Documents u Move underway from Mainframe to Workstation or PC platforms

JVB-STC' #*#* DoD Adoption Context (cont.) Organizational Attributes u Personnel v CiviliansVery Low Turnover v MilitaryVery High Turnover v ContractorsCritical to success u Hierarchical and Command Driven Organizations u Very Strong Mission Focus u SPI Activities underway u Training Funds controlled by Organization (not Project)

JVB-STC' #*#* OT Adoption Issues General Adoption Issues u Resistance to Change u On Going Improvement Programs u Mission Requirements OO & OT Specific u Training u Development Process u Management Changes

JVB-STC' #*#* Training u Focus on Paradigm Shift v Education not Training v Very Long Time Scale u Must Map to Development Process v Training not Education u Training Truisms Apply v Just in Time v Mentoring u Build Organic Training Capability v High Turnover v Long Product LifeCycle u Provide Training to Project Reviewers

JVB-STC' #*#* Development Process u Incremental v Largest Process Change v A few Formal Reviews replaced by many “In Process” Reviews v Monolithic Specification (requirements or design) replaced by evolving baseline(s) u Different from the Old Process v Let the technical gurus specify it v Make sure it specifies sound software engineering processes  Formal Design and Test subprocesses  Metrics Collection  A Formal Peer Review Process  Coding Standards u Focus on the Software Architecture v Should be the first technical step

JVB-STC' #*#* Management of OO Projects in the non OO organization The basics do not change... just the details.  Staffing  Get, keep, and train the right people. (Abstraction Skills)  Estimating  Different size metrics. (MOOSE, POPS, OPA)  Planning  Different milestones. (In Process Reviews)  Tracking Progress  Different measures of completeness. (Use Earned Value)  Requirements Change  RM very important due to incremental approach.  Risk  Identify and Track (Particularly New Technology Impacts)  Leadership  Different learning curves for staff.  Both new technology and new development paradigms are being introduced.  When the going gets tough the development staff will demand to use their tried and true methods.  There will be an intense desire to hack.

JVB-STC' #*#* OT Adoption Issues u No Explicit Reason for OT u “Hacking” Issue v Micro OO (without Macro OO) u Estimation Techniques and Heuristics v Lack of Experience, No Industry Standards u Software Architecture v How is a Product Line Approach institutionalized? u Other Organizational Elements v i.e., CM, QA, Test have to change their processes u Expectations - OT is not a Silver Bullet.

JVB-STC' #*#* Pushing OT Adoption u Specifying “... shall use OO...” does NOT work v Often get Functional Systems expressed as Objects v Developer gets “Time to Market” Savings when acquirer wanted High Maintainability u Solution Strategy v Explicitly Determine why OO  (e.g., Maintainability, Reuse, Time to Market, etc.) v This is the requirement, not “...shall use OO...” v Express the requirement in a testable way  Example: For a goal of high maintainability - Use Coupling, Cohesion, Inheritance Depth (and other) metrics to define design maintainability u Remember v OT is not a Silver Bullet.

JVB-STC' #*#* Conclusions u OT Adoption needs to be planned like any other project v Good planning implies you have a process for adoption projects v The adoption process needs to be tailored for OO adoptions u DoD has a unique development culture v Most OO experience and practices relate to the commercial world u OT is not a Silver Bullet v Be explicit about your goals and OT may be the solution u Organizational Adoption of OO in a Federal Setting is not easy... but it can succeed

JVB-STC' #*#* Successful Adoption and Use of Object Oriented Technologies Jim Van Buren Charles Stark Draper Laboratory Software Technology Support Center Voice:(801) (x3042)DSN (x3042) Fax:(801) DSN