Object oriented analysis and

design
Module 6: Best practices of Software
Engineering
 Objectives: Best Practices
• Identify symptoms of software
development problems.
• Explain the Best Practices.
• Present the Rational Unified Process
(RUP) within the context of the Best
Practices.
 Symptoms of Software
Development Problems

User or business needs not met

Requirements not addressed

Modules not integrating

Difficulties with maintenance

Late discovery of flaws

Poor quality of end-user experience

Poor performance under load

No coordinated team effort

Build-and-release issues
Trace Symptoms to Root Causes
Symptoms Root Causes Best Practices
Needs not met Insufficient requirements Develop Iteratively
Requirements churn Ambiguous communications
Modules do notfitfit
don’t Brittle architectures Manage Requirements
Hard to maintain Overwhelming complexity
Use Component Architectures
Late discovery Undetected inconsistencies
Poor quality Poor testing
Model Visually (UML)
Poor performance Subjective assessment
Colliding developers Waterfall development Continuously Verify Quality
Build-and-release Uncontrolled change
Insufficient automation Manage Change
 Best Practices Reinforce Each Other

Best Practices
Develop Iteratively

Manage Requirements Ensures users are involved

as requirements evolve

Use Component Architectures Validates architectural

decisions early on
Addresses complexity of
Model Visually (UML) design/implementation incrementally

Continuously Verify Quality Measures quality early and often

Evolves baselines incrementally

Manage Change
 Develop Iteratively
• Iterative development produces an executable

3. Requirements
4. Analysis & Design
2. Planning
1. Initial
Management 5. Implementation
Planning
Environment
(on-going)
6. Test
8. Evaluation

7. Deployment
Each iteration
results in an
executable release
 Managing Requirements
Ensures that you
– solve the right problem
– build the right system
by taking a systematic approach to
– eliciting
– organizing
– documenting
– managing
the changing requirements of a software
application.
 Use Component Architectures

• Software architecture needs to be:

Component-based Resilient
– Reuse or customize – Meets current and
components future requirements
– Select from – Improves extensibility
commercially available – Enables reuse
components – Encapsulates system
– Evolve existing software dependencies
incrementally
 Purpose of a Component-Based
Architecture
• Basis for reuse
– Component reuse Application-
specific
– Architecture reuse
• Basis for project
Business-
management specific

– Planning
– Staffing
Middleware
– Delivery
• Intellectual control
System-
– Manage complexity software
– Maintain integrity
 Model Visually (UML)
• Captures structure and behavior
• Shows how system elements fit together
• Keeps design and implementation
consistent
• Hides or exposes details as appropriate
• Promotes unambiguous communication
– The UML provides one language for all
practitioners.
Visual Modeling with the Unified
Modeling Language
Static
Diagrams
Class
Use-Case Diagrams
Sequence Diagrams Object
Diagrams Diagrams

Communication Component
Diagrams Models
Diagrams

State Machine Deployment

Diagrams Diagrams
Activity
Diagrams
 Continuously Verify Quality
Software problems are
100 to 1000 times more costly
to find and repair after deployment

 Cost to Repair Software

Cost  Cost of Lost Opportunities
 Cost of Lost Customers

Inception Elaboration Construction Transition

 Testing Dimensions of Quality
Usability
 Test application
from the perspective
of convenience to the
end user.

Functionality Reliability
 Test the accurate
workings of each
usage scenario.

Supportability Performance
 Test the ability to  Test the online response
maintain and support the under average and
application under peak loading.
production use.
 Manage Change
• To avoid confusion, have:
– Secure workspaces for each developer
– Automated integration/build management
– Parallel development

Workspace
Management

Process Parallel
Integration Development

Build
Management
 Manage Change (continued)
• Unified Change Management (UCM) involves:
– Management across the lifecycle
• System
• Project management
– Activity-based management
• Tasks
• Defects
• Enhancements
– Progress tracking
• Charts
• Reports
 Rational Unified Process
Implements Best Practices
Best Practices
Process Made Practical

Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually (UML)

Continuously Verify Quality

Manage Change
 Achieving Best Practices
• Iterative approach
• Guidance for activities
and artifacts
• Process focus on
architecture
• Use cases that drive
design and
implementation
• Models that abstract
the system
 A Team-Based Definition of
Process
A process defines Who is doing What, When, and
How, in order to reach a certain goal.

New or changed Software Engineering New or changed

requirements Process system
 Process Structure - Lifecycle
Phases
The Rational Unified Process has four phases:
– Inception – Define the scope of the project
– Elaboration – Plan the project; specify features and
baseline architecture
– Construction – Build the product
– Transition – Transition the product into the end-user
community

Inception Elaboration Construction Transition

Time
 Bringing It All Together: The
Iterative Approach
In an
iteration,
you walk
through all
disciplines.

Disciplines
group
activities
logically.
 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.
• The Rational Unified Process is a means
of achieving Best Practices.