Welcome to Telelogic’s TechConnect at Lucent Bell-Labs

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

2. Opening Remarks • Software Industry Challenges • Requirements Engineering: Practices & Tools • Software Technology Center

3. Market Expectations Up Costs Up Intervals Shrinking Complexity Up Revenues Down Stockholders : ROI Customers: Value Users : Functionality & Quality Solutions that are flexible, expansible, survivable, sustainable, affordable and secure Software Industry Challenges

4. User Task Flows Story Boards H. Prototypes Front-End Activities: Is This Complex or What? V&V V&V Inception Elaboration Construction User Needs Assessment Vision Statement Context Diagram Levels of Requirements Specs Problem Statement User Profiles User Req. Spec. Use Cases Detailed Scenarios Requirements NF(Archit.)R/POTR Operational Profiles Scenarios Verification MW Class Diagrams Process/Data Flows Analysis V. Prototypes Verification PLA Class Models State Models UI Design Product Arch. Design Scenarios Component Model Architecture & Design Verification Implementations Implement. Verification Usability Testing Test Case Skeletons Test Cases Test/rev., execution Time Test

5. Doing the Right Things Right • 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

6. Effectively generating High Quality Requirements: Elicitation Analysis Modeling & Specification Verification & Validation Requirements Engineering & DOORS • correct • consistent • complete • modifiable • traceable • verifiable • non-ambiguous • understandable • annotated Requirements Engineering Requirements Management Requirements Development Change Control Version Control Tracing & Impact Analysis Status Tracking Best Practices, Methods,Tools and Processes for Requirements Engineering

7. The Best Practices Effect: Early Defect Prevention & Reduction Source*: Boehm, Barry. Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall, Inc. 1981. Boehm, Basili. “Software Management.” IEEE Computer, January 2001. Current DefectPrevention & Reduction Rate of Discovery Proposed Requirements Design &Build Releaseto Test Releaseto Field TIME * 100X Decrease in Cost of Removing Defects

8. Architecture Requirements Realization Integrated Information Solutions Human Factors Software Configuration Mgmt Testing STC Domains of Expertise

9. DOORS @ Lucent:Experiences, Extensions, Integration Efforts Vassilka Kirova ( kirova@lucent.com )Darshak Kothari ( dkothari@lucent.com ) March 5, 2004

10. DOORS@Lucent: Overview • Areas of application • Key Projects • Artifact Flow Through • Virtual Requirements & Architecture Documents (VRAD) • Architectures & DOORS • Next Step • Q&A

11. Areas of Application Architecture Specification Requirements Capture & Engineering Modeling Tools Simulation Tools Coding Tools Testing & Test Mgmt Requirements Management & Traceability Tools Documentation Tools Project Management Tools Configuration/Change Management Tools Metrics Tools

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

13. Success Criteria Target (per release) Reduction in Effort (THCM) 13%-20% Reduction in defects (end customer) 20% Increase in multi-use of artifacts 10% Increase in degree of automation 30% What is Artifact Flow Through? PacketIN Environment • 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 Design to Req. Traceability Extended Developer Support ROSE Extended System Engineering Support Jumpstart Rose Model Generate Test Cases DOORS Test Management Tester Activities Req. to Test Traceability APX-TMS Example: PacketIN Targets

14. PacketIN Projected Gain • 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: 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

15. AFT: Key Components & Features Rose - based Design CM (CCMS) for Rose Models Design to UT Traceability Design to Req. Traceability Developer Activities ROSE Rose Model Jumpstart SRD support in DOORS Extended DOORS Infrastructure XML Generation Use Case Syntax Check Metrics & Reports XML Representation of Requirements Test Case Generation SE Activities DOORS Test Management Requirements to Test Traceability Tester Activities APX-TMS

16. End-to-End Workflow: “Flowthrough” • Generate for review, send notification • Generate baselined version, send notification Create SRD UCs, POTR Import DXL Generate MS Doc & XML DXL Scripts DOORS SE “Hand-off” COMPAS “Hand-off” COMPAS XML File MS Word File Jumpstart Rose Model Generate & Store Test Case INTA Developer Tester Create Design Models Manage Test Cases TMS ROSE “Hand-off” CCMS “Hand-off” WEB Rose Model Publ. Model Design Document - COMPAS

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

18. TMS Data File XML File End to End Workflow: Traceability FTF 004 Querying TMS Data Generate/ Update Surrog. Module Auto-Generate DOORS-TMS Links Generate XML: UC, POTR, Links DXL DOORS SE Populate ReqLink Property, ReqList Package Developer Tester ROSE TMS TMS Query Support Models Annotated with Req.; Run a Report Models Annotated with Tests; Run a Report Traceability Report

19. Innovate the Way The Team Works Together: Process Flow for High Quality … Requirements written in DOORS High Quality Review Early Comments to SE Delivered to tester (and developers) early Initial run through INTA

20. AFT Software Innovation Integrated Best Practices, Processes & Tools • 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 • 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 • 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 Adds functionality to standard Mobility tools Provides “Glue” Software Scalable integration architecture

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

22. VRAD Use Cases DOORS Prepare Source Doc. Instantiate VRAD Template Source Doc. Owner Author VRAD Tool Configure VRAD Generate DOORS VRAD VRAD Owner Publish Combined VRAD Legend: Manual TOOL-based Doc Controller

23. VRAD Versions (PDF) SAE VRAD DOORS VRAD Template Other Source Documents VRAD Generation Tool Workflow Illustrated Configure VRAD VRAD GUI Publish DOORS VRAD Publish Combined VRAD Generate VRAD Generate VARD Note: VRAD contains information from DOORS documents (SAE artifacts) as well as other external documents DOORS Tagged Source Documents

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

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

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

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

28. Systems (subsystem-architectures) Representation Model – The Structural View • Key Structural Elements Interface (of A) System (e.g., A) Connector Component (e. g. A2) Component (e. g. A1) Component decompositions (alternatives) Black-box Component Component Interface (ports) White-box Component

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

30. Next steps Architecture Specification Requirements Capture & Engineering Modeling Tools Simulation Tools Coding Tools Testing & Test Mgmt Requirements Management & Traceability Tools Documentation Tools Project Management Tools Configuration/Change Management Tools Metrics Tools

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

32. Questions?