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, architecturecentric 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 isTreating 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 doWe 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)

Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually

Verify Quality

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

Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually

Verify Quality

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

R D C T1 T2

Waterfall

TIME

Apply the Waterfall Iteratively to System Increments

Iteration 1
R D C T1 T2

Iteration 2
R D C T1 T2

Iteration 3
R D C T1 T2

TIME
-Earliest iterations address greatest risks. -Each iteration produces an executable release, an additional increment of the system. -Each iteration includes integration and test.

Waterfall Development Delays Reduction of Risk

R I S K Iterative

Waterfall

Iteration

Iteration

Iteration

Iteration

TIME

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

Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually

Verify Quality

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
The Goal
Client System to be built

Requirements Verification

Surrogate Goal

Use Case Model Requirements

A proxy for the client

Requirements Trace to Many Project Elements

Project Management

Design & Implementation

Requirements
Change Management

QA & Test

Requirement 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

Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually

Verify Quality

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

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.

Overwhelming complexity Uncontrolled change

Insufficient Automation

Practice 4:Visually Model Software

Develop Iteratively

Manage Requirements

Use Component Architecture

Model Visually

Verify Quality

Control Changes

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

Activity Diagrams Object Diagrams Collaboration Diagrams Deployment Diagrams Use-Case Diagrams Class Diagrams

Models

Sequence Diagrams State Diagrams Component 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 Assessment Implementation & Testing Deployment Requirements Analysis & Design

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 Assessment Implementation & Testing Deployment Requirements Analysis & Design

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

Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually

Verify Quality

Control Changes

Practice 5: Verify Software Quality

C O S T
Software problems are 100 to 1000 times more Costly to find and repair after deployment

Deployment

Development

Iterative Development Permits Continuous Testing

Iteration 1
R D C T1 T2

Iteration 2
R D C T1 T2

Iteration 3
R D C T1 T2

TIME

Test

Test
Plan Design Implement Execute Evaluate

Test
Plan Design Implement Execute Evaluate

Plan Test Design Implement Life Execute Cycle Evaluate

Testing in an Iterative Environment

R E Q T
Iteration 1 Iteration 2 Iteration 3

T E S T

Test Suite 1

Test Suite 2

Test Suite 3

Automation Reduces Testing Time and Effort

One Manual Test Cycle 13000 Tests 2 Weeks 6 People

Test Automation
13000 Tests 6 Hours 1 Person

Run More Tests More Often

Dimensions of Software Quality

Type
Functionality Reliability Application Performance System Performance

Why?
Does my application do what is required? Does my application leak memory? Does my application respond acceptably?

How?
Test cases for each scenario implemented Analysis tools and code instrumentation Check performance for each use-case/ scenario implemented

Does my system perform under production load?

Test performance for all use cases under authentic and worstcase load

Problems addressed by Verifying Quality

Root Causes Subjective Assessment Undetected Consistencies

Poor Testing
Insufficient Automation

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

Practice 6: Control Changes to Software

Develop Iteratively

Manage Requirements

Use Component Architectures

Model Visually

Verify Quality

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

Model Visually
Verify Quality

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

Ensures users involved As requirements evolve Validates Architectural Early Address complexity of design/ Implementation incrementally Measure quality early and often Manage Requirements
Use Component Architecture

Develop Iteratively

Model Visually

Verify Quality
Control Changes

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