Vous êtes sur la page 1sur 35

Database Design Approaches

The Waterfall vs. Iterative Methodologies

Traditional Systems Development Lifecycle (The Waterfall Model)


Planning

Traditional Systems Development Lifecycle (The Waterfall Model)


Planning

Analysis

Traditional Systems Development Lifecycle (The Waterfall Model)


Planning

Analysis Logical Design

Traditional Systems Development Lifecycle (The Waterfall Model)


Planning

Analysis Logical Design

Physical Design

Traditional Systems Development Lifecycle (The Waterfall Model)


Planning

Analysis Logical Design

Physical Design

Implementation

Database Development Process


Planning

Analysis
enterprise data model

Logical Design

Physical Design

Implementation

Database Development Process


Planning

Analysis
enterprise data model conceptual data model

Logical Design

Physical Design

Implementation

Database Development Process


Planning

Analysis
enterprise data model conceptual data model

Logical Design

logical data model

Physical Design

Implementation

Database Development Process


Planning

Analysis
enterprise data model conceptual data model

Logical Design

logical data model

Physical Design

Implementation
technology model

Database Development Process


Planning

Analysis
enterprise data model conceptual data model

Logical Design
databases and repositories

logical data model

Physical Design

Implementation
technology model

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. 2. 3. 4. 5. 6. Develop software iteratively Manage requirements Use component-based architectures Visually model software Continuously verify software quality Control changes to software

1. Develop Software Iteratively


Planning
The classic waterfall lifecycle Analysis Logical Design

Physical Design

Implementation

1. Develop Software Iteratively


Planning

Analysis Logical Design

Risk pushed forward in time

Physical Design

Implementation

Time

Iterative Approach
Initial Planning Planning Requirements

Analysis and Design

Evaluation

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

Implementation

Deployment Test

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 systems 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


Class Diagrams

Scenario Diagrams Model

State Diagrams

Deployment Diagrams

Use Case Diagrams

Component 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


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

Time

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..

Any software development process must:


Guide the order of a teams 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

The Rational Unified Process


- software development process that attempts to ensure quality systems developed in a repeatable and predictable way

RUP

Vous aimerez peut-être aussi