slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Software Model Clashes Identification USC-CSE Annual Research Review Mohammed Al-Said PowerPoint Presentation
Download Presentation
Software Model Clashes Identification USC-CSE Annual Research Review Mohammed Al-Said

Loading in 2 Seconds...

play fullscreen
1 / 24

Software Model Clashes Identification USC-CSE Annual Research Review Mohammed Al-Said - PowerPoint PPT Presentation


  • 185 Views
  • Uploaded on

Software Model Clashes Identification USC-CSE Annual Research Review Mohammed Al-Said. Models and Modeling. Software System. Model (Webster): A description or analogy used to help visualize or analyze something; a pattern of something to be made

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Model Clashes Identification USC-CSE Annual Research Review Mohammed Al-Said' - dominique


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Software Model Clashes Identification

USC-CSE Annual Research Review

Mohammed Al-Said

models and modeling
Models and Modeling

Software System

  • Model (Webster):
  • A description or analogy used to help visualize or analyze something; a pattern of something to be made
  • For us is representation of an aspect of software development based on a set of assumptions
  • Models may use other models as part of their assumptions (e.g.., COCOMO uses multiplicativeregression, WinWin uses Theory W)
slide3

SoftwareModels

Success Models

  • Win-Win • Business Case Analysis
  • Software Warranties • QFD
  • 10X • Six Sigma
  • Award Fees . IKIWISI
  • JAD

Product

Models

Process

Models

          • UML
      • CORBA •COM
  • Requirements
  • Architectures
    • Product Lines
  • OO Analysis & Design
    • Domain Ontologies
      • COTS • GOTS
  • Spiral
  • Waterfall
  • Open Source
  • Business Process Reengineering
  • CMM’s • Peopleware
  • IPT’s • Agile
  • Evolutionary
          • COCOMO
        • COCOTS
        • Checkpoint
  • System Dynamics . Metrics . ilities
  • Simulation and Modeling . Environment

Property Models

assumptions and models
Assumptions and Models

Assumption:A statement that is taken for granted as “true”

Example: COCOMO cost drivers are multiplicative

Model:a consistent set of assumptions and their logical derivations that represent a viewpoint

Example: COCOMO represents the effort “viewpoint” of a project. It has another assumption that states effort is proportional to (SIZE)E. Hence the logical “AND” implies that effort is proportional to the cost drivers AND (SIZE)E

Note:these assumptions are only taken to be true with respect to the COCOMO model itself

slide5
Model-Clash:

An incompatibility among the assumptions of a set of models

Example:

IKIWISI (I’ll know it when I see it) success model assumes requirements are generated after something is implemented (prototype)

Waterfall process model assumes nothing is implemented until requirements are specified.

There is no model in which both of above statements are consistent (there is at least an implementation or a requirement that can not satisfy both)

  • Yet many projects embrace both models and get into trouble
    • Need techniques to identify and avoid model clashes
    • USC-CSE MBASE approach one way to do this
example london ambulance service
Example: London Ambulance Service
  • Year: 1991
  • a computer system to replace the entiremanual system for scheduling of ambulances for 999 calls
  • time scale 12 months
  • intended budget of $2.2 million
  • Complex problem:
    • 300 ambulances
    • >400 patient transport service vehicles
    • >326 paramedics
    • 1,300 - 1,600 emergency calls per day
example london ambulance service1
Example: London Ambulance Service
  • LAS required a system able to support:
    • input & verification of call and incident details,
    • selection of most suitable ambulances,
    • communication of incident details to selected ambulances, and
    • forward planning to place vehicles and staff at positions where they are most likely to be required.
assumptions coverage
Assumptions Coverage

Testing&Tran.

Organizations

Requirements

Environment

Maintenance

Architecture

Project Size

Developer

Customer

Change

slide17

Assumptions Coverage

Testing&Tran.

Organizations

Requirements

Environment

Maintenance

Architecture

Project Size

Developer

Customer

Change

Document

Completeness

Knowability

Testability

Feasibility

Stability

Validity

Clarity

*Part based on SEI risk Taxonomy

slide18

Multi-Model Clashes Example

Waterfall

COTS

System requirements are fully specified prior to design and implementation stages

COTS capabilities determine many of the software system's requirements

COTS product capabilities may impose additional requirements on the system being developed

Requirements are sufficiently testable

The requirements’ nature will change little during development and evolution.

Much of requirements evolution are driven by COTS (even during development)

All design decisions are clearly justifiable

Schedule allows enough calendar months to progress sequentially

COTS vendor claims cannot be counted on as requirements

Minimum changes are introduced once each phase deliverables are approved

A COTS product’s internal architecture is not always visible to external developers

Interfaces to other software or hardware are completely defined

Results of original COTS testing process are not visible to external developers

COTS vendor is economically viable

COTS vendor is sufficiently responsive to requests for new features and improvements

COTS integration issues are not predictable in advance

slide19

Multi-Model Clashes Example

Waterfall

COTS

System requirements are fully specified prior to design and implementation stages

COTS capabilities determine many of the software system's requirements

COTS product capabilities may impose additional requirements on the system being developed

Requirements are sufficiently testable

The requirements’ nature will change little during development and evolution.

Much of requirements evolution are driven by COTS (even during development)

All design decisions are clearly justifiable

Schedule allows enough calendar months to progress sequentially

COTS vendor claims cannot be counted on as requirements

Minimum changes are introduced once each phase deliverables are approved

A COTS product’s internal architecture is not always visible to external developers

Interfaces to other software or hardware are completely defined

Results of original COTS testing process are not visible to external developers

COTS vendor is economically viable

COTS vendor is sufficiently responsive to requests for new features and improvements

COTS integration issues are not predictable in advance

Capabilities, conditions, and constraints for each requirement are clearly identifiable early in the development process

Full architecture analysis is performed with respect to the quality attributes of the system

System maintenance and operation are sufficiently feasible

High-Assurance

slide20

Business-Case

Fast time to market

Waterfall

COTS

System requirements are fully specified prior to design and implementation stages

COTS capabilities determine many of the software system's requirements

COTS product capabilities may impose additional requirements on the system being developed

Requirements are sufficiently testable

The requirements’ nature will change little during development and evolution.

Much of requirements evolution are driven by COTS (even during development)

All design decisions are clearly justifiable

Schedule allows enough calendar months to progress sequentially

COTS vendor claims cannot be counted on as requirements

Minimum changes are introduced once each phase deliverables are approved

A COTS product’s internal architecture is not always visible to external developers

Interfaces to other software or hardware are completely defined

Results of original COTS testing process are not visible to external developers

COTS vendor is economically viable

COTS vendor is sufficiently responsive to requests for new features and improvements

COTS integration issues are not predictable in advance

Capabilities, conditions, and constraints for each requirement are clearly identifiable early in the development process

Full architecture analysis is performed with respect to the quality attributes of the system

System maintenance and operation are sufficiently feasible

High-Assurance

requirements assumptions model clashes
Requirements Assumptions/Model Clashes
  • Models in left column will clash with models in right column
research contribution
Research Contribution
  • Assumptions and model-clashes of the most common software engineering models
  • An insight into model-clashes properties: (causes, patterns, relations)
  • Processes and visualization techniques for rapid model-clash identification
  • The relation between model-clashes and risk in software projects