Evolving Software Development ToolsTechniques

1
Evolving Software Development Tools/Techniques

• Case
• Reuse
• Object Oriented

2
Architecture of CASE
Form Report Generators
Diagramming Facilities
Quality Assurance Facilities
Project Information Facilities
Documentation Facilities
Repository
Code Generators
Standard Libraries
3
Outstanding Issues with CASE

• Who is really using CASE?
• How is CASE being used?
• What are the intended and unintended impacts of
  CASE?
• Why havent expectations been met?
• Can CASE be used in place of a systems
  development life cycle and methodology?

4
Motivation for Software Reuse

• The practice of using existing software assets to
  develop new applications
• Software assets
• Executable programs and software tools
• Code segments
• Documentation
• Requirements, designs, and architectures
• Test data and test plans
• Knowledge and information

5
Why Software Reuse?

• Reduce cost of software development
• Increase productivity of software developers
• Increase reliability of software
• Shorten software development time and time to
  market

6
Costs Associated with Software Reuse

• Costs of resources required to create and
  maintain reusable assets
• Cost of a reuse library
• Costs of resources required to create and
  maintain tools in support of software reuse
• Costs to reuse assets

7
Integrating Reuse with Software Development
Business Objectives
Domain Knowledge
Software Development Support Tools/Resources
Produces
Domain Engineering
Feedback (Customer and Process Needs)
Is used By
Produces
Software Development
Product
Customer
Consumes
Presents Requirements to
8
Technology Supporting Software Reuse

• Application Generators
• Automatic Programming
• Component-Based and Architecture-Based Reuse
  Libraries
• Domain Analysis and Engineering
• Domain-Specific Kits
• Re-engineering and Reverse Engineering
• Quantification of Reuse Potential and Measurement
  of Reuse Effectiveness
• Computer Languages

9
Reuse Assets Key Concerns

• Portability issues
• Maintainability issues
• Assets must be qualified and certified
• Qualification determining if an artifact is
  appropriate for the domain
• Certification determining if an artifact meets
  the quality standards and passes all testing
  procedures

10
Encouraging Software Reuse

• Incorporate software reuse practices into the
  software development process
• Train and educate employees on software reuse
• Develop and prove tools to practice software
  reuse
• Allocate the proper funds and resources to
  support a reuse program
• However
• Management is generally short-sighted in their
  view on software development and is often not
  willing to commit resources to acquire needed
  tools and training in software reuse technology
• Benefits of software reuse are not quickly
  realized and are uncertain

11
Inhibiting Software Reuse

• Project Managers
• Are often pushed by limited funds and tight
  schedules
• Have little incentive to allocate additional time
  and resources needed to develop reusable software
• Software Developers
• Are often reluctant to accept and use reusable
  assets for fear that the assets will not be as
  efficient, effective, or reliable as the software
  they write
• Have to understand and adapt reusable assets to
  meet the specific needs of a software system

12
Making Reuse Cost-Effective (Barnes/Bollinger)

• Broad definition of reuse - reuse of human
  problem solving
• Reuse costly maximize ratio of benefits to costs
• Increase level of reuse
• Build parts on local expertise buy for outside
  expertise
• Analyze likely variants
• Decrease average cost of reuse
• Costs Finding, adapting, integrating, and
  testing
• Decrease investment necessary to achieve benefit
• Match generality to needs
• Reuse strategies
• Adaptive reuse - large structures, small changes
  (e.g., parameterization)
• Compositional reuse - small invariant parts,
  significant investment

13
Effects of Reuse (Lim)

• What was done
• Quantitative case study of two reuse programs at
  Hewlett-Packard
• Results
• Both sites have documented productivity gains of
  40-57
• Both sites had documented defect reduction of
  24-51
• Cost to create reusable versions 111 of normal
  (vs. 120-480 from literature)
• ROI estimates from 216-410 Breakeven estimates
  from 2-6 years
• Caveats
• Data presented at relatively high level, details
  on estimates, variances not provided
• Little discussion on what management practices
  were followed to achieve benefits
• Managerial Notions
• Gains from reuse are real and measurable
• Reuse not free needs to be viewed as a long-term
  investment and managed

14
Reuse and Productivity (Banker/Kauffman)

• What was done
• Field study of 20 projects developed with an
  I-CASE tool over two years
• Measured development productivity using Function
  Points
• Development of a model of productivity impacts of
  reuse via I-CASE
• Results
• Documented high rates of Function Points delivery
  via the I-CASE tool
• Statistically significant impact of re-use on
  productivity
• Documented gains over time
• Caveats
• Statistical results somewhat weak
• Managerial Notions
• Provides metric for re-use
• Documents the longitudinal nature of gains from
  new software process technologies

15
What is an Object? Informal Definition

• An object is an integral entity which can
• change state and relate to other objects
• behave in certain discernible ways
• be manipulated by various forms of stimuli
• Objects
• exist, occupy space, and assume a state
• possess attributes
• exhibit behaviors

16
What is an Object? Formal Definition

• Object Concept - objects have a permanence
  identity apart from any operation on them
• Object - an entity which has state, behavior,
  and identity the structure and behavior of
  similar objects are defined in their common
  class the terms instance and object are
  interchangeable
• State of an object - encompasses all of the
  (usually static) properties of the object plus
  the current (usually dynamic) values of each of
  these properties
• Property or attribute of an object - a part of
  the state of the object which is an inherent or
  distinctive characteristic, trait, quality, or
  feature that contributes to making an object
  uniquely that object

17
Examples of Non-Objects

• Attributes, such as time, beauty, or color
• Emotions, such as love or anger
• Entities which are normally objects but are,
  instead, thought of as attributes of objects when
  a particular problem space is considered

18
Operations on Objects

• Modifier - an operation that alters the state of
  an object, such as a put operation
• Selector - an operation that accesses the state
  of an object, but does not alter the state, such
  as a get operation
• Iterator - an operation that permits all parts of
  an object to be accessed in some well-defined
  order, such as movement through a linked list
• Constructor - an operation that creates and
  object and/or initializes its state
• Destructor - an operation that frees the state of
  an object and/or destroys the object itself

19
What is a Class

• Class - a set of objects that share a common
  structure and a common behavior
• A class represents only an abstraction
• An object, an instance of a class, is a concrete
  entity that exists in time and space
• The class captures the structure and behavior
  common to all related objects, serving as a
  binding contract between an abstraction and all
  of its clients.
• Strongly typed programming languages can detect
  violations of the contract that is a class during
  compilation.

20
Object-Oriented Analysis Design

• Object-Oriented Analysis (OOA) is
• A method of analysis of a problem
• Examines requirements from the perspective of the
  classes and objects found in the vocabulary of
  the problem domain
• OOA products
• Identification of classes and objects
• Data dictionary
• Object-Oriented Design (OOD)
• Is a method of design
• Encompasses a process of object-oriented
  decomposition
• Employs a notation for depicting
• Logical and physical models of the system
• Static and dynamic models of the system

21
Object-Oriented Methodologies

• There are many methodologies for performing OOA
  and OOD
• Each methodology has its pluses and minuses
• It is good to look at a variety of methodologies
  and then define your own that fits your resources
  and capabilities
• Generic Methodology
• Look for reusable architectures and
  classes/objects
• Plan the design
• Invent the new classes/objects and continue
  exploiting reuse
• I mplement and test the new classes/objects
• Integration and final testing

22
Software Cost Estimation

• What is the Problem?
• 100 - 200 cost overruns are not uncommon
• 15of large projects never deliver anything

• What are the consequences?
• Economic
• Technical
• Managerial

• What is gained through effective software
  cost-estimation?
• schedule/staffing estimates
• better understanding of a particular project

23
Why are we bad at estimation?

• Complexity
• Infrequency
• Uniqueness
• Underestimation bias
• Goals not estimates

24
Basic Steps in Software Estimation

• Identify project objectives and requirements
• Plan the activities
• Estimate product size and complexity
• Estimate effort, cost and resources
• Develop projected schedule
• Compare and iterate estimates
• Follow up

25
Software Cost-Estimation Methods

• algorithmic
• expert judgement
• similar, completed projects
• equate to available resources
• Price-to-win
• Top-down (global estimate)
• Bottom-up (each component separately estimated)

26
Algorithmic Models

COCOMO TRW (Boehm) ESTIMACS
Computer Associates (Rubin) ESTIPLAN
AGS Management Systems FAST
Freiman Parametric Systems (Freiman) FUNCTION
IBM (Albrecht) POINTS MAINSTAY
Mainstay Software Corporation PRICE
RCA SLIM QSM (Putnam)
SOFTCOST-R Reifer Consultants (Tausworthe)
SPQR Software Productivity
Research (Jones)
27
"A Meta-model for Software Development Resource
Expenditures"( Bailey and Basili, 1981)

• What was Done
• Development of generic cost estimation model
  using NASA data
• Nature of Data
• NASA, two - ten programmers, six-ten man-years
• Approach
• choice of size metrics -- used developed lines
  new lines 20 of re-used lines
• functional form of best model E aDLb c
  (exponential)
• improve fit through additional variables
• Caveat -- small sample size
• Managerial Notions
• Immature state of the art
• Need for data from past projects to
  build/calibrate models
• calibrate to each different environment -- why??

28
Project Attributes
Methodology
Complexity
Experience

• Tree Charts
• Top Down Design
• Design Formalisms
• Formal Documentation
• Code Reading
• Chief Programmer Team
• Formal Test Plans
• Unit Development Folders
• Formal Training

• Interface Complexity
• Client-Initiated Design Changes
• Application Process Complexity
• Program Flow Complexity
• Internal Communication Complexity
• External Communication Complexity
• Data Base Complexity

• Programmer Qualifications
• Programmer Experience with Machine
• Programmer Experience with Language
• Programmer Experience with Application
• Team Previously Worked Together

29
"Software Engineering Economics" ( Boehm, 1984)

• What was done
• Development of cost and schedule estimation
  models ("COCOMO")
• Notion of project "modes" (Organic,
  Semi-detached, Embedded)
• Approach
• nominal development effort is estimated
• effort multipliers obtained from 15 cost drivers
  and applied
• schedule (time) then estimated from adjusted
  effort
• Results - Basic Model
• Org. Effort 2.4 (KDSI)1.05 Time2.5
  (Effort) 0.38
• Semi. Effort 3.0 (KDSI)1.12 Time2.5
  (Effort) 0.35
• Emb. Effort 3.6 (KDSI)1.20 Time2.5
  (Effort) 0.32
• Caveats
• Estimates within a factor of 1.3 29 of time,
  factor of 2 60 of time
• Managerial Notions
• Very widely used model in industry
• Data driven exercise widely customized

30
Cost Drivers

• Required software reliability
• data base size
• product complexity
• computer execution time constraint
• computer storage constraint
• computer turnaround time
• analyst capability
• programmer capability
• application experience
• hardware/software experience
• programming language experience
• use of modern programming practices
• use of software tools
• required development schedule

31
Kemerer, 1987
Data national consulting firm
15 completed DP systems
COBOL 200,000 source
lines of code (avg.)
32
Kemerer Results
Method Error Correlation

• SLIM 772 .94
• COCOMO 608 .84
• ESTIMACS 85 .49
• FUNC PTS 103 .76

33
Kemerer, 1987

• What do these results suggest?
• Models can do a good job
• Calibration is essential
• Environment is very important
• What further work is needed?
• Confirm on another sample
• Metric before/after tests
• Better models of productivity

34
How the Expert Systems Works

• Expert System Components
• database of historical projects
• adjustment rule base
• analog retrieval reasoning
• Process
• input current project
• locate similar project and use its actuals as a
  base
• adjust base via ruleset and project attribute
  differences between current and similar projects

35
Model Structure
turnover rate
hiring rate
workforce experience
workforce
process losses
potential productivity
error detection and correction
software development rate
actual productivity
QA effort
error rate
perceived productivity
learning
schedule pressure
perceived tasks complete
scheduled completion date
accuracy in measuring progress
perceived workforce level
perceived effort needed
forecast completion date
adjustments to workforce schedule
perceived project size
36
Main Problems to be Solved

• providing sound sizing estimates (use of
  function points?)
• external input types
• external output types
• logical internal files types
• external interface file types
• external inquiry types
• understanding effects of software cost drivers
• representing internal dynamics of a software
  project
• collecting required data
• predicting future projects rather than explaining
  historical projects

37
How can firms improve their cost estimation?
Metrics/Special Studies Team

• Roles
• Collect/Disseminate project data
• Calibrate/Develop cost models
• Evaluate new technologies
• Assist/Train project managers
• Build reusable code libraries
• Goals
• Measurably improve productivity
• Measurably improve software quality and
  reliability

38
CASE and the SDLC
Planning
Analysis
Design
Coding
Support
planning schedules enterprise data model
CASE Workstation
39
CASE and the SDLC
Planning
Analysis
Design
Coding
Support
entity relationship diagrams data flow
diagrams functional hierarchy diagrams
CASE Workstation
40
CASE and the SDLC
Planning
Analysis
Design
Support
Coding
normalized data model report user interface
designs structure charts
CASE Workstation
41
CASE and the SDLC
Planning
Analysis
Design
Support
Coding
code generation
CASE Workstation
42
CASE and the SDLC
Planning
Analysis
Design
Support
Coding
version control specification changes
CASE Workstation