Software Development

Best Practices
References
1. This the set of slides is majorly based on
the first module of the course material of
Rational University.
2. Philips Kruchten, The Rational Unified
Process, Pearson Education Asia, 2000.
A quote first
Software developers normally estimate
that they are 90% done, but it takes 90% to
get the rest of the way to 100% done.

In short, 90% done, 90% still remains.
Why This Session?
To provide a modern view of SD process
(approach, architecture, modeling etc.).
To investigate problems (symptoms), root causes
(diagnosis) and solutions (best practices) in team
SD process.
To address the issues related to risks, quality and
testing of the software product.
To have a prelude idea for Rational Unified
Process (RUP).


Objectives of a
Modern SD Process
Apply an iterative, use-case driven, architecture-
centric process to the development of a robust
design model.
Apply UML to represent the design model.
Apply the concepts of object orientation:
abstraction, encapsulation, inheritance and
polymorphism at design and implementation level.
Objectives (Cond..)
Understand the different views of a software
architecture, the key mechanism that are defined
in support of that architecture, and the effect of the
architecture and the mechanisms on the product
design.
Describe some basic design considerations,
including the use of the patterns.
Audience and Prerequisites
Audience
Software practitioners, Software Engineers,
Developers, Analysts, Senior Programmers,
Designers, Architects.
Prerequisites
Some exposure of Object Technology.
Some software development experience.

A Broad Perspective Ahead
Explore the symptoms and root causes of
software development problems.
Examine SIX best practices for software
development.
Apply these practices to address the root
causes of the problems.
Situation Analysis
World economies are becoming software
dependent (Should we put a big question mark
(?) today.
Applications are expanding in size, complexity,
distribution and importance.
Business is demanding increased productivity and
quality in less time and within budget.
Not enough qualified manpower is available.
A Challenging Scenario
Team sizes are increasing.
Specialization is growing (New Specific
Roles such as Performance Engineer & QA,
Integrator & Tester, Release Engineer etc.)
Rapid advancement in technology.
Distribution at large.

So, Scenario is
There are many software products under
use.
There are many software products under
development too.
There are too many projects underway,
some of them are at concept level, others
are verge of completion and some others are
under a middle state.
During the Development
There are many successes

During the Development
and,
There are too many failures too.

Symptoms for SD Problems
Inaccurate understanding of end-user needs.
Inability to deal with changing requirements.
Modules that dont fit together.
Software thats hard to maintain and/or extend.
Late discovery of serious project flaws.


Symptoms for SD Problems
(Contd.)
Poor software quality.
Unacceptable software performance.
Team members in each others way are unable to
reconstruct who changed what, when, where, why.
An untrustworthy build-and-release process.

Unfortunately, What happens is-
Treating symptoms does not treat the disease, e.g.
Late discovery of serious project flaws is only a
symptom of larger problems.
We have to diagnose for the symptom i.e.
subjective project status assessment for above
symptom.
Root Causes of SD Problems
Insufficient requirement management.
Ambiguous & imprecise communications.
Brittle architecture.
Overwhelming complexity.
Undetected inconsistencies among requirement,
designs, and implementations.
Root Causes of SD Problems
(Contd..)
Insufficient Testing.
Subjective project status assessment.
Delayed risk reduction due to waterfall approach.
Uncontrolled change preparation.
Insufficient Automation.

Actually, what we should do-
We should attack these root causes (diagnosis) so
that we are not only in position to get rid off the
system, but also we are in a better position to
provide quality to the software in a repeatable and
productive manner.
SIX Best Practices
Develop iteratively.
Manage requirements properly.
Use component architectures.
Model the software visually.
Verify quality.
Manage control changes.
Best Practices of SE
(Schematic)
Manage
Requirements
Use
Component
Architectures
Model
Visually
Verify
Quality
Develop Iteratively
Control Changes
Expect Outcome

Best practices enable high-performance teams
resulting into more successful projects in terms of
quality, timeliness and profits.
Practice 1: Develop Iteratively
Manage
Requirements
Use
Component
Architectures
Model
Visually
Verify
Quality
Develop Iteratively
Control Changes
Practice 1: Develop Software
Iteratively
An initial design is likely to be flawed with
respect to its key requirements.
Late-phase discovery of design defects
results in costly over-runs and/or project
cancellation.
The time and money spent implementing a
faulty design are not recoverable.

Traditional
Waterfall
Development
Requirement
Analysis
Design
Code &
Unit Testing
Subsystem
Testing
System
Testing
Time
Waterfall Development Delays
Reduction of Risk
R
I
S
K
TIME
Waterfall
R
D
T1
C
T2
Apply the Waterfall Iteratively to
System Increments


R
D
T1
C
TIME
Iteration 1 Iteration 2 Iteration 3
R
D
T1
C
R
D
T1
C
-Earliest iterations address greatest risks.
-Each iteration produces an executable release,
an additional increment of the system.
-Each iteration includes integration and test.
T2 T2 T2
Waterfall Development Delays
Reduction of Risk
R
I
S
K
TIME
Waterfall
Iterative
Iteration Iteration Iteration Iteration
Iterative Development Characteristics
Critical risks are resolved before making large
investments.
Initial iterations enable early user feedback.
Testing and integration are continuous.
Objective milestones provide short-term focus.
Progress is measured by assessing
implementations.
Partial implementations can be deployed.
Problems Addressed by Iterative
Development
Root Causes
Insufficient requirements

Ambiguous communications

Overwhelming complexity
Subjective assessment
Undetected inconsistencies
Poor testing
Waterfall development

Solutions
Enables and encourages user
feedback.
Serious misunderstandings evident
early in the life cycle.
Development focuses on critical
issues.
Objective assessment thru testing.
Inconsistencies detected early.
Testing starts earlier.
Risk Identified and addressed
early.
Practice 2: Manage Requirements
Manage
Requirements
Use
Component
Architectures
Model
Visually
Verify
Quality
Develop Iteratively
Control Changes
Practice 2: Manage Requirements
Elicit, organize and document required functionality and
constraints.
Evaluate changes and determine their impact.
Track and document tradeoffs and decisions.

Requirements are dynamic- Expect to change during
software development.
Definitions: Requirements and Their
Management
A requirement is a condition or capability to
which the system must conform.
RM is a systematic approach to
Eliciting, organizing and documenting the
requirements of the systems and
Ensuring the agreement between the client and the
development team on the changing requirements.

Terms of Agreement
Client
System
to be built
The Goal
Use Case Model
Requirements
Surrogate
Goal
Requirements
Verification
A proxy for the client
Requirements Trace to Many Project
Elements
Requirements
Requirement Management
Design &
Implementation
Change
Management
QA & Test
Project
Management
Catching Requirements Errors Early
Effective analysis of the problem and elicitation of the user
needs.
Agreement with the clients on the requirements and vice
versa.
Model interaction between the user and the system.
Establish a baseline and change control process.
Record of forward and backward trace of the requirements.
Use of iterative process.
Problems Addressed by Requirements
Management
Root Causes
Insufficient requirements

Ambiguous communications

Overwhelming complexity
Subjective assessment
Poor testing
Undetected inconsistencies
Insufficient automation

Solutions
Disciplined approach to requirement
gathering.
Communications based on the specified
requirements.
Prioritizing, filtering and tracing the
requirements.
Objective assessment of functionality
and performance.
Inconsistencies detected early.
Provision of a repository tool for
requirements, attributes, and tracing
with automatic links to the documents.
Practice 3: Use Component- Based
Architectures
Manage
Requirements
Use
Component
Architectures
Model
Visually
Verify
Quality
Develop Iteratively
Control Changes
Definition of Software Architecture
SA is defined as a collection (or organization) of
significant components of software system and it involves
decisions like:
Selection of the structural elements and their interfaces by
which a system is composed off.
Behavior as specified in collaborations among those
elements.
Composition of these structural and behavioral elements
into progressively larger subsystems.
Architectural style that guides this organization of
components.
Issues Concerning Architecture
Following issues influence SA structurally and
behaviorally:
Usage
Functionality
Performance
Resilience
Issues Concerning Architecture
(Contd..)
Comprehensibility
Economical and Technological Constraints and
Tradeoffs
Aesthetics
Reuse


Resilient & Component Based
Architectures
Good architectures, that meet their requirements,
are resilient and are component based
A resilient architecture enables
- Improved maintainability and extensibility
-Clean division of work among teams of
developers
-Encapsulation of hardware and system
dependencies
Resilient & Component Based
Architectures (Contd..)
A component-based architecture permits
-Reuse or customization of existing components
-Choice of thousands of commercially available
components
-Incremental evolution of existing software

Problems Addressed by Component
Architectures
Root Causes
Brittle Architectures




Overwhelming complexity

Uncontrolled change

Insufficient Automation


Solutions
Component facilitates resilient
architectures
Reuse of commercially available
components and framework is
facilitated
Modularity enables separation of
concerns
Components provide a natural basis
for configuration management.
Visual modeling tools provide
automation for component based
design.
Practice 4:Visually Model Software
Manage
Requirements
Model
Visually
Verify
Quality
Develop Iteratively
Control Changes
Use
Component
Architecture
Process 4: Visually Model Software
Capture the structure and behavior of architectures
Show how the elements of the system fit together
Hide or expose details as appropriate for the task
Maintain consistency between a design and its
implementation
Promote unambiguous communication.
Visual modeling improves our ability
to manage software complexity
UML: A Tool for Visual Model
The Unified Modeling Language (UML) is
a language for
Specifying
Visualizing
Constructing
Documenting
the artifacts of a software intensive system.
Diagrams are views of a model
Models
Activity
Diagrams
Class
Diagrams
Sequence
Diagrams
State
Diagrams
Component
Diagrams
Deployment
Diagrams
Collaboration
Diagrams
Object
Diagrams
Use-Case
Diagrams
Diagrams are views of a model
A model is a complete description of a
system from a particular perspective.
Use case diagrams are used to illustrate user interaction
with the systems.
Class diagrams are used to illustrate logical structure.
Object diagrams are used to illustrate objects and links.
State diagrams are used to illustrate the behavior.
Component diagrams are used to illustrate physical
structure of the system.

Diagrams are views of a model
(Contd..)
Deployment diagrams are used to show the mapping of
the software to hardware.
Interaction diagrams (collaboration and sequence
diagrams) are used to illustrate behavior.
Activity diagrams are used to illustrate the flow of events
in a use case.
Visual Modeling and Iterative
Development (Changes to Design)

Initial
Requirements
Risk
Targeting
Deployment
Implementation &
Testing
Requirements
Analysis & Design
Assessment
Visual Modeling and Iterative
Development
During implementation and testing within
an iteration, it is likely that architectural or
design changes are made via changes to the
source code. Some changes are intentional
and others are inadvertent.

Visual Modeling and Iterative
Development (Change Assessment)

Initial
Requirements
Risk
Targeting
Deployment
Implementation &
Testing
Requirements
Analysis & Design
Assessment
Problems Addressed by Visual Modeling
Root Causes
Insufficient requirements
Ambiguous communications

Brittle architectures

Overwhelming complexity

Undetected inconsistencies
Poor testing

Insufficient automation

Solutions
Use cases and scenarios unambiguously
specify behavior.
Models capture software design s
unambiguously.
Non-modular or inflexible architectures
are exposed.
Unnecessary detail hidden when
appropriate.
Unambiguous designs reveal
inconsistencies more readily.
Application quality starts with good
design.
Visual modeling tools provide support
for UML modeling.
Practice 5: Verify Software Quality
Manage
Requirements
Use
Component
Architectures
Model
Visually
Verify
Quality
Develop Iteratively
Control Changes
Practice 5: Verify Software Quality
Software problems are 100 to 1000 times more
Costly to find and repair after deployment
C
O
S
T

Development
Deployment
Iterative Development Permits
Continuous Testing
R
D
T1
C
TIME
Iteration 1 Iteration 2 Iteration 3
R
D
T1
C
R
D
T1
C
T2 T2 T2
Test Test Test
Plan
Design
Implement
Execute
Evaluate
Plan
Design
Implement
Execute
Evaluate
Plan
Design
Implement
Execute
Evaluate
Test
Life
Cycle
Testing in an Iterative Environment
Iteration 3 Iteration 1 Iteration 2
Test Suite 1 Test Suite 2 Test Suite 3
R
E
Q
T

T
E
S
T

Automation Reduces Testing Time and Effort
13000 Tests
6 Hours
1 Person
One Manual Test Cycle
13000 Tests 2 Weeks 6 People
Test
Automation
Run More Tests More Often
Dimensions of Software Quality
Functionality
Does my application
do what is required?
Test cases for each
scenario implemented
Reliability
Does my application
leak memory?
Analysis tools and
code instrumentation
Application
Performance
Does my application
respond acceptably?
Check performance for
each use-case/ scenario
implemented
System
Performance
Does my system
perform under
production load?
Test performance for
all use cases under
authentic and worst-
case load
Type Why? How?
Problems addressed by Verifying Quality
Subjective Assessment

Undetected Consistencies

Poor Testing

Insufficient Automation

Testing provides objective
project status assessment
Objective assessment exposes
inconsistencies early
Testing and verification are
focused on high risk areas
Defects are found earlier and
are less expensive to fix
Automated testing tools provide
testing for reliability,
functionality and performance.
Root Causes Solutions
Practice 6: Control Changes to Software
Manage
Requirements
Use
Component
Architectures
Model
Visually
Verify
Quality
Develop Iteratively
Control Changes
Practice 6: Control Changes to Software
Factors of Multiplicity
Multiple Developers
Multiple Teams
Multiple Sites
Multiple Iterations
Multiple Releases
Multiple projects
Multiple platforms
Without explicit control,
Parallel development degrades to chaos.
Three Common Problems
Simultaneous Update: Undesired update by later
on the work of the former.
Limited Notification: All team members are not
notified about fixing of a problem in shared
artifacts.
Multiple versions: it is usual to have multiple
versions of an artifact in different stages at the
same time. e.g. one release is in customer use, one
is in test, and one is still under development.
Three Major Aspects of a Change
Management System
Change Request Management (CRM): Cost and
schedule impacts of a requested changes to the
existing product.
Configuration Management (CM): Defining
configuration; Building, labeling and collecting
versioned artifacts; Maintaining Trace-ability
between versions.
Measurement: Describing the state of the product
in terms type, number, rate and severity of the
defects found and/ or fixing during the course of
development.
Concepts of Configuration and
Change Management
Decompose the architecture into subsystems and assign
responsibility for each subsystem to a team.
Establish secure workplaces for each developer
- Provide isolation from changes made at other work
places.
-Control all software artifacts- models, code, docs etc.
Establish an integration work place.
Establish an enforceable change control mechanism.
Know which changes appear in what releases.
Release a test baseline at the completion of each iteration.
Control Changes Support
All Other Best Practices
Develop Iteratively

Manage Requirements

Use Component
Architectures

Model Visually

Verify Quality
Progress is incremental only if
changes to artifacts are controlled.

To avoid scope creep, assess the
impact of the proposed changes
before approval.
Components must be reliable i.e.
correct versions of all constituent
parts are found.

To assure convergence,
incrementally control models as
designs stabilize.
Test are only meaningful if the
versions of the items under test are
known and the items protected
from changes.
Problems Addressed by Controlling
Changes
Root Causes
Insufficient requirements

Ambiguous communications

Overwhelming complexity
Subjective assessment

Undetected inconsistencies

Uncontrolled Change
Insufficient Automation

Solutions
Requirement change workflow is
defined and repeatable
Change requests facilitate clear
communications
Isolated workspaces reduce
interference from parallel work
Change rate statistics are good
metrics for objectively assessing
project status
Workspaces contain all artifacts,
facilitating consistency
Change propagation is controlled.
Changes maintained in a robust,
customizable system
Best Practices Reinforce Each Other
Develop
Iteratively
Control
Changes
Verify
Quality
Model
Visually
Use
Component
Architecture
Manage
Requirements
Ensures users involved
As requirements evolve
Validates Architectural
Early
Address complexity of design/
Implementation incrementally
Measure quality early and often
Evolves baseline incrementally
The RUP
The RUP (stands for Rational Unified Process)
brings the six best practices together in a form that
is suitable for a wide range of projects and
organizations.
It has four major phases- Inception, Elaboration,
Construction, and Transition that work on
organization along the contents of business
modeling, requirements, analysis and design,
implementation, test, deployment, configuration
and change management, project management and
environment.

Summary: Best Practices of
Software Develoment
The result is software that is
- On Time
- On Budget
- Meets Users Needs