Database Design Approaches

The Waterfall vs. Iterative Methodologies

Traditional Systems Development Lifecycle (“The Waterfall Model”)

PlanningPlanning

Traditional Systems Development Lifecycle (“The Waterfall Model”)

PlanningPlanning

AnalysisAnalysis

Traditional Systems Development Lifecycle (“The Waterfall Model”)

PlanningPlanning

AnalysisAnalysis

Logical Logical DesignDesign

Traditional Systems Development Lifecycle (“The Waterfall Model”)

PlanningPlanning

AnalysisAnalysis

Logical Logical DesignDesign

PhysicalPhysicalDesignDesign

Traditional Systems Development Lifecycle (“The Waterfall Model”)

PlanningPlanning

AnalysisAnalysis

Logical Logical DesignDesign

PhysicalPhysicalDesignDesign

ImplementationImplementation

Database Development Process

PlanningPlanning

AnalysisAnalysis

Logical Logical DesignDesign

PhysicalPhysicalDesignDesign

ImplementationImplementation

enterprise data enterprise data modelmodel

Database Development Process

PlanningPlanning

AnalysisAnalysis

Logical Logical DesignDesign

PhysicalPhysicalDesignDesign

ImplementationImplementation

enterprise data enterprise data modelmodel

conceptual data conceptual data modelmodel

Database Development Process

PlanningPlanning

AnalysisAnalysis

Logical Logical DesignDesign

PhysicalPhysicalDesignDesign

ImplementationImplementation

enterprise data enterprise data modelmodel

conceptual data conceptual data modelmodel

logical data logical data modelmodel

Database Development Process

PlanningPlanning

AnalysisAnalysis

Logical Logical DesignDesign

PhysicalPhysicalDesignDesign

ImplementationImplementation

enterprise data enterprise data modelmodel

conceptual data conceptual data modelmodel

logical data logical data modelmodel

technology technology modelmodel

Database Development Process

PlanningPlanning

AnalysisAnalysis

Logical Logical DesignDesign

PhysicalPhysicalDesignDesign

ImplementationImplementation

enterprise data enterprise data modelmodel

conceptual data conceptual data modelmodel

logical data logical data modelmodel

technologytechnologymodelmodel

databases and databases and repositoriesrepositories

Rational Unified Process

Why do so many projects fail?

• Characteristics of failed projects– Inaccurate understanding of end-user needs– Inability to deal with changing environments– Late discovery of serious project flaws– Poor software quality– Modules that do not fit together– Unacceptable software performance

• These are just symptoms of deeper underlying problems

Root Causes for Project Failure

• Ad hoc requirements management• Ambiguous and imprecise communication• Overwhelming complexity• Insufficient testing• Subjective assessment of project status• Uncontrolled change propagation• Insufficient automation

Software Development: Best Practices

1. Develop software iteratively2. Manage requirements3. Use component-based architectures4. Visually model software5. Continuously verify software quality6. Control changes to software

1. Develop Software Iteratively

Planning

Analysis

Logical Design

PhysicalDesign

Implementation

The “classic” waterfall The “classic” waterfall lifecyclelifecycle

1. Develop Software Iteratively

Planning

Analysis

Logical Design

PhysicalDesign

Implementation

Risk

Time

Risk pushed forward in time

Iterative ApproachIterative Approach

Planning RequirementsRequirements

Analysis and DesignAnalysis and Design

ImplementationImplementation

DeploymentDeployment

TestTest

EvaluationEvaluation

InitialPlanning

-continuous discovery and implementation--each iteration results in an executable

Advantages of the iterative process• Misunderstandings made evident early• Encourages user feedback• Continuous testing allows objective status

assessment• Inconsistencies between analysis, design, and

implementation detected early• Workload spread evenly (especially testing)

2. Manage Requirements

• Requirements are conditions or capabilities that a system must meet

• Requirements of a system are dynamic• Identifying a system’s requirements is a continuous

process• Impossible to exhaustively state a systems

requirements before start of development• Managing requirements involves

– Eliciting, organizing, documenting requirements– Evaluating changes to requirements– Tracking and documenting trade-offs and decisions

3. Use Component-based architecture• Many people are involved in the development of a

system– End users, analysts, developers, testers, technical writers,

project managers…• Each stakeholder views the system in a different way

during the course of a project• System architecture allows management of views• Architecture covers structure and behavior of

software elements, usage, functionality, performance, reuse, aesthetics, etc.

Component-based development (CBD)

• Allows reuse and customization of components from thousands of available sources

• Can use new, existing, or third-party components and strap them together to achieve desired functionality

• In an iterative approach, each cycle produces an executable architecture– Can be measured, tested, evaluated against requirements– Allows developers to attack risks continuously

Advantages of CBD architectures

• Components facilitate strong and flexible architectures

• Modularity enables separation of elements that are subject to change

• Components provide a natural basis for configuration management

• Visual modeling tools can be used for automation

4. Visually Model Software

• A model is a simplification of reality that describes system from specific perspective

• Models help teams visualize, specify, construct, and document system

• Improves ability to manage system complexity• Communication is improved through the use of a

common modeling language (such as UML)

Viewing a system from different perspectives

ModelModel

Scenario Diagrams

State Diagrams

Deployment Diagrams

Component DiagramsUse Case

Diagrams

Class Diagrams

Advantages of Visual Modeling

• Use-cases and scenarios clearly specify system behavior

• Inflexible architectures quickly exposed• Detail can be hidden when necessary• Unambiguous designs show inconsistencies

easily• Visual Modeling tools support UML

5. Continuously verify software quality

Cost

Time

- Software problems can be thousands of Software problems can be thousands of times times more expensivemore expensive to find and repair to find and repair afterafter deployment than if discovered earlier in the deployment than if discovered earlier in the projectproject

Testing and Quality

• Testing involves– Creating tests for systems key scenarios– Assessing functionality by asking which scenarios

failed– Testing at every iteration, continuously improving

quality

6. Control Changes to Software

• Complex systems typically involve– Multiple developers– Multiple teams– Multiple sites– Multiple releases, platforms, and products

• Can quickly degenerate into chaos

To control changes…

• Must establish repeatable workflow for managing changes

• A tested baseline is released at the end of every iteration

• By developing iteratively, the process of change control is continuous and traceable

Advantages of Formal Change Control

• Change requests facilitate unambiguous communication

• Change rate statistics are good metric for project status

• Change propagation is controlled• All outputs are in a single location – provides

for consistency

So…..

• Guide the order of a team’s activities• Specify which artifacts (deliverables) must

be produced and when they must be produced

• Direct activities of both individuals and teams

• Monitor and measure project activities

Any software development process must:

The Rational Unified Process

- software development process that attempts to ensure quality systems

developed in a repeatable and predictable way

RUPRUP