Murray Hill, NJ March 5, 2004 Welcome to Telelogic’s TechConnect at Lucent Bell-Labs.

Murray Hill, NJ

March 5, 2004

Welcome to Telelogic’s TechConnect

at Lucent Bell-Labs

2 Telelogic TechConnect – Lucent Technologies

Opening Remarks

• Software Industry Challenges

• Requirements Engineering: Practices & Tools

• Software Technology Center


Software Industry Challenges

CostsUp

CostsUp

RevenuesDown

RevenuesDown

MarketExpectations

Up

MarketExpectations

Up

Solutions that areflexible, expansible, survivable, sustainable, affordable and secure

ComplexityUp

ComplexityUp

Stockholders : ROICustomers: ValueUsers : Functionality & Quality

Stockholders : ROICustomers: ValueUsers : Functionality & Quality

IntervalsShrinking


User Needs AssessmentUser Needs Assessment

Front-End Activities: Is This Complex or What?

Inception Elaboration Construction

V&V

Use Cases Use Cases

Test/rev., executionTest/rev., execution

Process/Data FlowsProcess/Data Flows

ImplementationsImplementations

Operational ProfilesOperational Profiles

Component ModelComponent Model

Test Case SkeletonsTest Case Skeletons Test CasesTest Cases

Context Diagram Context Diagram

PLA PLA

Product Arch. Product Arch. Design Scenarios Design Scenarios

Class Models Class Models

Vision StatementVision Statement

Problem StatementProblem Statement

MW Class DiagramsMW Class Diagrams

H. PrototypesH. Prototypes

Story BoardsStory BoardsUser Task FlowsUser Task Flows

Requirements

Analysis

Architecture & Design

Implement.Verification

Verification

Levels of Requirements Specs

V&V

NF(Archit.)R/POTRNF(Archit.)R/POTR

V. PrototypesV. Prototypes

User Profiles User Profiles

State Models State Models UI DesignUI Design

Detailed Scenarios Detailed Scenarios

User Req. Spec. User Req. Spec.

Verification

Usability TestingUsability Testing

Scenarios Scenarios

Verification

Time Test


Doing the right thing right– Agreement on goals and targets

– Risk management

– Early defect prevention and reduction

– Elimination of gaps and redundancies

Throughout software engineering lifecycle

– Start in front end

– Addressed in all phases

With inter-related, right weight processes and tools– Repeatable

– Measured

– Adaptive

– Iterative

Doing the Right Things Right


Requirements Engineering & DOORSEffectively generating High Quality Requirements:

• modifiable

• traceable

• verifiable

• non-ambiguous

• understandable

• annotated

• correct

• consistent

• complete

Requirements ManagementRequirements Management

Elicitation

Analysis

Modeling & Specification

Verification & Validation

Change Control

Version Control

Tracing & Impact Analysis

Status TrackingBest Practices, Methods,Tools and Processes for Requirements Engineering

Requirements Development

Requirements Engineering


The Best Practices Effect: Early Defect Prevention & Reduction

Current

TIME

Ra

te o

f D

isc

ov

ery

Requirements Design &Build

Proposed

DefectPrevention

& Reduction

Releaseto Test

Releaseto Field

* 100X Decrease in Cost of Removing Defects

Source*: Boehm, Barry. Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall, Inc. 1981. Boehm, Basili. “Software Management.” IEEE Computer, January 2001.


STC Domains of Expertise

Requirements

Software Configuration

Mgmt

Architecture

Testing

Integrated Information Solutions

RealizationHumanFactors

Vassilka Kirova ( [email protected] )

Darshak Kothari ( [email protected] )

March 5, 2004

DOORS @ Lucent:Experiences, Extensions, Integration Efforts

mailto:[email protected]




DOORS@Lucent: Overview

• Areas of application

• Key Projects

– Artifact Flow Through

– Virtual Requirements & Architecture Documents (VRAD)

– Architectures & DOORS

• Next Step

• Q&A


Areas of Application

Configuration/Change Management Tools

Metrics Tools

Project Management Tools

Documentation Tools

Requirements Management & Traceability Tools

Requirements

Capture &Engineerin

g

Architecture Specification

ModelingTools

Simulation

Tools

CodingTools

Testing & Test Mgmt


Key Projects: Artifact Flow Through

• Goal – Increase product quality and team

efficiency/productivity– Decrease development cycle time

• Constraints– No impact on schedules– Compliance with Mobility process– Compliance with TL 9000 requirements– Use of Mobility/Lucent standard tools

• Work Model: – Collaboration & Co-ownership between STC and

PacketIN– Continuous Improvement with Clear Targets– Focus on Technical Excellence


What is Artifact Flow Through?

•A Modular, Integrated Method, Tool and Process Environment for:– Specification, modeling, generation

and management of software “artifacts” – requirements, designs, and test work items

– Process improvement supporting collaboration, elimination of functional smokestacks, and more iterative development

•Leverages best software practices– Use case –driven, scenario-based

development– Model-based design– Early testing paradigm

•Data-driven approach – Metrics definition and automation– Benchmarking data & monitoring – Data collection, analysis and ongoing-

improvement

PacketIN Environment

ExtendedSystem Engineering Support

DOORS

ExtendedDeveloper Support

ROSE

APX-TMS

Design to Req. Traceability

Req. to Test Traceability

Jumpstart Rose Model

Generate Test Cases

Test Management

TesterActivities

30% Increase in degree of automation

10% Increase in multi-use of artifacts

20% Reduction in defects (end customer)

13%-20%Reduction in Effort (THCM)

Target

(per release) Success Criteria

Example: PacketIN Targets


AFT: Benefits

• AFT Increases quality and productivity while reducing the cycle time via:– Common – scenario-based -representation throughout development cycle

– Smooth “handoffs” of artifacts – “artifact flow” – with no-rework

– Maximum reuse of knowledge and artifacts

– Maximum automation – generation of test cases, design jumpstart, metrics

– Automated Traceability

PacketIN Projected Gain

Cumulative ROI

(500,000)

0

500,000

1,000,000

1,500,000

2,000,000

Sept '02 Sept '03 Sept '04

Time

Cum

ulat

ive

$

CumulativeSavings

CumulativeCostEstimate

CumulativeROI

Projected ROI$200-500K in the first year

$1-2M in each subsequent year

Distribution of savings:– Reduction in field defects accounts

for 35% of the expected savings

– Effort reduction accounts for 65% of the expected savings


AFT: Key Components & Features

SE Activities

SRD support in DOORSExtended DOORS Infrastructure XML GenerationUse Case Syntax CheckMetrics & Reports

DOORS

Developer Activities ROSE

Rose - based DesignCM (CCMS) for Rose ModelsDesign to UT Traceability

Design to Req. Traceability

Requirements to Test Traceability

Rose Model Jumpstart

Test Case Generation

TesterActivities APX-TMS

Test Management

XML Representation

of Requirements


End-to-End Workflow: “Flowthrough”

SE

Create SRDUCs, POTRImport DXL

Generate MS Doc & XML

DXL Scripts DOORS

Jumpstart Rose Model

Generate & Store

Test Case

Manage Test Cases

INTA

TMSROSE

XML File“Hand-off” COMPAS MS Word File

“Hand-off” COMPAS

Create Design Models

•Generate for review, send notification•Generate baselined version, send notification

Developer Tester

“Hand-off” WEB

“Hand-off” CCMSRose Model Publ. Model

Design Document - COMPAS


Better Requirements and Product Quality through Use Cases (UC)

• Characteristics and Benefits – UCs capture a contract

between the stakeholders of a system about its behavior

– UCs specify system’s behavior under various conditions (success & failure modes) in a way that is concise and easy to understand, track, and validate

– UCs are collections of scenarios; scenarios provide context – traditional requirements are often too ambiguous

– UCs are a key to the creation/ generation of quality test cases and system verification

Industry data:

• Use cases improved developer productivity by 40% (DaimlerChrysler)

• 35% increase in developer productivity at Merrill Lynch achieved through: Tool-based Requirements Management and Use cases

Industry data:

• Use cases improved developer productivity by 40% (DaimlerChrysler)

• 35% increase in developer productivity at Merrill Lynch achieved through: Tool-based Requirements Management and Use cases


End to End Workflow: Traceability

SE

Generate XML:UC, POTR, Links

DOORS

Populate ReqLinkProperty, ReqList

Package

TMS Query Support

TMSROSEModels

Annotated with Req.;Run a Report

Developer Tester

Traceability Report

ModelsAnnotated with Tests;

Run a Report

Auto-Generate DOORS-TMS

Links

QueryingTMS Data

Generate/Update Surrog.

Module

FTF 004

DXL

XML File TMS Data File


Innovate the Way The Team Works Together: Process Flow for High Quality …

Requirements written in DOORS

Delivered to tester (and developers) early

Initial run through INTA

Early Comments to SE

High Quality Review


AFT Software Innovation

Integrated Best Practices, Processes & Tools

Test(Augmenting TMS)

• Test cases generation from requirements

–Optimized coverage–Choice of algorithms

• Tool-based requirements traceability

–Gaps & coverage–Change notification–Impact analysis–Test reuse

Adds functionality to standard Mobility toolsProvides “Glue” Software

Scalable integration architecture

System Engineering(Extending DOORS)

• Support for Use Cases in DOORS

–Structured template

–Syntax Checker

• XML representation of requirements for downstream tools

• Test coverage reports (traceability support)

• Metrics Reports

Design(Augmenting Rose)

• Design model jumpstart tool – use case view and UML sequence diagrams

• Design-to-unit test traceability support

• Design to requirements traceability tool and reports

• Guidelines for legacy code reengineering


Key Projects: VRAD

• What are VRADs?

– “Books” of project/feature/component specific requirements, architecture and any other supporting information

• Means for:

– Need-based content definition

– Flexible, automated, on demand document generation

• Benefits:

– Reuse of artifacts

– Avoiding information overload

– IP protection


VRAD Use Cases

Prepare Source Doc.

Configure VRAD

Publish Combined VRAD

Generate DOORS VRAD

VRAD Owner

Source Doc. OwnerAuthor

Doc Controller

DOORS

Instantiate VRAD Template

VRADTool

Manual

Legend:

TOOL-based


VRAD Generation Tool Workflow Illustrated

Publish DOORS

VRAD

DOORS VRAD Template

VRADVersions (PDF)

DOORS

Note: VRAD contains information from DOORS documents (SAE artifacts) as well as other external documents

Note: VRAD contains information from DOORS documents (SAE artifacts) as well as other external documents

Publish

Combined

VRAD

Other Source Documents

TaggedSource Documents

Configure VRADVRAD GUI

GenerateVARD

Generate VRAD

SAE VRAD


Key Projects: Architecture & DOORS

• What is an architecture specification? Meta-model: views, components, interfaces, constraints, etc.

• What are the current architecture specification/representation practices in Lucent? Structured documents, informal diagrams …

• What are the current architecture representation practices elsewhere? What are the best practices? From informal text to ADLs

• What are the current expectations/experience of architecture specs users? What is the expected final product? Documents ….

• What is the evolution path? Structured documents & informal “block-&-line” diagrams ->

structured textual specifications based on underlying “meta-model” & rigorous models (e.g., UML diagrams) -> formal models or partial formal models & constraints & textual annotations

• Is DOORS a step forward?


DOORS: Underlying architecture and usage model

• DOORS is an object-based module/document-centric management system which supports:

– Storing and viewing information objects in context

– Linking and traceability

– Tracking changes

– Editing and baselining

• DOORS is not:

– A relational data-base

– A modeling tool


Benefits & Drawbacks of moving to DOORS

• Benefits– Viewing the architecture information in context; easy

navigation between different architecture specs as well as between architecture and requirements artifacts

– Traceability between information objects at selected level of granularity, e.g., requirements to an interface

– Tracking changes and impact analysis– Structuring/Restructuring the architecture specification

artifacts according to a common model – an opportunity for streamlining the specs

– Step toward a “model-text” specification approach

• Drawbacks– A somewhat clumsy editing– Performance issues– Learning curve


Representation Model

• Views– Structural View

• Component, Interfaces, Connectors (and configurations)

– Behavioral View• State models, scenarios, etc.

– Quality View• Reliability, Performance, Maintainability, etc.

– Deployment View• Hardware configurations, software allocation to

machines, etc.

• Rational, constraints & annotations


Representation Model – The Structural View

• Key Structural Elements

Connector

Component(e. g. A1)

System (e.g., A)

Component Interface (ports)

Systems (subsystem-architectures)

Component decompositions (alternatives)

Component(e. g. A2)

Interface (of A)

Black-box Component

White-box Component


Some Issues that Need Further Attention

• Printing should allow to print line numbers

• Saving a view does not allow to inherit access rights from module.

• Export to Word sometimes does not copy certain OLE objects and does not finish cleanly.

• Printing in book format over runs in to margins and looses some text if it does not fit in the margins. Specifically for text in the attributes.

• Need to have “diff-marking” functionality.


Next steps

Configuration/Change Management Tools

Metrics Tools

Project Management Tools

Documentation Tools

Requirements Management & Traceability Tools

Requirements

Capture &Engineerin

g

Architecture Specification

ModelingTools

Simulation

Tools

CodingTools

Testing & Test Mgmt


Acknowledgments

• The work presented here has been done in collaboration with Mobility SAE organization and PacketIN SE department

Murray Hill, NJ March 5, 2004 Welcome to Telelogic’s TechConnect at Lucent Bell-Labs.

Documents

Transcript of Murray Hill, NJ March 5, 2004 Welcome to Telelogic’s TechConnect at Lucent Bell-Labs.