Infowave OOAD 01 BestPractices

Objectives: Best Practices
• Identify symptoms of software development problems.

• Explain the six Best Practices.
Object-Oriented Analysis and Design • Present the Rational Unified Process (RUP) within the
context of the Best Practices.
for RUP and OpenUP
1. Best Practices of Software Engineering
Pongsatorn P. Sukhum
Infowave (Thailand) Co., Ltd.
Copyright © 1995-2010 Infowave (Thailand) Co., Ltd.

All Rights Reserved.
Symptoms of Software Development Problems
9 User or business needs not met

9 Requirements not addressed
9 Modules not integrating
9 Difficulties with maintenance
9 Late discovery of flaws
9 Poor quality of end-user experience
9 Poor performance under load
9 No coordinated team effort
9 Build-and-release issues
Copyright © 1995-2010 Infowave (Thailand) Co., Ltd. Copyright © 1995-2010 Infowave (Thailand) Co., Ltd.
All Rights Reserved. All Rights Reserved.
Trace Symptoms to Root Causes
Symptoms Root Causes Best Practices

“The complexity of the problems being addressed by Insufficient requirements
software is growing more rapidly than our ability to Needs not met
Develop Iteratively
Ambiguous communications
develop and maintain the software” Requirements churn
Brittle architectures Manage Requirements
Modules do not fit
- Mark Paulk, SEI. Hard to maintain

Overwhelming complexity Use Component Architectures
Late discovery Undetected inconsistencies Model Visually (UML)
Poor quality Poor testing

Continuously Verify Quality
Poor performance Subjective assessment

Manage Change
Colliding developers Waterfall development
Build-and-release
Uncontrolled change
Insufficient automation
1
Six Best Practices Develop Iteratively
• Iterative development produces an executable
Develop Iteratively 3. Requirements

4. Analysis & Design
Manage Requirements
2. Planning
Use Component Architectures 1. Initial
Management 5. Implementation
Planning
Model Visually (UML) Environment
(on-going)
Continuously Verify Quality 6. Test
Manage Change 8. Evaluation
7. Deployment
Each iteration results
in an executable
release
Risk Profiles Managing Requirements
• Ensures that you

– solve the right problem
– build the right system
Waterfall Risk
by taking a systematic approach to
– eliciting
Risk
Risk Reduction – organizing

– documenting
– managing
Iterative Risk
the changing requirements of a
software application.
Time
Use Component Architectures Purpose of a Component-Based Architecture
• Basis for reuse

– Component reuse
Component-based Resilient
– Architecture reuse
– Reuse or customize components – Meets current and future • Basis for project management Component-based
– Select from commercially requirements – Planning architecture with
available components – Improves extensibility – Staffing layers
– Evolve existing software – Enables reuse – Delivery
incrementally – Encapsulates system • Intellectual control Application-
specific
dependencies – Manage complexity
– Maintain integrity Business-
specific
Middleware
System-
software
2
Model Visually (UML) Visual Modeling with the UML
Static
• Captures structure and behavior Diagrams
• Shows how system elements fit together Use-Case Class
Diagrams Diagrams
• Keeps design and implementation consistent Sequence Object
Diagrams Diagrams
• Hides or exposes details as appropriate
• Promotes unambiguous communication Dynamic
– The UML provides one language for all practitioners. Diagrams
Communication Component
Models Diagrams
Diagrams
Composite
State Machine Structure
Diagrams Diagrams
Activity Deployment
Diagrams Diagrams
Continuously Verify Quality Testing Dimensions

FURPS+ Usability
Test application from the
perspective of
Functionality convenience to end-user.
Test the accurate
workings of each
usage scenario Reliability
Cost
Cost
Test the application
Also known as the behaves consistently and
1-10-100 Rule Supportability
predictably.
Test the ability to maintain

and support application
under production use Performance
Inception Elaboration Construction Transition Test online response
under average and peak
loading
Manage Change
• To avoid confusion, have:

– Secure workspaces for each developer
– Automated integration/build management
– Parallel development
Workspace
Management
Methodology = Process + Notation
Process Parallel
Configuration Management Integration Development
is more than just check-
in and check-out Build
Management
3
A Team-Based Definition of Process Rational Unified Process
A process defines Who is doing What, When, and How, Affectionately known as the
“Hump Chart” because it
in order to reach a certain goal.
looks like migrating humpback
whales
New or changed Software Engineering New or changed

requirements Process system
Process Structure - Lifecycle Phases An Iterative Approach

The Rational Unified Process has four phases: In an Iteration,
– Inception – Define the scope of the project you walk through
– Elaboration – Plan the project; specify features and baseline architecture all workflows
– Construction – Build the product
– Transition – Transition the product into the end-user community Disciplines define
the workflow
Inception Elaboration Construction Transition
Time
Lifecycle Lifecycle Initial Operational Product

Objective Architecture Capability Release
Milestone Milestone Milestone (PR)
(LCO) (LCA) (IOC)
General Availability
Copyright © 1995-2010 Infowave (Thailand) Co., Ltd.
(GA) Copyright © 1995-2010 Infowave (Thailand) Co., Ltd.
Summary
• Best Practices guide software engineering by addressing

root causes.
• Best Practices reinforce each other.
• Process guides a team on who does what, when, and
how. Questions ?
• The Rational Unified Process is a means of achieving Best
Practices.

Infowave OOAD 01 BestPractices

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Infowave OOAD 01 BestPractices

Diunggah oleh

Hak Cipta:

Format Tersedia

Objectives: Best Practices

• Identify symptoms of software development problems.

Copyright © 1995-2010 Infowave (Thailand) Co., Ltd.

Symptoms of Software Development Problems

9 User or business needs not met

Trace Symptoms to Root Causes

Symptoms Root Causes Best Practices

- Mark Paulk, SEI. Hard to maintain

Late discovery Undetected inconsistencies Model Visually (UML)

Poor quality Poor testing

Poor performance Subjective assessment

• Iterative development produces an executable

Develop Iteratively 3. Requirements

Risk Profiles Managing Requirements

• Ensures that you

Risk Reduction – organizing

Use Component Architectures Purpose of a Component-Based Architecture

• Basis for reuse

Continuously Verify Quality Testing Dimensions

 Test the ability to maintain

• To avoid confusion, have:

New or changed Software Engineering New or changed

Process Structure - Lifecycle Phases An Iterative Approach

Lifecycle Lifecycle Initial Operational Product

• Best Practices guide software engineering by addressing

Anda mungkin juga menyukai

Test the ability to maintain