University of Southern California Center for Systems and Software Engineering A Tractable Approach to Handling Software Productivity Domains Thomas Tan.

Slides:



Advertisements
Similar presentations
Database Systems: Design, Implementation, and Management Tenth Edition
Advertisements

Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Introduction to Databases
Copyright 2000, Stephan Kelley1 Estimating User Interface Effort Using A Formal Method By Stephan Kelley 16 November 2000.
ICS (072)Database Systems: A Review1 Database Systems: A Review Dr. Muhammad Shafique.
Automated Analysis and Code Generation for Domain-Specific Models George Edwards Center for Systems and Software Engineering University of Southern California.
University of Southern California Center for Software Engineering CSE USC COSYSMO: Constructive Systems Engineering Cost Model Barry Boehm, USC CSE Annual.
11/08/06Copyright 2006, RCI1 CONIPMO Workshop Out-brief 21 st International Forum on COCOMO and Software Cost Modeling Donald J. Reifer Reifer Consultants,
University of Southern California Center for Systems and Software Engineering Productivity Data Analysis and Issues Brad Clark, Thomas Tan USC CSSE Annual.
University of Southern California Center for Systems and Software Engineering A Tractable Approach to Handling Software Productivity Domains Thomas Tan.
COCOMO II Calibration Brad Clark Software Metrics Inc. Don Reifer Reifer Consultants Inc. 22nd International Forum on COCOMO and Systems / Software Cost.
MSIS 110: Introduction to Computers; Instructor: S. Mathiyalakan1 Systems Design, Implementation, Maintenance, and Review Chapter 13.
Ch8: Management of Software Engineering. 1 Management of software engineering  Traditional engineering practice is to define a project around the product.
IS112 – Chapter 1 Notes Computer Organization and Programming Professor Catherine Dwyer Fall 2004.
University of Southern California Center for Systems and Software Engineering Building Cost Estimating Relationships for Acquisition Decision Support Brad.
University of Southern California Center for Systems and Software Engineering Assessing the IDPD Factor: Quality Management Platform Project Thomas Tan.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
1 IS112 – Chapter 1 Notes Computer Organization and Programming Professor Catherine Dwyer Fall 2005.
University of Southern California Center for Systems and Software Engineering Software Cost Estimation Metrics Manual 26 th International Forum on COCOMO.
University of Southern California Center for Software Engineering CSE USC 9/14/05 1 COCOMO II: Airborne Radar System Example Ray Madachy
University of Southern California Center for Systems and Software Engineering © 2009, USC-CSSE 1 An Analysis of Changes in Productivity and COCOMO Cost.
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
LSU 10/09/2007System Design1 Project Management Unit #2.
Chapter 23 – Project planning Part 2. Estimation techniques  Organizations need to make software effort and cost estimates. There are two types of technique.
What is Software Engineering? the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software”
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Lecture 22 Instructor Paulo Alencar.
An Introduction to Software Architecture
1 Process Engineering A Systems Approach to Process Improvement Jeffrey L. Dutton Jacobs Sverdrup Advanced Systems Group Engineering Performance Improvement.
Chapter 6 : Software Metrics
2 Systems Architecture, Fifth Edition Chapter Goals Describe the activities of information systems professionals Describe the technical knowledge of computer.
SCSC 311 Information Systems: hardware and software.
Principles of Information Systems, Sixth Edition Systems Design, Implementation, Maintenance, and Review Chapter 13.
111 Notion of a Project Notes from OOSE Slides – a different textbook used in the past Read/review carefully and understand.
1 Chapter 23 Estimation for Software Projects. 2 Software Project Planning The overall goal of project planning is to establish a pragmatic strategy for.
SE: CHAPTER 7 Writing The Program
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Principles of Information Systems, Sixth Edition Systems Design, Implementation, Maintenance, and Review Chapter 13.
Cost Estimation. Problem Our ability to realistically plan and schedule projects depends on our ability to estimate project costs and development efforts.
Systems Analysis and Design in a Changing World, Fourth Edition
CMSC 345 Fall 2000 Requirements Overview. Work with customers to elicit requirements by asking questions, demonstrating similar systems, developing prototypes,
PRESENTAION TOPIC : DSS Development Presented TO: Sir Ahmad Tisman Pasha Presented BY : Uzma Noreen Roll # BSIT (6 th ) Department.
Chapter 6 CASE Tools Software Engineering Chapter 6-- CASE TOOLS
University of Southern California Center for Systems and Software Engineering © 2010, USC-CSSE 1 Trends in Productivity and COCOMO Cost Drivers over the.
Principles of Information Systems, Sixth Edition 1 Systems Design, Implementation, Maintenance, and Review Chapter 13.
Estimating “Size” of Software There are many ways to estimate the volume or size of software. ( understanding requirements is key to this activity ) –We.
Effort Estimation In WBS,one can estimate effort (micro-level) but needed to know: –Size of the deliverable –Productivity of resource in producing that.
SOFTWARE ENGINEERING. Objectives Have a basic understanding of the origins of Software development, in particular the problems faced in the Software Crisis.
SWE 513: Software Engineering
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
Software Design and Architecture
1 Agile COCOMO II: A Tool for Software Cost Estimating by Analogy Cyrus Fakharzadeh Barry Boehm Gunjan Sharman SCEA 2002 Presentation University of Southern.
Chapter 1 Computer Technology: Your Need to Know
Chapter 33 Estimation for Software Projects
Classifications of Software Requirements
COCOMO III Workshop Summary
Productivity Data Analysis and Issues
System Design.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 23 Estimation for Software Projects copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Constructive Cost Model
Pongtip Aroonvatanaporn CSCI 577b Spring 2011 March 25, 2011
The Extensible Tool-chain for Evaluation of Architectural Models
Software Metrics “How do we measure the software?”
More on Estimation In general, effort estimation is based on several parameters and the model ( E= a + b*S**c ): Personnel Environment Quality Size or.
COCOMO Models.
Chapter 33 Estimation for Software Projects
Software Engineering: A Practitioner’s Approach, 6/e Chapter 23 Estimation for Software Projects copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Automated Analysis and Code Generation for Domain-Specific Models
Chapter 26 Estimation for Software Projects.
Project Management Unit #2
COCOMO MODEL.
Presentation transcript:

University of Southern California Center for Systems and Software Engineering A Tractable Approach to Handling Software Productivity Domains Thomas Tan Brad Clark 24 th International Forum on COCOMO and Systems/Software Cost Modeling November 3, 2009

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling2 Table of Contents Overview Operational Context Software Application Difficulties Productivity Group Matrix –Example Mapping of Systems –Aerospace Project Data Analysis COCOMO II Implications Next Steps Q&A

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling3 Overview Conventional labels used in Software Productivity Domains use system engineering terms Systems can be comprised of many different software applications, e.g. Command and Control Productivities are influenced by the difficulty of the application type and the operating environment Many applications in a system can exhibit different productivities

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling4 Motivation Our motivation is to create a new productivity classification system that can be –Understood by both cost estimators and engineers –Flexible enough to accommodate a wide range of software applications This presentation discusses this new approach As a work-in-progress, we welcome comments and suggestions Please join us at the workshop to discuss this approach and its usage

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling5 Overview This approach employs general descriptions to characterize the intended “operational context” (environment) and an application’s “degree of difficulty”: –Operational Context describes the intended environment, platform or target host on which the software application will operate –The application difficulty is the degree of difficulty in specifying, developing, and testing a software application

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling6 Operational Context Dimensions of constraints include electrical power, computing capacity, storage capacity, repair capability, platform volatility, physical environment accessibility, etc.

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling7 Operational Context Very Unconstrained –Unlimited electrical power with backup battery –Regular upgrades and maintenance –Heavily COTS-hardware and COTS-software dependent –Support multiple users –Limited loss during system down time Unconstrained –Operating environment may move over land and water –Electrical power is limited by mobility (size dependent) –Computing and storage capability depends on ability to carry weight and size –Upgrades and maintenance are not frequent –Components are modular and cannot be broken apart

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling8 Operational Context Constrained –Similar to unconstrained in term of upgrade, maintenance, and component structure –Operating environment may move through the air –Electrical power, computing and storage capability are limited due to weight constraints Very Constrained –Battery is the primary source of electrical power. –Components are miniaturized and custom-made with special tool to access –No ability to upgrade and maintain system after deployment Highly Constrained –Hardware is required to survive in adverse conditions –Limited software control –Real-time sensor inputs and commands –Upgrade and maintenance is not feasible after deployment –Unique system platform and evolving in maturity as system being developed

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling9 Software Application Difficulties Difficulty would be described in terms of required software reliability, database size, product complexity, integration complexity, information assurance, real- time requirements, different levels of developmental risks, etc.

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling10 Software Application Difficulties Very Easy –Risks are well understood and little loss –Business or operational logic is straightforward –Limited in interfacing with other software applications –Mostly stand-alone functionality –Simple tests Easy –Not a new type of application –Risks are understood and cure exists –Business or operational logic is straightforward –Requires low reliability due to small or little loss when unavailable –Limited external interface and security requirements Nominal –Somewhat complicated business logic –Risks exists and may need additional study to find mitigation –May require distributed environment with additional security requirements –Moderate, easily recoverable loss for nominal reliability –Not a new type of application

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling11 Software Application Difficulties Challenging –High reliability due to greater size of loss or high probability of risk –Risks are challenging to resolve –Very complicated business logic, external storage may be necessary due to distributed environment –New type of application –High level real-time response and security requirements –Additional communication interfaces necessary for external components or systems Very Challenging –Extremely complicated business logic –Risks are very challenging to resolve and loss is great (disastrous consequences) –Many automated controls with limited human control –New type of application –High level real-time response and security requirements –Communication to external components through different interfaces

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling12 Productivity Group Matrix Operational Context Application Difficulty Very Uncon- strained Uncon- strainedConstrained Very Constrained Extremely Constrained Very Easy1,11,21,31,41,5 Easy2,12,22,32,42,5 Nominal3,13,23,33,43,5 Challenging4,14,24,34,44,5 Very Challenging 5,15,25,35,45,5 The intersection of an Operational Context and Application Difficulty represent a Productivity Group –Each group includes number of project data points, data range, simple cost estimating relationship (of the form: Y = aX b ), standard error, percent bias, and the coefficient of determination, R 2

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling13 Example Mapping to Systems Very Unconstrained and Very Easy may include systems like: –Business Analysis Tools –Database –Data Mining –Data Warehousing –Diagnostics Very Unconstrained and Easy may include systems like: –Logistics –Training –Support –Test Constrained and Challenging may include systems like: –Flight Systems –Radar –Signal Processing We welcome comments and suggestions on mappings of systems to the productivity groups.

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling14 Aerospace Project Data Analysis Data collection from Aerospace –Data from Aerospace Corp. report* –188 data records –4 Operating Environments –8 Application Domains Our experiment –Challenging Application Difficulty: Signal Processing –Easy Application Difficulty: Test –Calculate estimating relationship (in Y = aX b form), standard error, and R 2 –Our hypothesis is that Easy Application Difficulty will have higher productivity than Challenging Application Difficulty * Gayek, Long, Bell and Larson, “Software Cost and Productivity Model,” Aerospace Report ATR- 2004(8311)-1, The Aerospace Corporation, El Segundo, CA, Feb 04

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling15 Aerospace Project Data Analysis Challenging Application Difficulty: Signal Processing –40 records –Estimating relationship for effort Effort = x (Size) 0.93 R 2 = 0.7 Standard Error = 0.57

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling16 Aerospace Project Data Analysis Easy Application Difficulty: Test –16 records –Estimating relationship for effort Effort = 7.46 x (Size) 0.97 R 2 = 0.68 Standard Error = 0.53

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling17 Aerospace Project Data Analysis Using the estimating relationship to compare Easy and Challenging Application Difficulty –Size in KSLOC –Effort in PM –Productivity in SLOC/PM Very Easy: TestChallenging: Signal Processing SizeEffortProductivityEffortProductivity

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling18 COCOMO II Implications Productivity Groups may be used to to pre-set COCOMO II Parameters. This is also a work-in-progress. COCOMO II Parameters Very UnconstrainedUnconstrainedConstrained Very Constrained Extremely Constrained PREDHNLVL RESLHNLVL CPLX-DeviceVLN, LHVHXH PVOLLNHVH TIMENHVHXH STORNHVHXH Pre-sets driven by Operational Context

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling19 COCOMO II Implications Pre-sets driven by Application Difficulty FactorsVery EasyEasyNominalChallenging Very Challenging PREDHNLVL RESLHNLVL RELYVLLNHVH CPLX-ControlVLN, LHVHXH CPLX- Computations VLN, LHVHXH CPLX-DataVLN, LHVHXH CPLX-UIVLN, LHVHXH DATALNHVH

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling20 COCOMO II Implications Factors captured by local calibration of COCOMO constants A and B: –Security and Information assurance (given complexity is at least high) Very Easy would have no security or information assurance requirements Very Challenging would require the software to authenticate access, handle denial of service attacks, ensure data integrity, etc. –Components or Sub-system Interactions Heterogeneous components require special interfaces to communicate with each other Homogeneous components are generally built with similar communication interface

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling21 COCOMO II Implications COCOMO Parameters not addressed: –Development Flexibility –Team Cohesion –Process Maturity –Developed for Reuse –Analyst Capability –Programmer Capability –Personnel Continuity –Applications Experience –Platform Experience –Language and Tool Experience –Use of Software Tools –Multi-Site Development These are usually driven by business decisions May be indirectly driven by Difficulty or Context

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling22 Next Steps The proposed approach to classifying software application productivities by Operational Context and Application Difficulties needs to be verified with the government agencies and industrial communities that will use the approach for software project cost estimates. –Hold workshops and working groups to fill in ratings for operational context and application difficulties. –Test approach by soliciting characterizations of applications and determining where their applications fit in the productivity group matrix –Analyze project cost data for productivity: each project will be characterized by Operational Context and Application Difficulties

University of Southern California Center for Systems and Software Engineering 24th International Forum on COCOMO and Systems/Software Cost Modeling23 Questions? For more information, contact: Thomas Tan