DevSuite Admin Guide. Date:

Transcription

1 DevSuite Admin Guide Author: TechExcel co.ltd Date:

2 Table of Content DevSuite Admin Guide DevSuite Overview and Common System Settings Chapter 1 Chapter 1- Understanding TechExcel DevSuite 1.1 Understanding TechExcel DevSuite 1.2 DevSuite Components 1.3 Understanding KnowledgeWise 1.4 Understanding DevSpec 1.5 Understanding DevPlan 1.6 Understanding DevTrack 1.7 Understanding DevTest 1.8 Upgrade Steps: Chapter 2 Chapter 2- Understanding DevSuite Integration 2.1 Understanding DevSuite--CustomerWise Integration 2.2 Understanding DevTrack--VersionLink Integration Chapter 3 Chapter 3- Getting started with DevSuite Admin 3.1 Logging into DevSuite Admin 3.2 Understanding DevSuite Admin Workspace Understanding menu bar commands Understanding tool bar commands Understanding keyboard shortcuts 3.3 Open DevSuite projects Chapter 4 Chapter 4 - Understanding the DevSuite Administrat 4.1 Assigning Admin Roles to Users 4.2 DevSuite Administration 4.3 Understanding Administrator Roles--System, Division, and Project Chapter 5 Chapter 5- Administering DevSuite Projects 5.1 Administering Sample Projects 5.2 Creating DevSuite Projects 5.3 Administering DevSuite Projects 5.4 Administering Project Templates 5.5 Backing Up DevSuite Projects 5.6 Understanding Project Class, Project Type and Project Status 5.7 Understanding Active and Inactive Projects 5.8 Administrative Tasks Performed by System Administrators 5.9 Restoring DevSuite Projects 5.10 Deleting DevSuite Projects Chapter 6 Chapter 6- User & License Management 6.1 Understanding System-Level User Administration 6.2 Administering User Licenses Understanding License Edition Understanding Site License Understanding License Class Understanding License Types Loading DevSuite License File Tracking DevSuite LIcenses 6.3 Administering User Accounts Creating User Accounts 6.4 Administering User Logins Viewing the Login Status Of Project Members Managing Idle Timeout Settings Viewing Login History Logs 6.5 Administering Divisions Managing Divisions Chapter 7 Chapter 7- Administering DevSuite-DevTest Integrat 7.1 Understanding DevSuite-DevTest Integration 7.2 Guide to Administering DevSuite--DevTest Integration 7.3 Guide to enabling DevSpec/KnowledgeWise integration in DevTest Chapter 8 Chapter 8- Administering Multisite Deployment 8.1 Understanding DevSuite Multisite Steps to deploy a Multi-site envrionment 8.2 Guide to Creating a DevSuite Multi-Site Family 8.3 Guide to distributing Local Projects to Other Sites Chapter 9 Chapter 9- LDAP Directory Server Integration 9.1 Administering Directory Server Integration 9.2 Administering LDAP Directory Server Registration 9.3 Administering Field-Attribute Matching Identification 9.4 Administering Field and Attribute Mapping 9.5 Administering LDAP Directory Server Authentication 9.6 Importing User Accounts from a LDAP Server Filtering User Accounts in the LDAP Import Wizard DevSuite System Settings Administration Chapter 1 General System Settings Administration 1.1 System Level General Settings 1.2 Managing Applicable Applications 1.3 Administering System Date and Time Settings 1.4 Enabling Spell Check and Auto Log Off Time Settings 1.5 Administering Keyword Searching

3 1.6 Administering Standard Lookup Fields Defining Standard Lookup Fields and Field Values 1.7 Multilingual Support and Localization Administration 1.8 Administering Time Categories 1.9 Administering LinkPlus Integration 1.10 Managing DevSuite Admin Reports User Information Report Project information Report Admin Change Log Report 1.11 Administering Welcome and Warning System Messages Chapter 2 DevSuite Web Administration 2.1 Understanding DevSuite Web Server Administration 2.2 Administering the DevSuite Web Server Administering DevSuite Web URLs in DevSuite Admin Client Administering Multiple DevSuite Web Servers 2.3 DevTrack Web Administration Defining DevTrack Web Connections Defining DevTrack Web Issue List and Reporting Options Administering Interproject Switching Defining DevTrack Web Titles, Welcome Messages and Logout URL 2.4 Beta Customer Portal Administration 2.5 Administering Image and Multimedia Attachment Settings Defining DevTrack Web Image Attachment Settings Defining DevTrack Web Movies and Sound Attachments Settings 2.6 Administering DevTrack Web Authentication and Access Controls Configuring DevTrack Login and Password Authentication Configuring Windows NT User Authentication Configuring Third Party Authentication DevTrack Web SSO Chapter 3 Document Serve and Mail Service Administration 3.1 Understanding DevSuite Document Server 3.2 Administering DevSuite Document Server Installing and Configuring the Document Server Updating Document Server Info in the Admin Client 3.3 Troubleshooting File Attachment Issue 3.4 Understanding DevSuite Mail Services 3.5 Administering DevSuite Mail Services Installing and Configuring the Notification/ Retrieval Service Administering Error Handling Defining Trace Levels Defining Mail Service Sensitivity Settings Defining Error Log Files Defining Service Error Reports Troubleshooting DevTrack Notification Service Errors Chapter 4 Division Management 4.1 Understanding Divisions Managing Divisions Chapter 5 Product Release Management 5.1 Understanding Produce Release Management Administration 5.2 Administering the Product Component Version Tree Administering Product Catogories Administering Products Administering Versions Administering Builds Defining Applicable Products/Versions in DevSpec/ DevTrack Projects 5.3 Administering the Product Family Version Tree 5.4 Administering Product, Version, and Build Release Statuses Defining the Product Release Lifecycle Administering the Version Release Lifecycle Administering Build Release Lifecycle 5.5 Administering Product Implementation Modules Adding Product Implementation Modules 5.6 Administering Product Version Options Defining Version Options Applying Version Options to Versions Chapter 6 Time and Cost Tracking Administration 6.1 Understanding Time and Cost Administration 6.2 Administering Time Groups and Time Categories Creating Time Groups Editing Time Groups Creating Time Categories Editing Time Categories 6.3 Understanding Time and Cost Administration 6.4 Administering Time Groups and Time Categories Creating Time Groups Editing Time Groups Creating Time Categories Editing Time Categories Chapter 7 Managing DevSuite with Other Modules 7.1 Inter-Project Switching Settings 7.2 Project Portfolio Management 7.3 DevTime and Work Schedule Management 7.4 Kloud Integration Management Chapter 8 DevTest System Settings Administration 8.1 Understanding DevTest Site Administration

4 8.2 Administering DevTest Database Servers 8.3 Administering DevTest Application Servers 8.4 Administering the DevTest Document Server 8.5 Administering System Date and Time Settings 8.6 Administering System Messages and Help 8.7 Administering DevTest Admin Reports 8.8 Administering DevTest Web 8.9 Administering DevSuite Integration 8.10 Administering Multiple Sites KnowledgeWise Projects Administration Chapter 1 KnowledgeWise Concepts 1.1 Understanding TechExcel KnowledgeWise and DevSuite Understanding DevSuite ALM Solutions Understanding TechExcel Project Hierarchy 1.2 Understanding DevSuite Administration Understanding DevSuite Site (System-Level) Administration Understanding Project Administration 1.3 Understanding DevSuite Sample Projects and Templates Understanding Sample Projects Understanding Project Templates Understanding Solution Templates Chapter 2 Project Administration 2.1 Understanding KnowledgeWise Project Administration Understanding Projects 2.2 Understanding the DevSuite Admin Workspace Understanding Menu Bar Commands Understanding the Tool Bar Commands Logging into DevSuite Admin Opening KnowledgeWise Projects Closing DevTrack Projects Understanding Keyboard Shortcuts 2.3 Administering KnowledgeWise Projects Creating Knowledge Management Projects Opening KnowledgeWise Projects Backing Up KnowledgeWise Projects Restoring KnowledgeWise Projects Creating Projects Based from Backed Up Projects Copying KnowledgeWise Project Settings Understanding Active and Inactive Projects Active Projects Inactive Projects Deleting KnowledgeWise Projects Defining Project Names and Descriptions Defining Knowledge Item ID Prefixes Defining Projects as Active and Inactive Defining Name Formatting Defining Project Time Zone Settings Chapter 3 Team Administration 3.1 Understanding Team Administration 3.2 Administering Account Types, Access Controls, and Privileges Defining Account Types Administering Knowledge Management Privileges Administering Invisible Pages and Fields Administering Read-Only Pages and Fields Administering Report Access Controls and Privileges 3.3 Administering Project Team Members Adding User Accounts to Projects Removing User Accounts from Projects 3.4 Administering Team Groups Defining Team Groups Adding and Removing Project Members to Team Groups 3.5 Administering Group Folders Defining Group Folders Chapter 4 Knowledge Folder Administration 4.1 Administering Knowledge Item Folders 4.2 Administering Knowledge Folder Function Pages Administering the Add Knowledge Folder Page Administering the Edit Knowledge Folder Page 4.3 Administering Knowledge Folder System Pages Defining System Page Titles Customizing the Applicable Product System Page Customizing the Knowledge Folder Applicable Owner Page Customizing the Access Control System Page Customizing the Folder Order System Page 4.4 Administering Knowledge Folder System Fields Displaying Access Controls in Custom Pages Chapter 5 Knowledge Item Administration abc 5.1 Understanding KnowledgeWise Knowledge Items 5.2 Administering Knowledge Item Function Pages Administering the Add Knowledge Item Function Page Administering the Edit Knowledge Item Function Page Administering the Knowledge Item Detail Function Page Administering the Forward Knowledge Item Function Page 5.3 Administering Knowledge Item System Pages Administering the Knowledge History System Page

5 5.3.2 Administering the Version System Page Administering the Knowledge Event System Page Administering the Knowledge Item All Links System Page Administering the Linked Knowledge System Page 5.4 Administering Knowledge Item Fields and Controls Understanding Knowledge Item System Fields 5.5 Administering Knowledge Item List Columns Displaying Knowledge System Fields in the Knowledge List Panel Customizing Knowledge Item List Indicator Icons Customizing Knowledge Item List Font Colors and Weights 5.6 Administering Knowledge Item-Level Knowledge Management Enabling Spell Checking in the Description Control Enabling HTML Formatting in the Description Control Chapter 6 Secured Access Level Administration 6.1 Understanding Secured Knowledge Access Level Security Understanding Access Level Conflict Resolution Rules Comparison with Public and Protected Access Controls 6.2 Administering Knowledge Folder Secured Access Levels Defining Knowledge Folder Access Levels Defining User Account Access Levels 6.3 Administering Knowledge Item Access Levels Defining Knowledge Folder Access Levels Defining User Account Access Levels 6.4 Administering Non-Member Access Levels Chapter 7 Page, Field, and Control Administration 7.1 Understanding KnowledgeWise Client GUI Customization 7.2 Administering System Pages 7.3 Administering Custom Pages Creating Custom Pages Adding Controls to Custom Pages Removing Controls From Custom Pages Ordering Controls in Custom Pages Adding Static Labels Understanding Custom Page Form Design Commands Aligning Custom Controls and Labels Resizing Controls and Labels 7.4 Administering System Controls 7.5 Administering Custom Fields and Controls Understanding Control Types Customizing Check Box Controls Customizing Date-Time Controls Customizing Short Text Box Controls Customizing Multiple-line Text Box Controls Customizing Composed Field Controls 7.6 Customizing Selection and Combination Box Controls Defining Selection List Options (Manually) Defining Selection List Options (From Lookup Fields) Defining Parent-Child Relationships Between Controls Customizing Autogrow Combo Box Controls Customizing Combo Box Controls Customizing Dropdown List Controls Customizing Multiple Selection Controls New Section 7.7 Administering Calculation Fields and Controls Defining Numerical Calculation Controls Defining Date Calculation Controls Defining Selection Calculation Factors Chapter 8 Workflow Administration 8.1 Administering Knowledge Item Workflow Enabling Support for Knowledge Workflow Rules Defining Workflow States Defining Workflow Transitions Defining State-Based Access Controls Defining Transition-Based Access Controls Defining State-Based Applicable Owners and Default Owners Defining Knowledge State Versioning Rules Defining State-Based Read-Only Knowledge Item Fields Defining State-Based Mandatory Knowledge Item Fields Defining State-Based Invisible Knowledge Item Fields 8.2 Administering Knowledge Item State Groups Enabling Knowledge Item State Group Support Creating New Knowledge Item State Groups Defining Knowledge Item State Groups Chapter 9 Event Administration 9.1 Administering KnowledgeWise Events 9.2 Administering Event Templates Defining Default Event Titles and Descriptions Defining Default Event Workflow States Defining Default Event Owners 9.3 Administering Event Workflow Creating Event States Editing Event States Deleting Event States 9.4 Administering Event Access Controls DevSpec Projects Administration

6 Chapter 1 DevSpec Concepts 1.1 Understanding TechExcel DevSpec and DevSuite 1.2 Understanding DevSuite ALM Solutions Understanding TechExcel Project Hierarchy 1.3 Understanding DevSuite Administration 1.4 Understanding DevSuite Site (System-Level) Administration 1.5 Understanding Project Administration 1.6 Understanding DevSuite Sample Projects and Templates 1.7 Understanding Sample Projects 1.8 Understanding Project Templates 1.9 Understanding Solution Templates Chapter 2 Project Administration 2.1 Understanding DevSpec Project Administration Understanding Projects 2.2 Understanding the DevSuite Admin Workspace Understanding Menu Bar Commands Understanding the Tool Bar Commands Logging into DevSuite Admin Opening DevSpec Projects Closing DevTrack Projects Understanding Keyboard Shortcuts 2.3 Administering DevSpec Projects Creating DevSpec Projects Backing Up DevSpec Projects Restoring DevSpec Projects Creating Projects Based from Backed Up Projects Chapter 3 Team Administration 3.1 Understanding Team Administration 3.2 Administering Account Types, Privileges, and Access Controls Defining Account Types Granting Privileges to an Account Type Defining Page-Level and Field-Level Access Rights Renaming Account Types Deleting Account Types Understanding Specification View Privileges and Access Controls Privileges Access Control Understanding Requirement View Privileges and Access Controls Privileges Access Control Understanding Change Request View Privileges Understanding Report View Privileges Understanding Invisible Pages and Fields Understanding Read-Only Pages and Fields 3.3 Administering Secured Folder Access Levels Understanding Secured Folder Access Level Conflict Resolution Access type prioritization User account prioritization Defining Secured Work Item Access Levels Defining Secured Folder Access Levels Updating Secured Folder Access Levels for All Users Chapter 4 Specification Administration 4.1 Understanding DevSpec Specifications Understanding Specification Administration Enabling Specifications Defining Specification ID Prefixes Defining Specification Starting Numbers 4.2 Administering Specification Folders Customizing the Add Specification Folder Function Page Administering the Edit Specification Folder Function Page Administering Specification Folder System Pages Customizing the Spec Folder Applicable Owner System Page Customizing the Change Log System Page Customizing the Folder Order System Page Customizing the Access Control System Page Displaying Access Controls in Custom Pages 4.3 Administering Specifications Administering the Add Specification Function Page Administering the Edit Specification Function Page Administering the Specification Detail Function Page Administering the Forward Specification Function Page Administering the Version Function Page Administering the Specification Template Function Page Administering the Group Change Specification Function Page Administering the Group Forward Specification Function Page Administering the Specification Change Function Page Administering the DevSpec User Function Page Chapter 5 Change Requests Administration 5.1 Understanding DevSpec Change Request Administration 5.2 Administering Change Request Folders Administering Change Request Folder Description Page System Fields 5.3 Administering Change Requests Administering Change Request System Pages Administering the Edit Change Request Function Page Administering the Change Request Detail Function Page

7 5.3.3 Administering the Change Request Detail Function Page Administering the Forward Change Request Function Page Administering the Applicable Product System Page Administering the Change Request History System Page 5.4 Administering Change Request Workflow Enabling Change Request Workflow Options Creating Change Request Workflow States Editing Change Request States Deleting Change Request States Defining Change Request State Transitions Defining Change Request State Transition Rules Defining Change Request State Applicable Owners Defining Default Owners by Change Request State Defining State-Based Read-Only Change Request Fields Defining State-Based Mandatory Change Request Fields Defining State-Based Invisible Change Request Fields Chapter 6 DevSpec GUI Gustomization 6.1 Understanding DevSpec GUI Customization 6.2 Administering System Pages 6.3 Administering Function Pages 6.4 Administering Custom Pages Adding Custom Pages Adding Controls to Custom Pages Removing Controls From Custom Pages Ordering Controls in Custom Pages 6.5 Administering System Fields and Controls Understanding Specification Folder System Fields Understanding Specification System Fields Understanding Requirement Folder System Fields Understanding Requirement System Fields Understanding Change Request Folder System Fields Understanding Change Request System Fields Understanding Document and File Attachment System Controls Document System Control (1105) File Attachment System Control (1121) 6.6 Administering Custom Fields and Controls Understanding Control Types Customizing Check Box Controls Customizing Date-Time Controls Chapter 7 Event Administration 7.1 Understanding DevSpec Events 7.2 Administering DevSpec Event Templates Defining Event Templates Defining Default Event Titles and Descriptions Defining Default Event Workflow States Defining Default Event Owners Defining Event Template Scope 7.3 Administering Event Workflow Defining Event States 7.4 Administering Event Management Privileges Defining Event Management Privileges Chapter 8 Implementation Integration Administration 8.1 Understanding DevSpec Iterative Development Management Administration 8.2 Administering DevSuite Development Integration Enabling Baseline Support Defining Applicable Products and Versions 8.3 Administering Implementation Linking and Time Management Enabling Implementation Link Time Management Tools Defining Implementation Link Options Defining Applicable Implementation Modules 8.4 Administering Specification Backlogs Enabling Specification Backlog Management Defining Spec Management Options for Child Development Projects Defining State-Based Specification Assignment Rules Defining State-Based Pending Specification Linking Rules Defining Assigned Implementation Link Spec State Automation Defining Closed Link Specification State Automation Administering the Implementation Module Control Chapter 9 Time and Cost Analysis Administration 9.1 Understanding DevSpec Time, Cost, and Income Estimates 9.2 Administering Project, Time, Cost, and Income Estimation Settings Enabling Time and Cost Analysis Defining Time and Cost Analysis Preferences Defining Time/Cost Tracking Defining Time/Income Tracking Selecting Applicable Time Categories Updating Time Categories 9.3 Administrating Time, Cost, and Income Estimation Controls Administering Requirement Estimation Controls Administering Specification Estimation Controls DevTrack Projects Administration Chapter 1 DevTrack Concepts 1.1 Understanding TechExcel DevTrack and DevSuite Understanding DevSuite ALM Solutions Understanding TechExcel Project Hierarchy

8 1.2 Understanding DevSuite Administration Understanding DevSuite Site (System-Level) Administration Understanding Project Administration 1.3 Understanding DevSuite Sample Projects and Templates Understanding Sample Projects Understanding Project Templates Understanding Solution Templates Solution Guide Report Chapter 2 Project Administration 2.1 Understanding DevTrack Project Administration Understanding Projects 2.2 Understanding the DevSuite Admin Workspace Understanding Menu Bar Commands Understanding the Tool Bar Commands Logging into DevSuite Admin Opening DevTrack Projects Closing DevTrack Projects Understanding Keyboard Shortcuts 2.3 Administering DevTrack Projects Creating DevTrack Projects Backing Up DevTrack Projects Restoring DevTrack Projects Creating Projects Based from Backed Up Projects Copying DevTrack Project Settings 2.4 Overview Settings 2.5 Project Login Tip 2.6 Web Setup 2.7 KnowledgeWise/ DevSpec Integration Chapter 3 Team Administration 3.1 Understanding Team Administration 3.2 Administering Account Types, Access Controls, and Privileges Defining Account Types Enabling Advanced Access Control Support Enabling the New Issue Deletion Option Administering Issue Management Privileges Administering Invisible Pages and Fields (Standard Access Controls) Administering Read-Only Pages and Fields Administering On Submission Access Controls Administering On Existing Issues Access Controls Administering DevTrack Knowledge Management Privileges Administering Report Access Controls Windows Client Reporting Web Client Reporting Administering Subproject Management Privileges 3.3 Administering Project Members Adding User Accounts to Projects Editing Project Member Account Types Removing User Accounts from Projects Viewing Project Member Information 3.4 Administering Team Groups Defining Team Groups Adding and Removing Project Members to Team Groups 3.5 Administering Group Folders Defining Group Folders Chapter 4 Development Issue Administration 4.1 Administering General Settings for Main View GUI Design 4.2 Administering the Issue List Panel Adding or Removing List Columns Editing List Column Headers Changing Column Order Defining List Indicator Icons and Text Colors Displaying Note and Event Attachment Icons 4.3 Administering the Issue Detail Panel Defining Issue Detail Panel Page Order Customizing the Issue Detail Panel in the Windows Client Customizing the Issue Detail Page of the Web Client Multiple page display Single page display 4.4 Administering Function Pages Administering the New Issue Window system controls Defining Manager Options in the Windows Client Detailed action display Simplified action display Administering the Forward Issue Window Administering the Close Issue Window 4.5 Administering System Pages Administering the Issue Description System Page Administering the Issue Detail System Page Administering the Current Status System Page Administering the Notes System Page Administering the Link System Page 4.6 Administering Custom Pages Creating Custom Pages 4.7 Administering Page Design Adding Controls to Custom Pages

9 4.7.2 Ordering Controls in Custom Pages Removing Controls From Custom Pages Chapter 5 Methodology Support Administration 5.1 Administering Methodology Settings Settings for Agile Development Spaces Settings for Non Agile Development Spaces Other Methodology-related Settings 5.2 Administering Iterative Sub Project Templates 5.3 Administering Backlog Support Defect Backlog V.S. Release Backlog Using Backlogs Without DevSpec Implementation Link Time Management 5.4 Administering Implementation Module and Task Assignment Settings Chapter 6 Development Issue Workflow Administrati 6.1 Administering Development Issue Workflow 6.2 Configuring Project Workflow Enabling Transition-Based Workflow and Transition-Dependent Rules Enabling State-Based Workflow and Workflow Rules Enabling Transition Dependent Access Controls 6.3 Administering Issue Workflow States Adding Workflow States Deleting Issue Workflow States Defining State-Dependent Workflow Rules Defining State-Dependent Applicable Owner Access Controls Defining State-Dependent Default Issue Owners Defining Applicable Workflow States Defining State-Dependent Mandatory Fields Defining State-Dependent Read-Only Fields Defining State-Dependent Invisible Fields 6.4 Administering Transitions Adding Transitions Editing Transitions Defining Transition-Dependent Workflow Rules Defining Transition-Dependent Issue Management Privileges Defining Transition-Dependent Mandatory Fields Defining Transition-Dependent Read-Only Fields Defining Transition-Dependent Invisible Fields 6.5 Administering Transition-Dependent Master-Detail Relationships Enabling and Configuring Transition-Dependent Master-Detail Rules Defining Transition-Dependent Master-Detail Relationships 6.6 Administering Conditional Transitions Enabling Conditional Transition Support Defining Conditional Transition Rules Defining Conditional Transition Rule Conditions 6.7 Administering Inter-project Action Automations Defining State-Dependent Inter-project Automation Rules Defining Transition-Dependent Inter-project Automation Rules 6.8 Administering Issue Creation Triggers Defining Transition-Dependent Issue Creation Triggers Administering State-Dependent Issue Creation Triggers Chapter 7 Administering Advanced Features 7.1 Administering DevTrack Development Issue Routing Enabling Issue Routing Defining Issue Routing Rule Criteria Defining the Default Recipient of Routed Issues Defining Issue Routing Rules (Criteria) Defining Issue Routing Targets (Potential Owners) 7.2 Administering Personal Folders Enabling Personal Folder Support Defining Personal Folders 7.3 Administering Issue Templates Defining Issue Template Options 7.4 Administering Link Types Understanding Interproject Linking Defining Referential Link Types Defining Parent-Child Link Types Deleting Link Types 7.5 Administering Custom Crystal Reports Choosing DevTrack Reporting Platforms Defining Custom Crystal Report Template Folders Adding User-Defined Custom Reports 7.6 Managing Issue Priority Defining Priority Order Management Settings Defining Priority Value Management 7.7 Administering Status Groups Enabling Status Group Support Defining Status Groups Chapter 8 Issue Notification & Escalation Adminis 8.1 Administering Issue Notifications and Escalations 8.2 Administering the DevTrack Mail Service Managing Outgoing Server Settings Defining Issue Notification Sending Addresses Reloading Settings to DevTrack Mail Service Defining Issue Notification Activity Dates 8.3 Administering Issue Notifications Enabling Issue Notification in a DevTrack Project

10 8.3.2 Defining Issue Notification Rules Administering Issue Notification Triggers Defining Custom Issue Notification Status Change Triggers Defining Custom Field Change Triggers 8.4 Administering Issue Escalations Administering Issue Escalation Rules Understanding Issue Escalation Triggers Administering Issue Escalation Actions Administering Issue Escalation Schedules Chapter 9 Integration Administration 9.1 Administrating DevTrack Integration 9.2 Administrating the Retrieval Service Defining Incoming Mail Server Settings Defining Incoming Mail Server Properties Defining Autosubmit Settings 9.3 Managing Issue Submission by Understanding Advanced Issue Autosubmission The [Issue Properties] tag The [Description] tag Custom tags for multiple lines of text Chapter 10 Subproject Administration 10.1 Understanding DevSuite Subprojects Understanding Subprojects and the Beta Customer Portal 10.2 Administering Subproject Settings Enabling Subproject Support Defining Subproject Terminology Defining Default Subprojects Defining Applicable Issue Types 10.3 Administering Subproject Statuses Defining Independent Subproject Statuses Defining Subproject Status Based on Highest Ranking Defining Subproject Status Based on Lowest Ranking Defining Subproject Status Based on Issue Status 10.4 Administering Subproject Priorities Creating Independent Subproject Priorities Defining Highest Subproject Priorities Defining Lowest Subproject Priorities Defining Linked to Issue Subproject Priorities Chapter 11 Time and Cost Tracking Administration 11.1 Understanding DevSuite Development Time and Cost Tracking Understanding DevSuite Time and Cost Tracking Administration 11.2 Administering Time Groups and Categories Selecting Applicable Time Categories Enabling Time Tracking Enabling Cost Tracking Defining Project Time Tracking Methods Defining Hourly Rate by Account Type Defining Hourly Rate by User Account 11.3 Administering Time and Cost Tracking Privileges Chapter 12 Knowledge Management Administration 12.1 Understanding DevTrack Knowledge Management 12.2 Administering KnowledgeWise Integration Enabling KnowledgeWise Integration Enabling DevSpec Integration Migrating Knowledge View Data 12.3 Administering Project-level Knowledge Management Understanding KnowledgeWise Understanding Knowledge Items Understanding Knowledge View Access Controls Enabling the Knowledge View Selecting a Revision System Defining the Maximum Number of Revisions Customizing the Description Page Customizing the History Page Customizing the Resolution Page Backing up the Document Files 12.4 Administering Issue-level Knowledge Management Understanding the Notes Page Enabling the Notes Page Customizing Note Page List Columns Understanding Memo Field Time Stamping Managing Note Types Managing Note Access Controls DevTrack Projects Administration (Enterprise) Chapter 1 DevTrack Concepts 1.1 Understanding TechExcel DevTrack and DevSuite Understanding DevSuite ALM Solutions Understanding TechExcel Project Hierarchy 1.2 Understanding DevSuite Administration Understanding DevSuite Site (System-Level) Administration Understanding Project Administration 1.3 Understanding DevSuite Sample Projects and Templates Understanding Sample Projects Understanding Project Templates Understanding Solution Templates

11 Chapter 2 Iterative Development Administration 2.1 Understanding DevSuite Iterative Development 2.2 Administering Project-Level Iterative Development Specifying Iterative Development Terminology Defining Iteration Durations Resource Allocation on Iterations Iterative Subproject Templates 2.3 Understanding Implementation Modules 2.4 Administering Development Backlogs Specifying Backlog Terminology Chapter 3 Enterprise Edition Features 3.1 Understanding DevTrack Enterprise Edition 3.2 Administering the DevTrack Search Engine Installing the DevTrack Search Engine Defining Search Engine Settings Indexing the DevTrack Search Engine 3.3 Administering User Identity Authentication Chapter 4 Issue Types and Multiple Workflow Admin 4.1 Understanding Multiple Workflow and Issue Types 4.2 Administering Multiple Workflow and Workflow Assignment Enabling Multiple Workflow Defining Multiple Workflow Settings Defining Subworkflows Understanding Workflow Assignment Methods Defining Issue Type Subworkflow Initialization Granting Issue Type Assignment Privileges 4.3 Administering Issue Types Defining Development Issue Type Terms Linking Issue Type Property to Issue Property Fields Adding Issue Types Defining Default Issue Types Defining Issue Types Chapter 5 Development Event Administration 5.1 Administering DevTrack Development Events 5.2 Administering Event Groups Creating Event Groups Ordering Event Groups Ordering Event Templates within Event Groups 5.3 Administering Regular Development Event Templates Defining Regular Event Templates Editing Event Templates Defining Default Event Titles and Descriptions Defining Event Description Timestamping Rules Defining Default Event Workflow States Defining Default Event Owners Defining Default Event Start and Due Dates Defining Regular Development Event Attachment Rules 5.4 Administering Co-Owner Event Templates Creating Co-Owner Event Templates Administering Event Variables Enabling Co-owner Events and Event Variables Creating Unlinked Event Variables Creating Linked Event Variables Defining Co-Owner Event Attachment Rules 5.5 Administering Applicable Owners of Development Events 5.6 Administering Event Management Privileges and Access Controls Defining Event Access Controls Understanding Event Privileges 5.7 Administering Customer Access to Development Events Understanding Event Customer Access Rights Defining Event Customer Access Controls 5.8 Administering Event Workflow Chapter 6 Event Notification & Escalation Adminis 6.1 Administering Event Notifications and Escalations Notification and escalation triggers Push and pull notification subscriptions 6.2 Administering Event Notifications Enabling Event Notification in a DevTrack Project Defining Event Notification Rules Administering Event Notification Triggers 6.3 Administering Event Escalations Escalation triggers Escalation conditions Escalation actions Subscribers Administering Event Escalation Rules Understanding Event Escalation Triggers Administering Event Escalation Actions Escalation schedules Notification methods Event reassignment actions Administering Event Escalation Schedules Administering Event Reassignment Actions 6.4 Administering Event Notification and Escalation Conditions 6.5 Administering Event Notification and Escalation Actions

12 6.5.1 Identifying Notification Action Addresses Defining Event Notifications Defining Customer Notifications Defining Pager and Mobile Phone Notifications 6.6 Administering Potential Recipients and Subscriptions Identifying Potential Recipients of Notification Actions Potential recipient variables Customers as potential recipients Defining the Scope of Potential Recipient Variables Chapter 7 Beta Customer Portal Administration 7.1 Managing the DevTrack Beta Customer Portal Understanding the Beta Customer Portal Understanding Beta Customer Portal Security Understanding the Customer Manager 7.2 Managing Customer Base Projects Understanding Customer Base Projects Understanding the Customer Base Settings Page Associating Custom Base Projects with DevTrack Projects Creating New Customer Base Projects Defining Beta Customer Portal Login Settings Defining Parent-Child Relationship Support Defining Default Subprojects for Customer Base Projects 7.3 Customizing the Address Page of the Customer Manager Customizing the Address Page Defining Customer Types Defining Project Linking Options Customizing the Customer ID Control 7.4 Customizing Contact Info in the Customer Manager Customizing the Contact Info Page Defining Contact Access Types Defining Access Type Privileges Defining Project Access Controls 7.5 Managing DevTrack Customer Manager Privileges Understanding Customer Manager Privileges Defining Account Type Privileges Chapter 8 Interproject Actions and Linking Admini 8.1 Administering Interproject Actions and Linking 8.2 Administering Standard Interproject Actions and Linking Enabling Project-to-Project Integration Enabling Standard Interproject Action Support Enabling Interproject Link Support Defining Interproject Standard Action Settings Defining Interproject Editing Rules Defining Interproject Field and Field Value Mapping Defining Issue History for Linked Issues Defining Standard Interproject State Automation Rules Defining Interproject State Automation Rule Conditions 8.3 Administering System Interproject Actions Defining Clone System Interproject Actions Defining Submit System Interproject Actions Defining Copy System Interproject Actions 8.4 Administering Custom Interproject Actions Adding, Editing, and Deleting Custom Interproject Actions Defining Custom Interproject Actions Defining Custom Interproject Action Access Controls Defining Custom Interproject Action Applicable States 8.5 Administering Custom Interproject Action Automations Enabling Interproject Action Automation in Transition-Based Projects Enabling Interproject Action Automation in State-Based Projects Defining State-Dependent Interproject Automation Rules Defining Transition-Dependent Interproject Automation Rules Defining Interproject Action Automation Rule Conditions Chapter 9 Product, Version, and Build Administrat 9.1 Understanding Product Version Tree Administration 9.2 Administering Milestone Date Types Adding Milestone Date Types Editing Milestone Date Types Deleting Milestone Date Types 9.3 Administering the Product Tree Administering Product, Version, and Build Release Cycles Release status 9.4 Administering Applicable Products, Versions, and Builds 9.5 Administering Product Categories 9.6 Administering Products Defining Products Defining the Product Release Lifecycle 9.7 Administering Versions Managing Version Milestones Deleting Versions Managing the Version Release Lifecycle 9.8 Administering Builds Defining Builds Managing Build Release Lifecycle 9.9 Administering Product Implementation Modules Chapter 10 Subproject Administration 10.1 Understanding DevSuite Subprojects

13 Understanding the Subproject Tree Structure Understanding Subprojects and the Beta Customer Portal 10.2 Administering Subproject Settings Enabling Subproject Support Defining Subproject Terminology Defining Default Subprojects Defining Applicable Issue Types 10.3 Administering Subproject Statuses Defining Independent Subproject Statuses Defining Subproject Status Based on Highest Ranking Defining Subproject Status Based on Lowest Ranking Defining Subproject Status Based on Issue Status 10.4 Administering Subproject Priorities Creating Independent Subproject Priorities Defining Highest Subproject Priorities Defining Lowest Subproject Priorities Defining Linked to Issue Subproject Priorities Chapter 11 Branch Management Administration 11.1 Understanding Multiple Branch Management 11.2 Administering Branch Issues Enabling Branch Management Defining Branch Issue Types Adding, Editing, and Deleting Branch Issue Types Defining Default Branch Issue Types 11.3 Administering Branch Link Types Adding, Editing, and Deleting Branch Link Types Defining Branch Link Type Properties 11.4 Administering Branch Actions Adding, Editing, and Deleting Branch Actions Defining Branch Actions Defining Branch Action Privileges Defining Branch Applicable States Chapter 12 Branch Event Administration 12.1 Understanding Branch Events Enabling Branch Events Enabling In-frame Editing of Branch Events Defining Branch Event Templates Adding, Editing, and Deleting Branch Event Templates Defining Branch Event Template Attachment Rules Defining Branch Event Workflow States Managing Branch Event Access Rules Administering Branch Event Workflow Defining Branch Event Automatic Close Workflow Rules 12.2 Administering Advanced Branch Event Workflow Disabling In-frame Editing Defining branch event Advanced Workflow Rules DevTest Projects Administration Chapter 1 DevTest Concepts 1.1 Understanding DevTest Test Management 1.2 Understanding Test Management 1.3 Knowledge Management 1.4 Test Planning and Organization 1.5 Scheduling and Assigning Testing 1.6 Running Tests and Tracking Results Chapter 2 DevTest Admin Basics 2.1 Understanding the DevTest Administration 2.2 Understanding the DevTest Admin Workspace 2.3 Accessing DevTest Projects 2.4 Understanding the DevTest Administration 2.5 Understanding the DevTest Admin Workspace 2.6 Accessing DevTest Projects Chapter 3 Project Administration 3.1 Administering DevTest Projects 3.2 Administering General Project Settings 3.3 Administering DevTest Projects 3.4 Administering General Project Settings Chapter 4 Team Administration 4.1 Administering Work Project Privileges and Access Controls 4.2 Administering Team Groups 4.3 Understanding Team Administration 4.4 Administering Account Types, Access Controls, and Privileges 4.5 Administering Template Project Privileges and Access Controls 4.6 Administering Project Members 4.7 Administering Group Folders Chapter 5 Template Project Administration 5.1 Administrating Template Projects 5.2 Administrating Test Template Folders 5.3 Administering Test Templates 5.4 Administering Template Project Workflow 5.5 Administrating Environment Variables Chapter 6 Test Planning Administration 6.1 Understanding DevTest Test Planning 6.2 Administering Planning Folders

14 6.2.1 Customizing the Planning Folder Notes Page 6.3 Administering Planning Wizards Understanding the Release Wizard Understanding the Test Cycle Wizard Defining Wizard Page Titles and Descriptions Defining Coverage Update Warning Messages Displaying the Notes Page in Planning Folders Displaying Target Data in the Release Folder Editing Page Displaying Target Data in the Release Wizard Enabling Target Data Reporting 6.4 Administering Summary Reports Understanding Summary Report Columns Adding or Removing Summary Reports Defining Planning Summary Report Refresh Options Defining Display Names for Summary Report Columns Customizing the Summary Report Customizing the Test Coverage Summary Report Chapter 7 Test Task Administration 7.1 Understanding Test Task Management 7.2 Customizing Test Task Function Pages Customizing the Test Task Editing Function Page Customizing the Test Task Detail Function Page Customizing Test Task Forward Function Page Customizing Test Task Override Function Page Customizing the Test Task Group Change Function Page Customizing the Test Task Group Forward Function Page 7.3 Customizing the Test Task List Panel Adding or Removing List Columns Defining Test Task List Indicator Icons Defining Test Task List Text Formatting 7.4 Administering Test Task Workflow Understanding Task States Understanding Verification Points and Test Task Workflow Enabling State-to-State Transition Workflow Rules Enabling Applicable Owner Workflow Rules Enabling Read-only Field Workflow Rules Enabling Invisible Field Workflow Rules Enabling Mandatory Field Workflow Rules Enabling Access Control Workflow Rules Enabling Product Defect Submission Triggers Defining State-to-State Transition Workflow Rules Defining Applicable Owner Workflow Rules Defining Applicable Owners in the User Manager Defining Task State Access Controls Defining Read-Only Field Workflow Rules Defining Invisible Fields Workflow Rules Defining Mandatory Fields Workflow Rules Defining Defect Submission Trigger Workflow Rules Chapter 8 GUI Customization 8.1 Understanding the DevTest Clients Understanding DevTest Admin Understanding the DevTest Clients 8.2 Understanding Projects Understanding Project Hierarchy Understanding Knowledge Projects Understanding Template Projects Understanding Work Projects 8.3 Understanding Views Understanding the Knowledge View Understanding the Template View Understanding the Planning View Understanding the Task View Understanding the Report View Understanding the DevTrack View 8.4 Understanding Panels Understanding Tree Windows Understanding List Windows Understanding Detail Windows 8.5 Understanding Pages Understanding Function Pages Understanding System Pages Understanding Custom Pages Understanding Planning Wizard Pages 8.6 Administering Page Customization 8.7 Understanding Function Pages Understanding Applicable System Pages Chapter 9 DevTrack Integration 9.1 Understanding DevTest-DevTrack Integration Understanding System-Level Integration Understanding the DevTrack View 9.2 Administering DevTest-DevTrack System-Level Integration Enabling DevTest-DevTrack Site Integration Integrating DevTest with DevTrack Sites 9.3 Administering DevTest-DevTrack User Mapping and Privileges Manually Mapping DevTest Users to DevTrack Users Automatically Mapping DevTest Users to DevTrack Users

15 9.3.3 Exporting Users from DevTest to DevTrack Sites Importing User Accounts from DevTrack to DevTest Administering DevTrack View Privileges 9.4 Administering DevTrack Issue Submission Settings Defining DevTrack Issue Submission Settings Mapping DevTest Fields to DevTrack Fields Mapping DevTest and DevTrack Field Choices 9.5 Administering DevTest-DevTrack Interproject Searching Administering Custom Product Defect Search Fields to DevTrack Fields Chapter 10 Knowledge Administration 10.1 Understanding DevTest Knowledge Management 10.2 Administrating Project-Level Knowledge Creating Knowledge Folders Editing Knowledge Folders Defining Knowledge Folder Access Privileges Defining Knowledge Folder Build Privileges Defining Knowledge Project Field Labels Defining Knowledge Topic Page 10.3 Administrating Task-Level Knowledge Chapter 11 Notification Administration 11.1 Administering Notification Enabling Notification 11.2 Administering Notification Triggers Understanding Notification Triggers System triggers Custom triggers Defining Notification State Change Triggers Defining Notification Field Change Triggers 11.3 Administering Notification Recipients Understanding Notification Recipients Defining Notification Recipients Defining User Defined Address Lists 11.4 Administering Notification Conditions Defining Task State Notification Conditions Defining Keyword Notification Conditions 11.5 Customizing Message Templates Understanding Message Template Variables Subject line field content variables Body field name variables Body field content variables Defining Auto Message Templates Defining Manual Message Templates Defining New Test Cycle Message Templates Defining Subject Line Prefixes 11.6 Administering Integration Defining General Properties Authentication Character Sets Defining the Incoming Mail Server 11.7 Administering Escalation Enabling Escalation Understanding Escalation Rules Defining Escalation Rules Understanding Escalation Actions Defining Escalation Actions DevSuite Admin Guide DevSuite is a complete system for development process management. From requirements to project planning, work item tracking to QA testing, DevSuite allows team to follow configurable, integrated processes. DevSuite Overview and Common System Settings Chapter 1 Chapter 1- Understanding TechExcel DevSuite 1.1 Understanding TechExcel DevSuite TechExcel DevSuite is a family of integrated application lifecycle management (ALM) tools that place knowledge management?rom ideas and requirements to formal specifications, to competitive information to issue resolution and customer insight?t the core of any product development initiative. By facilitating access to information and communication between distributed development teams, DevSuite enables enterprises to improve the efficiency and quality of their end products. The DevSuite knowledge-centric strategy enables improve communication, keep up-to-date on changes, and reduce the development cycles so that the business may deliver the right products for the right markets in the shortest possible time. DevSuite enables distributed software development organizations to manage every aspect of the application development life cycle from the initial design in DevSpec, project planning in DevPlan, product development in DevTrack, and QA testing in DevTest. The foundation of all these processes is a common knowledge base managed in KnowledgeWise.

16 1.2 DevSuite Components DevSuite can be effectively used to help an organization build their development culture around best practices. Best practices and development guidelines are enforced and mandated by every team member activities. DevSuite individual products can also be independently used as point solutions for requirements management, issue and project tracking, and QA test management: DevSuite can be effectively used to help an organization build their development culture around best practices. Best practices and development guidelines are enforced and mandated by every team member activities. DevSuite individual products can also be independently used as point solutions for requirements management, issue and project tracking, and QA test management: 1.3 Understanding KnowledgeWise TechExcel DevSuite leverages intellectual assets with KnowledgeWise, communicating a clear product vision and tactical execution strategy by linking ideas and customer feedback, specifications, requirements, designs, prototypes, and other documents to specific areas of work. KnowledgeWise provides for the easy and efficient collection and organization of informal ideas, gathered from a

17 wide variety of sources. Some of these ideas will be discarded, many will be consolidated and improved, and others will be accepted as is, but this collection, organization, and refinement of knowledge is vital to the ultimate success of any development project. Documents are shared with all project stakeholders providing for complete access to the information that enable them to drive development projects. KnowledgeWise enables development organizations to build a knowledge base of shared knowledge in many different media? ocuments, URLs, knowledge topics. All documents may be linked with different areas of work so that internal teams and external customers can search the knowledge base for self-service content based on their access privileges. Existing knowledge base content can also be linked to other knowledge base management systems or by populating KnowledgeWise with thirdparty knowledge packs. 1.4 Understanding DevSpec TechExcel DevSpec provides development organization with a framework for creating, organizing, and managing software requirements and specifications that delivers visibility, traceability, and validation to all requirement management processes. DevSpec facilitates access of information and collaboration between internal and external stakeholders and team members so that good ideas are expressed in through requirements and well-defined specifications. DevSpec enables product manager to efficiently manage product requirements and specifications in one solution while any changes to requirements are controlled through a process. DevSpec has build-in report feature which allows users to generate a wide variety of reports. Using DevSpec, organizations may define a framework for creating and managing requirements and product specifications that may be linked to DevTrack development issues and DevTest test cases. 1.5 Understanding DevPlan TechExcel DevPlan enables development organizations to transform informal ideas and goals into formal strategic plans that optimize development planning, increase efficiency and collaboration, and control project workflow from design planning to implementation. TechExcel DevPlan is a tool for planning and managing the software development life cycle for distributed development teams Using DevPlan, project managers may design and document a fully conceptualized?esigned product?and plan and manage the implementation of that design within a single interface. The product that is described and documented in the control documents (business requirements, functional specifications, technical specifications, etc.) is articulated in the DevPlan client by a hierarchical tree structure that both represents the?esigned product?and is used to implement those designs. Every area of work is represented by a subproject folder in the subproject hierarchy. A subproject is a discreet area of work that corresponds to a specific product, feature, version, or build. The subproject hierarchy represents all of the products, features, versions and builds as subprojects in a hierarchical structure and clearly defines the relationships between each area of development. The subproject hierarchy is the framework for all planning and development so the documents linked to a subproject are accessible in both DevPlan and DevTrack. All project planning and project management tasks in DevPlan are based on a subproject tree structure that both represents the?esigned product?and work breakdown structure that will used to implement that vision. The subproject hierarchy, as defined in DevPlan, is visible in both DevPlan client and an integrated TechExcel DevTrack project. Project planning and implementation are managed within a common subproject hierarchy that enforces good development practices and accountability and enables collaboration between distributed teams The subproject tree structure as displayed in the DevPlan and DevTrack clients provides project managers, designers, and developers with a visual representation of the product or products in development. Managers and developers can see the product and its features in the tree structure and assess the status of all areas of development in the DevPlan client.

18 1.6 Understanding DevTrack Building on the strategic vision, deliverables and milestones of DevPlan, DevTrack manages the implementation process. DevTrack powerful and flexible framework coordinates workflow, notification, escalation, routing, version control, activity tracking, QA testing, multi-release management and much more. Once an area of development is ready for implementation, DevTrack ensures that teams execute their tasks within the context of DevPlan's project breakdown structure. Designs and specifications are easily viewable by the DevTrack user so that no work is performed without an approved concept driving it; managers can also quickly identify areas that require design and schedule brainstorming sessions, or presentations of completed designs, in order to refine their vision. The DevSuite Admin client enables system and project administrators to define a framework that enables the development team to manage every aspect of the development process. DevTrack tools are particularly focused on facilitating issue management, team management, and communications management?development teams to create, manage, and trackissues(new features, enhancements, product defects, and other development issues) andevents(sub-issues) in DevTrack projects. Administrator-defined workflow and process automation rules enable development teams to manage issues throughout the development life cycle.?devtrack facilitates team work between project members, development teams, and customers by providing all stakeholders with a central repository sharing information about individual issues and the project itself. 1.7 Understanding DevTest TechExcel DevTest is an integrated test management solution that enables QA organizations to manage the entire testing life cycle from test planning and team management to the analysis of test results. Using DevTest, organizations may define and manage release and test cycles, plan and assign test cases (calledtest tasks) to testing teams, execute test coverage, and submit product defects to an integrated DevTrack project. The DevTest knowledge-centric approach to test management ensures that the test team always has access to up-to-the-minute data for each phase of the testing life cycle. From test design to test execution and analysis, DevTest provides easily access to the knowledge items?ontrol documents?hat are needed to implement effective test management processes. Note: All DevTest system and project-level administrative tasks are performed in the DevTest Admin client, which is separate from the DevSuite Admin client.

19 1.8 Upgrade Steps: 1. Pleasebackup your Databasebefore performing the following upgrade procedure. 2. Uninstall DevSuite V831: 1) Uninstall Application server, Document Server and other V831 components one by one. Please keep the DevSuite Database Server. 2) Uninstall Web Server and Web Service: Please turn to Web Server machine and uninstall the DevSuite Web Server and Web Service. 3) Uninstall DevSuite Client (Admin & Windows Client): Please turn to the machine where installed DevSuite Admin or Windows Client Please check and see the shortcuts of DevSuite at Start menu All Programs TechExcel DevSuite, if shortcuts still exist, remove them manually. Notes:The following screenshot is based on the assumption that DevSuite V831 components are installed on one single machine. Thus this might be different from the actual configuration at your end. 3. Make sure DevSuite V831 files have been removed completely. We suppose that all the DevSuite V831 components are installed in default paths. 1) (In Web Server machine) Please check C:\Inetpub\wwwroot\PTWeb. If the folder still exists, please remove the folder PTWeb manually. 2) (In Web Server machine) Please check C:\Inetpub\Scripts\Texcel\DevTrack. If the folder still exists, please remove the folder DevTrack manually. 3) (In Client machine) Please check C:\Program Files\Techexcel\DevSuite. If the folder still exists, please remove the folder DevSuite manually. Note:PleaseDO NOTdelete the folderc:\program Files\Techexcel\DTServer\DocServerinDocument Servermachine. All documents and issue attachments are saved there. 4. Install DevSuite V831 Application Server Before installing DevSuite Application Server, please run following script in SQL Server: altertablelogindropcolumnportfolioprojectadmin Since database server has been previously installed, we ll start with the installation of App Server (DXAppServerSetup.exe). Turn to the machine where older DevSuite application server was installed, run thedxappserversetup.exe.

20 In the DevSuite Application Server dialog, if you want to change the default directory, click Change button to change the installation path. Otherwise click the Next button to continue. Chapter 2 Chapter 2- Understanding DevSuite Integration 2.1 Understanding DevSuite--CustomerWise Integration TechExcel DevSuite can fully integrate withtechexcel? CRM software?ustomerwise. CustomerWiseis anintegrated customer support and help desk solution, combining the power of the Web with sophisticated client-server applications. DevSuiteand TechExcel CustomerWise may be configured to share a common database, allowing development teams and customer support teams to easily collaborate and share datavia inter-project actions. When a customer support incident is an indication of a possible software defect, the support team may copy the incident from TechExcel CustomerWise into DevTrack as a new defect, to be managed and resolved by the development team. Conversely, DevTrack project members may create incidents in a TechExcel CustomerWise or TechExcel ServiceWise project from within a DevTrack project. A DevTrack project may share a common customer base project with a TechExcel CustomerWise project. Customer base projects enable project teams to manage customer contacts and grant access to DevTrack projects through the Beta Customer Portal. 2.2 Understanding DevTrack--VersionLink Integration DevTrack supports integration with many different third-party version control system applications including IBM Rational ClearCase, AccuRev, CVS, Serena PVCS, Perforce, and Microsoft Visual SourceSafe. Although the functionality of each version control system is different, DevTrack supports the following processes for each supported version controls system:?checking in files to the version control system and associating each check-in with an issue.?changing the progress state of an issue during a check out procedure from the version control system.?viewing an issue?/span>s associated file operations (check-in, checkout, and so on) and elements from within the DevTrack Windows client. Note: The majority of version control management tasks are performed in the integrated version control system application andnotin the DevTrack Client. Chapter 3 Chapter 3- Getting started with DevSuite Admin

21 3.1 Logging into DevSuite Admin Select the DevSuite Admin icon in the Windows Start menu.select from Start --> All Programs --> TechExcel DevSuite --> DevSuite Admin, and the DevSuite Admin Login dialog box appears. Enter a user name and password. Note: DevSuite Admin is delivered with the following default system administrator account User Name: Admin Password: (blank) The password is case-sensitive, but the user name is not. For security reasons TechExcel recommends changing the default login setting as soon as possible. To change web services, select an option from the Web Service dropdown list. The DevSuite Admin client connects to the DevSuite Application Server through the DevSuite Web Service. Changing the web service enables the client to connect to a different DevSuite Application Server and manage a different DevSuite site. You can also use the Ellipsis button to create a new web service connection: Click the OK button. The DevSuite Admin client opens. By default, the client displays the Project Setup page. To administer a project, open or create a project using tools in the File menu. Note:When you have DevTest joined as a component site to DevSuite, you will see both your DevSuite and DevTest projects using DevSuite Admin. 3.2 Understanding DevSuite Admin Workspace The DevSuite Admin client organizes the work area into two bars and two panels. The DevSuite Admin client is organized into four sections: Menu Bar:The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help menus. Tool Bar:The tool bar displays controls that enable administrators to perform system-level and project-level administrative tasks. Tree Panel:The Tree Panel organizes administration tools into a hierarchical structure consisting of folders and folders. Page Panel:The Page Panel displays form-based administrative tools that enable the administrator to configure and maintain system-leveland project-levelsettings.

22 3.2.1 Understanding menu bar commands Understanding tool bar commands Understanding keyboard shortcuts 3.3 Open DevSuite projects The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help menus. File:The File menu displays commands that enable the administrator to create, open, back up, restore work projects. Edit:The Edit menu displays commands that enable the administrator to manage text and GUI customization tasks. View:The View menu displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in the Admin client. Tool:The Tool menu displays commands that enable the administrator to perform a range of system-level administrative tasks including user, login, and license administration. Help:The Help menu displays commands that enable the administrator to access online help systems and information about the current build. Chapter 4 Chapter 4 - Understanding the DevSuite Administrat 4.1 Assigning Admin Roles to Users To assign a user an admin role, click the User Manager Icon button. The User Information dialog box of that particular user will pop up. to bring up the user list. Locate the target user, and click the Edit

23 Assign the appropriate administrator role to the user by ticking the corresponding check box. Note that when a user is assigned to be a system administrator, he or she also automatically becomes a division administrator and a project administrator. And when a user is assigned to be a division administrator, he or she also becomes a project administrator. Note: Starting in DevSuite 7, if a user is originally a project administrator with admin access to multiple projects and is switched to be a system administrator, he or she would then have admin access to every project. However, if the user is later switched back to be a project admin, he or she would lose the admin access to the original projects he or she belongs to. 4.2 DevSuite Administration In DevSuite, all system-level and project-level administrative tasks are managed inn the DevSuite Admin client. The DevSuite Admin client is a web service-enabled client that enables system and project administrators to define, configure, and administer TechExcel sites and projects. DevSuite system administration is the process of configuring, administering, and maintaining a DevSuite site. A site consists of a system settings project and one or more work projects?evtrack projects, DevSpec projects, and KnowledgeWise projects. Every work project in a DevSuite site shares a common database --knowledge base, and other system-level configurations that are defined in the DevSuite Admin client. There are two types of settings that can be managed in the Admin. System Settings--which include creating users, projects, multi-site settings, web server settings, document server settings, and many more.) These settings affect all projects within a DevSuite system. Project Settings-- which include which users belong to a project, the workflow a project follows, the user interface of the project, and other settings related only to the individual project which is opened. 4.3 Understanding Administrator Roles--System, Division, and Project All DevSuite site, system, and project administrative tasks are performed in the DevSuite Admin client. To access, configure and administer site, system, or project settings,the administrator? user account granted administrative privileges?ust open the appropriate?roject?in the client. DevSuite utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts?system administrator, division administrator, and project administrator account types. System:A system administrator is responsible for configuring, customizing, and managing the DevSuite site and all system-level settings. Division:A division administrator is responsible for configuring, customizing, and managing multiple work projects. Project:A project administrator is responsible for configuring, customizing, and managing a work project. Configurations defined in a work project apply to that work project alone. A company may have several active development projects

24 running concurrently and each project may have its own unique team structure and workflow. Chapter 5 Chapter 5- Administering DevSuite Projects 5.1 Administering Sample Projects In DevSuite, a sample project is a project that provides the development organization with a sandbox for configuring and evaluating features and integrations in a risk free environment. Using tools in DevSuite Admin, administrators may create sample projects or live projects based onexisting sample or liveprojects. Project administrators may freely configure sample projects to represent their development processes.?project configurations and settings tried and tested in sample projects may be imported into newly created?ive projects??sample projects provide development organizations with a tool for training new users or to introduce existing users to new features or changes in businesses processes. System administrators can click the Change button in the overview page in a project to convert a sample project to a live one, or vice versa. 5.2 Creating DevSuite Projects System Administrators can create new live projects, sample projects or project templates by clicking the New Project Icon The New Project dialog box enables administrators to define the project title, the project type, and to import project settings from previously-defined projects. 1. Project Name: Enter the project title. Do not use the following characters in the name of the project:/ \ :??< > 2.Create Project As: Select one of the three radio buttons to indicate the project class of the new project. It can be a live project, a sample project or a project template. 3.Project Type: There are three project types for administrators to choose from: Development Management

25 (DevTrack), KnowledgeWise project, and DevSpec Project. Select the appropriate kind, and indicate corresponding KnowledgeWise or DevSpec project if needed. 4.Copy Settings from: A new project must copy project settings from either a project template or a live/sample project. Select the project from which the newly created project wishes to copy. Click the OK button when the information above is correctly specified. A new project is created successfully. 5.3 Administering DevSuite Projects In DevSuite, a project is a tool for storing, organizing, and managing incident, event, employee, asset, knowledge, and project team data. Every DevSuite implementation?alled adevsuite site?ay consist of multiple types of work projects including development projects, KnowledgeWise projects,devspec projectsand DevTest projects. All projects in a DevSuite site are organized into a hierarchical structure that defines the relationships between the projects in a DevSuite site. Every DevSpec or DevTrack project is the child of a parent KnowledgeWise knowledge management project and relies on that project to manage project intelligence. As seen from the above diagram, multiple DevTrack projects can be created based upon a single DevSpec project. On the other hand, standalone DevTrack projects can also be created. Note that even a standalone DevTrack project has to be based on a KnowledgeWise project. 5.4 Administering Project Templates In DevSuite, a project template is a blueprint for creating a project of a specific type?knowledgewise knowledge management projects, DevSpec requirements management projects, or DevTrack development projects. Each project template defines a complete set of project-level settings including the definition of all project business objects, workflow rules, team representation, and project integrations. Project templates may be used to quickly configure new projects whenever they are created in a DevSuite site.unlike sample and live projects, project templates can only be accessed from DevSuite Admin Client. Regular users cannot get access to project templates from Windows or Web Client. 5.5 Backing Up DevSuite Projects DevSuite stores backups of DevTrack projects in a proprietary DTK file format. Once the administrator definesthe project information, the administrator may back up either the entire database or only selected projects. DevSuite Admin creates the backup file with the selected project data. DevSuite Admin stores backed up projects in a proprietary DTK file format. To backup DevSuite projects: 1Invoke the Back Up Project command:?select File > Back Up Project in the menu bar.?press CTRL + B.?Click the Backup Project Icon. The Back Up Project dialog box appears.

26 2Click the Ellipsis button to navigate to the location of the backup file. The Backup dialog box opens. 3Navigate to the location of the backup files. 4Enter a name for the DTK file in the File Name field. 5Select the DevTrack Backup File (DTK) option in the Save as Type dropdown list. 6Click the Save button. The Backup dialog box closes. 7Select a back up option:?click the Whole Database radio button to backup all projects in a DevTrack implementation.?click the Selected Projects radio button to backup some, but not all projects in a DevTrack implementation. Highlight the projects to be backed up. 8Click the OK button. The project is backed up. 5.6 Understanding Project Class, Project Type and Project Status Every project in the DevSuite Site must be one of the three project classes: live project, sample project or project template. Every project in the DevSuite Site must be one of the three project types: development projects (DevTrack), KnowledgeWise projects or DevSpec projects. Every project in the DevSuite Site must be one of the two project statuses: Active or Inactive.

27 5.7 Understanding Active and Inactive Projects Every DevSuite project has either an active or inactive status. The status of a project determines the tasks that an administrator may perform on that project. Administrators define the status of a project by selecting the Active Project check box in the Overview page. Active Projects---Administrators may perform the following tasks using active projects:?administrators may open active projects in Admin and configure project settings.?administrators may use the User Manager to add user accounts as project members to active projects.?administrators may import project properties from Active projects. Inactive Projects---Administrators may perform the following tasks using inactive projects:?inactive projects may be deleted using the Delete Project command. Active projects cannot be deleted. Note:Sometimes system administrators may find that the Is Active Project check box in the overview page is grayed out. The reason might be that there are still active projects depending on this project, which makes the conversion from active to inactive impossible. 5.8 Administrative Tasks Performed by System Administrators A work project is a tool for storing and managing work item and event data. The work items managed and tracked in a project are project-specific: development issues in DevTrack, test templates and test tasks in DevTest, and specifications, requirements, and change requests in DevSpec. Every work project represents a distinct area of work and is defined by unique team structures (account types, team groups, and group folders) and workflow rules. Generally, the configuration and customization of work projects is the responsibility of a project administrator. However, many project administrative tasks are the responsibility of the system administrator. System administrators may create, delete, open, close, back up, and restore work projects and work projects in the General System Settings folder of the DevSuite Admin client. System administrators may create, delete, open, close, back up, and restore DevTrack projects using tools in the File menu of DevSuite Admin. 5.9 Restoring DevSuite Projects DevSuite stores backups of DevSuite projects in a proprietary DTK file format. Administrators may choose to back up selected projects or the entire database. When restoring backed up DevSuite projects administrators may overwrite existing projects or create new projects based on the backed up projects. To restore DevSuite projects: 1Invoke the Restore command.?select File > Restore in the menu bar.?press CTRL + R.?Click the Restore Project Icon The Restore Project dialog box appears. 2Locate the backed up project. DevSuite stores backups of DevSuite projects in a proprietary DTK file format. 3Click the Open button. The DevSuite Restore II dialog box appears. Specify whether to restore the documents or not. Click OK to close the dialog box.

28 4 Another dialog box appears, displaying the Project ID number of the project to be restored. 4Specify the Restore options. System administrators can choose either to overwrite existing project with the same ID or create new project by giving the project a new name. 5Click the OK button. The project is restored. If the DTK file selected contains multiple backed up, the DevSuite Restore dialog box would appear for each backed up project Deleting DevSuite Projects System administrators may use the Delete command to delete inactive projects.note that administrators may only delete projects that have an inactive status.for instructions on making a project inactive see To delete a project: 1Select File > Delete, or click the Delete Project Icon. 2The Delete Project dialog box appears. The Delete Project dialog box displays all of the projects that may be deleted. Only those projects that have an inactive status may be deleted. 3Select a project. 4Click the Delete button. Note:Deleting a project from the system is permanent. Administrators must perform all appropriate back ups before deleting a project. Chapter 6 Chapter 6- User & License Management 6.1 Understanding System-Level User Administration System-level user administrative tasks include license management and allocation, user account creation and definition, and the management of project administrators. Optional system-level administrative tasks include multiple site management, division management, and LDAP directory server integration and administration. 6.2 Administering User Licenses TechExcel offers many different varietiesoflicenses to development organizations that purchase DevSuitesoftware, and the licenses purchased by these development organizations determine the features available within the DevSuiteimplementation.

29 DevSuitelicenses are divided into four different categories: License Edition:The License Edition defines the version of the DevSuite software purchased. DevSuite Solution Pack is available for either Team Edition or Enterprise Edition. Site License:The Site License defines whether Multiple Site support is available in the DevSuite implementation. Multiple Site licenses are only available to users of the DevSuite Enterprise Edition. License Class:The License class defines the duration of the license. TechExcel offers three classes of licenses: evaluation licenses, permanent purchased licenses, and limited-time purchased licenses. License Type:License types represent the number of seats that are available in a DevSuite site. DevSuite supports three types of licenses: Fixed licenses, Floating licenses, and Light licenses Understanding License Edition Understanding Site License Understanding License Class Understanding License Types Loading DevSuite License File Tracking DevSuite LIcenses 6.3 Administering User Accounts The License Edition defines the version of the DevTrack software purchased. DevSuite is available in two editions: DevSuite Team Edition and DevSuite Enterprise Edition. A DevSuite Team Edition licenseenables development teams to use all the standard DevSuite features. DevSuite Enterprise Edition features (Subprojects, Events, Beta Customer Portal, and so on) are not available. Development teams may purchase any number of fixed licenses and floating licenses. Development teams may also purchase support forlicensed modules. Although many DevSuite Enterprise Edition configuration tools are displayed in DevSuite Admin, these features cannot be enabled or configured in the DevSuite Team Edition. Purchasers of the DevSuite Team Edition may purchaselicensed modules. Every DevTrack Standard Edition license includes information about the modules purchased. If the modules are not enabled in the license, these features cannot be accessed using that license. DevTrack Web DevTrack Web for Customers DevTrack QA Test Management DevTrack Offline Support Version Control Support Power Beta Customer Support Search Engine Support LDAP Support A DevSuite Enterprise Edition licenseenables development teams to use all of the features in the DevSuite Standard Edition plus a number of features that are only available in the Enterprise Edition. DevSuite Enterprise Edition features include: Advanced access controls Subprojects Personal folders Event management

30 Event notification Event escalation Beta Customer Portal DevTrack Search Engine DevTrack Multiple Sites Multiple workflows Purchasers of the DevSuite Enterprise Edition may purchase any number of fixed licenses, floating licenses, and light licenses. Light licenses enable customers to access DevTrack projects through the Beta Customer Portal. TechExcel provides 100 light licenses with every purchase of the DevTrack Enterprise Edition. Purchasers of the DevTrack Enterprise Edition may purchaselicensed modules. Every DevSuite Enterprise Edition license includes information about the modules purchased. If the modules are not enabled in the license, these features cannot be accessed using that license Creating User Accounts 6.4 Administering User Logins TechExcel offers purchasers of the DevSuite Enterprise Edition two types of site licenses: Multiple Site licenses and Single Site licenses. Multiple Site License:Multiple Site licenses enable development organizations to create site families and to share licenses across multiple DevSuiteimplementations (sites).each site belongs to one of three site types: System master sites, work sites, and stand-alone sites. Single Site License:Single Site licenses do not support site families. All DevSuiteimplementations using a Single Site license are stand-alone sites Viewing the Login Status Of Project Members Managing Idle Timeout Settings Viewing Login History Logs 6.5 Administering Divisions The License class defines the duration of the license. TechExcel offers three classes of licenses: evaluation licenses, permanent purchased licenses, and limited-time purchased licenses. Evaluation License:An evaluation license is a free license that enables the users to evaluate DevSuitefor a short time period: 15 days, 30 days, or 60 days. Evaluation licenses are available for DevSuiteEnterprise Edition. Limited-Purchased License:Alimited-purchased license enables the users to work in DevSuiteapplications for alonger limitedtime period.limited-purchased license is ideal for customers to use in the test server, where new build can be tested before rolling out to the production server. Limited-purchasedlicenses are available for the DevSuite Team Edition and the DevSuiteEnterprise Edition. Purchased License:A purchased license enables the users to work in DevSuiteapplications for an unlimited time period. Permanent licenses are available for the DevSuite Team Edition as well as the DevSuite Enterprise Edition Managing Divisions Chapter 7 Chapter 7- Administering DevSuite-DevTest Integrat 7.1 Understanding DevSuite-DevTest Integration Although DevSuite officially consists of KnowledgeWise, DevSpec, DevPlan, DevTrack and DevTest, currently DevTest is always installed using a separate database to the other applications. For this reason it is necessary to do a small amount of configuration after installation to enable DevSuite and DevTest to share the same admin console as well as information such as license and user data. The integration also provides the ability to link requirements, specifications or knowledge items created in DevSpec to test

31 templates in DevTest. We do this by joining DevTest as a component site to the Master site DevSuite. 7.2 Guide to Administering DevSuite--DevTest Integration To join DevTest as a component site to the DevSuite family, we need to first configure the settings in Devtest Application Server Configuration window and then perform site join in DevSuite Admin Client. 1. Set DevTest as a component site to DevSuite During the DevTest application server installation (or you can later bring this window up from the Start menu), in the Parent DevSuite System Info section, select "Configure as a component of a DevSuite site" option and specify the DevSuite application name. This could be the server host name, server IP or even the fully qualified domain name. Keep the port number to the default (8228) unless your DevSuite system is running under a different port. Use the Test button to confirm the connection. Once the connection is successfully make, the System Name would be automatically populated (by pulling the information from your DevSuite sytem) with the join status listed as "To be joined". At this point if you bring up the DevSuite application configuration window, similar information regarding DevTest component system is also pre-populated: 2. Join DevTest as a component site in DevSuite Admin Client Launch DevSuite Admin Client and log in with your Administrator account. You should see DevSuite and DevTest listed as available sites in the background upon login. Use the "Open Project" icon or File--> Open Project menu to launch the project selection window. Note that two systems would be listed respectively on the top. When selecting TechExcel DevSuite system, all the Knowledgewise, DevSpec, DevTrack projects are displayed below, while selecting TechExcel DevTest system gives you accesss to all available DevTest template and work projects. Note that after the site join, you will no longer see the system selection section. Instead, all DevSuite and DevTest projects will be listed alltogether in the project selection pane. Select TechExcel DevTest system and once the project selection pane refreshes to display the DevTest projects, then go to System Settings.

32 In the DevTest System Settings project, go to Site Settings --> Site Info. Click on the Join button underneath the Current System section, as shown below. A warning message stating that the component join might require some time, thus you need to make sure the connection timeout defined in IIS is sufficient. How do I cofigure IIS connection timout? To change the connection timeout setting in IIS 6, right click on Default Web Site and select Properties. Extend your connection timout seconds in the Web Site tab. To change the connection timeout setting in IIS 7, select the Default Web Site and in the Actions pane, select Advanced Settings. Extend your connection timout seconds in the Connection Limits section: What if I don't see the Join button? Make sure the system Admin account type you belong to does carry the privilege for multisite management. To check what system account type you belong to, launch DevSuite User Manager and locate your account. You can locate the system admin account type info in the User Information tab.

33 Then open DevTest System Settings project and go to Administration Account Type --> System Account Type page. Select the system account type you belong to and make sure "multisite management" privilege is checked. Go back to the Site Info page and you should see the Join button now. 3. Site Join Process The component join process would start to take place after the "OK" confirmation button is pressed in step 2. The first half part of the join mainly involves resolving the user ID as well as the project ID conflict between the two sites, as the user IDs and the project IDs now have to be unique across two systems. Therefore, when the system detects an ID overlap, a new ID will be assigned to the item (it could be a user or a project) in the component site. Follow the site join wizard to complete the join process. Note that it's possible that you won't see all the windows listed below. --Check if any of the existing users in DevTest are new users in DevSuite. --Resolving projectid conflict

34 --Resolving user ID conflict by updating user IDs in the component site --Joining DevTest to the DevSuite system Once you click the Finish button, you will be prompted with the message informing you that the join has been done successfully. 7.3 Guide to enabling DevSpec/KnowledgeWise integration in DevTest Once you have 1. DevTest Admin -- Associate DevTest template projects with DevSpec and KnowledgeWise projects Open DevTest Admin Go to 'File', 'Open project', and open the 'template base' project you want to integrate with DevSpec. The 'work projects' linked to this 'template base' project will be associated automatically. Go to the 'Overview' page. Click the lower 'Change' button. Select a KnowledgeWise project. Tick the 'Enable DevSpec Integration' box. Select a DevSpec project. Click 'OK'.

35 2. DevTest Admin -- Add the 'All Links' page to the Template View In the template base project, go to 'Template GUI Settings', 'Function Pages', 'Detail Pages'. Add 'All links' page to the working page section. Repeat these steps for the 'Editing Pages'. 3. DevTest Admin -- Add the 'All Links' page to the Task View In the work project, go to 'Test Task GUI Settings', 'Function Pages', 'Detail Pages'. Add 'All links' page to the working page section. Reload the Web Settings. Note:You may need to restart the server in order to get the 'All Links' pages to show. Chapter 8 Chapter 8- Administering Multisite Deployment 8.1 Understanding DevSuite Multisite Imagine a global corporation with users accessing DevTrack that's hosted in US from Europe and Asia. The data sent by those remote users have to travel across the ocean to hit the web server and then the database, and don't forget that it's another journey for the response to be passed back to the user end. With the new DevSuite multisite deployment, the scenario mentioned above would no longer be a concern. DevSuite now supports the Distributed Site concept where local work sites can be established with its own database and web server. By joining the work sites with the system master site, users will be hitting the local system while the data is in sync with all other sites at real time. For example, when a user in Japan enters a bug in DevTrack in the local system, users in US or Eurpose would see the new bug right away in the systems they are accessing.

36 8.1.1 Steps to deploy a Multi-site envrionment 8.2 Guide to Creating a DevSuite Multi-Site Family Below is a quick list on the steps for Multi-site deployment: Set up the master site and the regular work sites with their own DevSuite system. Note that a site can contain both a DevSuite db and a DevTest db. Please join DevTest as a component site to DevSuite in each site if applicable. Set up site join between the master and the regular work sites. Distribute projects from the master site to the regular work sites or vice versa. Detailed information regarding these steps is included in the remaining guide. 8.3 Guide to distributing Local Projects to Other Sites Once sites are joined, in order for a local project to be accessed in other sites, we need to distribute it to one or all sites in the Admin Client. You can do so in the Site Projects page under Site Settings folder in the System Settings project. The "Distribution Status" column in the Projects panel tells you whether a poject is local (meaning the project is rooted in the system you are looking at) or distributed (meaning the project was originally rooted in other systems and got distributed to this site). To make a local project appear in one or all other sites, follow the steps below: In the Site Project page, highilght the project you would like to distribute. Click on the "Distribute..." button. Select one or multiple sites you want this project to be distributed to. Click OK. After you do so, two records would show up in the Sites panel indicating that the project is ready at the local site but is not ready at the other site. In order to get the other site ready, an activation file needs to be generated and loaded on the other system.

37 At this point, the "Generate Activation File..." button should become clickable. Click on the button and save the activation file to a location where you can easily find later. Copy the activation file to the other system (or you can connect using the same Admin console by configuring the web service connection upon login). Go to Site Settings --> Site Project and you should see the project you just distributed listed as a "Distributed project" in the panel. Highlight the project and click on the "Load Activation File..." button and browse to the dsprj file. The system would start restoring the project. When it's done, you will be prompted with the message below, and the sync status for both sites will now listed as "Ready".

38 Chapter 9 Chapter 9- LDAP Directory Server Integration 9.1 Administering Directory Server Integration A directory service stores and organizes information about the resources on a network?ncluding addresses, computers, and peripheral devices such as printers. The directory service provides a centralized database that enables network administrators to manage access to these resources by applications and users. A directory service organizes content in a directory server into a logical and accessible structure and acts as a central authority that can securely authenticate resources and manage identities and relationships between them. DevSuite-directory server integration enables administrators to manage user data (user names, phone numbers, passwords, and so on) in a directory server rather than in individual DevSuite projects or sites. Once the system administrator has integrated the DevSuite site with their directory servers,they may use LDAP to manage user accounts and logins:?system administrators may import user data from an LDAP server into a DevSuite site.?system administrators may enable LDAP directory server authentication for all projects managed in a site. An LDAP server is usedtoauthenticate users logging into DevSuite projects usingdomain user accounts. Understanding Integration Tasks In TechExcel DevSuite, all LDAP directory server integration and authentication are defined at the system-level in the DevSuite Admin client. System administrators are responsible for enabling and defining DevSuite-LDAP directory server integration settings, enabling and definingdevsuite authentication settings, and mapping DevSuite user account properties to LDAP user attributes. All system-level LDAP directory server integration tasks are performed in theldap Integration folderof the System Settings project in the DevSuite Admin client. DevSuite-directory server integration is a four-step process: 1Register one or more LDAP directory servers. Every integrated directory service is defined by its name and directory server type. 2Define DevSuite field-ldap attribute matching identifiers. 3Map DevSuite fields to LDAP attributes. 4Define LDAP directory server user authentication settings. An LDAP directory server may be used to authenticate users logging into projects using Windows-based clients.

39 9.2 Administering LDAP Directory Server Registration DevSuite enables DevSuite site integration with multiple LDAP directory servers. As a first step towards integration, every directory server must be?egistered?in the System Settings project. Directory server registration defines the directory server type, and connection settings. Using controls, in the LDAP ServerSetting page, system administrators may define the list of directory services that are used in the DevSuite site. DevSuite supports integration with three types of LDAP directory services: MS ADAM, MS Directory, and Other Directory Servers. MS ADAM:Microsoft ADAM (Active Directory Application Mode) is a flexible LDAP directory service that runs as a user service, rather than as a system service. MS Directory:Microsoft Active Directory is a network operating system directory that enables administrators to manage enterprise-wide information from a centralized repository. Other Directory Servers:In DevSuite, the termother LDAP Serversis used as a catchall term to refer to non-active Directory server types?he directory services software and standards that define an LDAP server. System administrators must identify LDAP servers and define the LDAP server name, the server type before they can define the LDAP directory service settings. To register an LDAP directory server: 1Select the LDAP Server Setting page in the LDAP Integration folder of the System Settings project. All LDAP integration tasks are performed in the System Settings project in the DevSuite Admin client. 2Click the New button. The New LDAP Server dialog box appears. 3Define the name and server type. The server name may be any name that enables the administrator to identify the LDAP server within DevSuite. DevSuite supports Microsoft ADAM, Microsoft Active Directory, and other LDAP server types. 4Click OK. The LDAP server is displayed in the LDAP Server List of the LDAP Server Setting manager. After selecting the LDAP server and defining its name and server type, the administrator may define the LDAP server connections. ToDefineConnections toanldap Directory Server LDAP directory serversettings identify the location of the directory service, connection settings (including username and passwords), and the search filter that selects the data to be imported from the directory server. On the LDAP Server Setting page, highlighting the LDAP server previously defined and clicking the Server Info button,system administrators may define, update, and test LDAP server connections, define a DN path and password to access appropriate data, and define a search filter to limit the scope of LDAP data accessed. Server Name:The Server Name is a name that identifies the registered LDAP server in the DevSuite system. Host Name:The hostname identifies the server machine that hosts a particular LDAP directory server. The devices on a network are uniquely identified by their hostnames. Port:A port number is a specific number that is used to map data to a particular process running on a computer. In a DevSuitedirectory server integration, the port number identifies the channel over which data is communicated between the DevSuite and the directory server. For example, port 389. User DN and Password:A distinguished name (DN) is a collection of attributes (relative distinguished names) that uniquely reference an object in the directory tree?uch as a user account. The DN may consist of a common name (CN) and one or more domain name components(dc). For example, CN=users,DC=mydomain,DC=com The user DN identifies the DN that is used to access LDAP directory server data. The user DN must be accompanied by the corresponding password. Server Type:The Server Type identifies the LDAP directory service application that represented by the integrated directory server. Search Filter:The search filter identifies the attribute to be imported from the LDAP directory server. For example, objectclass=user Attribute Name of the User ID/GUID:The User ID/GUID identifies the LDAP attribute that corresponds to the DevSuite User ID property.for example, SAMAccountName Steps to define a connection to an LDAP directory server:

40 1.Select a LDAP directory server in the LDAP Server List. System administrators must register an LDAP directory server before they may define LDAP directory server connection settings. 2.Click the Server Info button. The LDAP Server Information Setting manager appears. 3.Define or update the server name and hostname in the Server Setting tab.?the server name is any name that identifies the LDAP server within DevSuite Admin.?The host name is the name of the machine hosting the LDAP directory server. 4.Define the port number in the Port text box. 5.Optional: To test the connection to the LDAP server, click the Test button. The LDAP Server Information manager tests whether DevSuitemayaccess the LDAP server through the defined host and port number. 6.Define theuser DNaccount and password: The sync user DN identifies the DN that that is used to access and synchronize LDAP directory server data. The sync user DN must be accompanied by the corresponding password.an example of the User DN can becn=users,dc=mydomain,dc=com 7.Define or update the server type by selecting and option from the Server Type dropdown list. The Server Type dropdown list displays the server type selected when the LDAP directory server was registered. 8.Define a search filter.the Search Filter identifies the LDAP directory field that is to be imported.an example of a search filter would beobjectclass=user. Always use a search filter. If no search filter is defined, DevSuite imports all data contained in the root directory. 9.Optional: To confirm that DevSuite can connect with the LDAP server,select theattribute Name of theuserid/guid control. The data displayed in the Attribute Name of the UserID/GUID control is drawn from the LDAP server. If no data is displayed in the UserID/GUID control,that meansdevsuite cannot connect to the LDAP server. Confirmif the UserDN and password are correct. 10.Define an attribute name for the User ID/GUID. For example,samaccountname.the User ID/GUID identifies the attribute that corresponds to the DevSuite User ID property. 11.Click the OK button. 9.3 Administering Field-Attribute Matching Identification Matching identifiers are sets of mapped DevSuite user account properties and LDAP attributes that are used by the DevSuite to identify mapped pairs of DevSuite user accounts and LDAP user accounts. Defining the Search Root The search root for user accounts is a DN (distinguished name) that identifies the root directory for team member accounts in the directory server. A distinguished name consists of container name (CN) and one or more domain controls (DC). For example, CN=users,DC=mydomain,DC=com. The root directory represents the LDAP directory that contains project member information. DevSuite searches all subfolders within the root directory for user data matching the search criteria defined in the Search Filter control of the Server List page. To define the search root: 1Select a registered LDAP server in the LDAP Server List of the LDAP Servers Setting for User Import & Sync page. 2Click the Setting button. The LDAP Servers Setting for User Import & Sync manager appears. 3Select the General Setting for Import and Sync tab 4Define the root for user account data in the Search Root for Team Members text box. The root directory represents the LDAP directory that contains user information. DevSuite searches all subfolders within the folder for user data matching the search criteria defined in the search filter 9.4 Administering Field and Attribute Mapping Please input description. 9.5 Administering LDAP Directory Server Authentication 9.6 Importing User Accounts from a LDAP Server

41 DevSuite-LDAP directory server integration enables administrators to manage user data (user names, phone numbers, and so on) in a directory server instead of their DevSuite sites. System administrators may import user account attributes from an integrated LDAP server into a DevSuite system settings project using the LDAP Import wizard. The LDAP Import wizard enables administrators to quickly create or update project user accounts by importing data from an integrated LDAP server. While importing user data, the administrator may also assign a license to the user. Note:System administrators that plan to useldapto authenticate user logins into the DevSuite clients must redefine the passwords of user accounts imported from an LDAP directory server. LDAP passwords are encrypted and cannot be imported into DevSuite system settings projects from LDAP directory servers. To import user account attributes: 1Click theusermanager icon in the tool bar. TheUserManager appears. 2Click the Import button. The Select a User Import Source dialog box appears. 3Select the Import from LDAP option. The Select Support Members wizard appears. 4Select an LDAP Server from the LDAP Server dropdown list. DevSuite must be integrated with an LDAP server, otherwise no optionswould bedisplayed in the LDAP Server dropdown list. 5 Optional: To search for user accounts based on the first name of the user, enter a query string in the First Name control. To filter user accounts based the first name of the user, the appropriate LDAP attribute must be mapped to the DevSuite First Name field. For example, the DevSuite First Name field may be mapped to the LDAP givenname attribute. System administrator may use the asterisk * wild card character to search for text strings in the First Name control. 6 Optional: To search for user accounts based on the last name of the user, enter a query string in the Last Name control. To search for user accounts based on the last name of the user, the appropriate LDAP attribute must be mapped to the DevSuite Last Name field. For example, the Last Name field may be mapped to the sn attribute. System administrator may use the asterisk * wild card character to search for text strings in the Last Name control. 7 Optional: To search for user accounts based on any LDAP user account attribute, enter a query string in the Search Filter control. The query string entered in the Search Filter must identify both theattributeand theattribute value. For example, the query sn=smith returns all LDAP user accounts with the last name?mith? System administrators may define complex queries using four logical operators in the Search Filter control: The asterisk wildcard character, the ampersand & AND operator, the pipe OR operator, and the exclamation point! NOT operator. 8Click the Search button. Data matching the search parameter defined is displayed in the LDAP Users list. 9Add or remove users to the Selected Users list.?click the Add button to move users from the LDAP Users list to the Selected Users list.?click the Remove button to move users from the Selected Users list to the LDAP Users list. 10Click the Next button. The Select Users to be Overwritten page appears. 11 Optional:To overwrite properties of existing user accounts with their mapped LDAP attributes, select one or more user accounts. Any LDAP user accounts that match existing DevSuite user accounts based on administrator-defined matching identifiers is displayed in the Select Users to be Overwritten page. 12Click the Next button. The License Assignment page appears. 13Select one or more user accounts in the User list and click the Assign License button. The Select a License Type dialog box appears. 14Assign appropriate licenses to the user. 15Click the OK button. The Select a License Type dialog box closes. 16Click the Finish button. The user accounts are imported into the DevSuite system settings project Filtering User Accounts in the LDAP Import Wizard DevSuite System Settings Administration Chapter 1 General System Settings Administration 1.1 System Level General Settings

42 You can view/define the following information in DevSuite System Settings --> System Settings --> General Settings: Database Memo Field Size:The system will display the type of database (Microsoft SQL Server, Oracle Database or MySQL) your DevSuite system is currently runnning on as well as the maximum memo field size limit that's currently being set to. The memo field size setting controls how many characters can be entered in the memo field/text box controls throughout the system, such as the Description field. Please note that the setting would appear to be read-only to you. Please contact TechExcel Support if you wish to expand the memo field size in order for users to enter more data. Issue ID Uniqueness:You can define whether the Issue ID is unique for each project or across the entire system. By default it is set to be unique at the project level. Please note that this setting would also appear read-only to you. Please contact TechExcel Support if you think there is a need to change this. "Task" renaming:in DevTrack, by default we refer to a ticket that's being entered in the system as a "task". You can change this naming convention to better fit your scenario if needed. 1.2 Managing Applicable Applications There are six modules within the DevSuite umbrella and admins can choose/update which are the applicable applications to the system. This can be configured under DevSuite System Settings--> System Settings --> Applicable Applications. This is essentially the same page you (or whoever installed the system) saw towards to the very end of the Application Server installation. Please note that you can only turn on the module to which you are licensed. Take the screenshot below for example, you will be able to turn DevPlan on but not DevTime because your license does not cover the DevTime module. Also note that once you turn on a previously disabled module in the Admin Client, the corresponding web service has to be enabled as well. To do so, log onto the Web Server and launch the DevSuite Web Service Installation window from StartàTechExcel DevSuiteàDevSuite Web ServiceàDevSuite Web Service Configuration. Select the checkbox for the module(s) you wish to turn on. In our example, check Install DevPlan and then click the OK button to confirm.

43 1.3 Administering System Date and Time Settings DevSuite enables organizations to define standard date and time settings and formatting at the system-level. A system-defined time zone, date and time formats may be enforced globally to every project in the site or designated as default settings which may be overridden at the project or user-level. All DevSuite clients connect to the DevSuite Application Server to get the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database are using the same time clock standard. To define a standard time zone:to define the standard time zone for a DevSuite system, select a time zone in the System Time Zone dropdown list in the Date/Time Settings folder. To define a standard time zone rule:to define rules for implementing the standard system time zone, select an option in the Time Zone area of the the System Time Zone dropdown list in the Date/Time Settings folder. To define rules for implementing the standard system time zone, select an option in the Time Zone area of the Date/Time Settings page. The Time Zone area displays four mutually exclusive options: Default:The standard time zone corresponds to the default time zone of the application server machine. System Level:The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone. Project Level:The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time zone. User Preference:The standard time zone may be overridden at the user- level. Project members may define the time zone of all dates and times displayed in their clients. Defining System Date Formats To define the standard date format for a DevSuite system, select a date format in the Date Format dropdown list in the Date/Time Settings folder. The Date Format dropdown list displays 13 date formats: M/d/yy MM/dd/yyyy yy/mm/dd yyyy/mm/dd yyyy-mm-dd dd-mmm-yy dd/mmm/yyyy dd/mm/yy dd/mm/yyyy dd.mm.yy dd.mm.yyyy dd-mm-yy dd-mm-yyyy Defining System Time Formats To define the standard time format for a DevSuite system, select a time format in the Time Format dropdown list in the Date/Time Settings folder. The Time Format dropdown list displays four date formats: h:mm:ss am/pm hh:mm:ss am/pm

44 H:mm:ss HH:mm:ss To Define the Date/Time Format Rules To define rules for implementing the standard system date and time, select an option in the Date/Time Format area of the Date/Time Settings page. The Date/Time Format area displays three options: System Defined:The standard date/time format is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone. Project Defined:The standard system date/time format may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time zone. User Defined:The standard time zone may be overridden at the user-level. Project members may define dates and times displayed in their clients. Displaying Date and Times in Reports To ensure that the date and time is displayed in the list panels and reports, click the Show Time Info check box. 1.4 Enabling Spell Check and Auto Log Off Time Settings You can define the web client spell check option under DevSuite System Settings --> System Settings --> Spell Check. We recommend that "Auto-detect Spell Check" option is used for best spell check coverage across all browser types. And DevSuite also provides administrators a way to log out idle users based on the length of the inactivity. This can be done under DevSuite System Settings --> System Settings --> Auto Logoff Time Settings. This setting is especially useful for managing floating/concurrent license usage. Suppose you have 50 users share 10 floating licenses. You wouldn't want idle users to take up a license, preventing others from logging in, so it would make sense to log idle users out when their inactivity reaches for say 20 or 30 minutes. To define the timeout settings, specify the number of minutes you want fixed license users or floating license users to idle before the sytemm logs them out. The minimum number is 15, while 0 stands for unlimited, meaning that DevSuite system will not log out users due to inactivity. Note:The reason why the minimum number is 15 is because DevSuite application server would lock a floating license for at least 15 minutes. For example, if a floating license user logs onto DevTrack and uses the system for only 5 minutes, the license will be locked for another 10 minutes before it gets released back to the pool and can be used by others.

45 1.5 Administering Keyword Searching In DevSuite projects, the user may search for work items based on property definitions, workflow states, or the?eywords?that are recorded in fields. A keyword is a term that captures the essence of a topic and so is likely to be used in the description of a knowledge item or work item making it an effective search condition. DevTrack enables project members to search for keywords in the following fields: the Issue Title, Issue Description, History, Notes Title, Notes Description, Link Comments, Event Title, and Event Description. Using controls in the Keyword Search page of the System Settings folder, system administrators may define how precisely the DevTrack Search Engine interprets keyword searches: Exact Keyword Search:If the exact keyword search option is selected, the search engine returns only those text strings that exactly match the keyword queried. Characters immediately preceding or following the keyword string ensure that the string is not returned as a match. A keyword search that uses the keyword?pp?returns work items that have the text stringappin the fields queried. The keyword search does not return issues that include the wordsapparel,appear,apple, orapplication. Keyword Search Includes Wildcard Characters:If the loose keyword search option is selected, the search engine returns all text strings match the keyword queried. Characters immediately preceding or following the keyword string are ignored. A keyword search that uses the keyword?pp?returns work items that include the wordsapparel,appear,apple, orapplicationas well as the text stringapp. 1.6 Administering Standard Lookup Fields In DevSuite, a standard lookup field is an administrator-defined custom field that may be used to define and track business object data in projects throughout a DevSuite site. Each standard lookup field defines a set of field values, which may potentially defined that field in the project.in the DevSuite clients, the field is represented by a multiple selection control (such as a dropdown list) and the field values are displayed as options within that control. Using controls in the Standard Lookup Field page, system administrators may define any number of standard lookup fields and standard lookup field values. A standard lookup field is defined by its field name, field description, field scope, and one or more field values. Each field value may be defined by a field description. Field Name:The field name enables project administrators to identify the field in each project. Field Description:The field description provides project administrators with information about the data tracked in the field. Field Scope:The field scope defines the range of projects in which the standard lookup field may be employed. All standard lookup fields defined in the system settings project are {System} fields. Field Value:A field value is a field property definition that may define a field property. Each standard lookup field defines one or more field values which constitute of options Defining Standard Lookup Fields and Field Values 1.7 Multilingual Support and Localization Administration To add a standard lookup field: 1Select the Standard Lookup Field page in the System Settings folder. All standard lookup fields are defined in the System Settings project. 2Click the New button in the Lookup Field area. The Add Standard Lookup Field dialog box appears. 3Enter a descriptive title for the lookup field in the Lookup Field Name field. 4Select a project from the Project dropdown list. 5Enter a brief description of the data values contained by the lookup field in the Description text area.

46 6Click the OK button. The Add Standard Lookup Field dialog box closes. To edit a standard lookup field: 1Select a standard lookup field in the Standard Lookup Field page. 2Click the Edit button in the Lookup Field area. The Edit Standard Lookup Field dialog box appears. 3Edit standard lookup field definitions. 4Click the OK button. The Edit Standard Lookup Field dialog box closes. To delete a standard lookup field: 1Select a standard lookup field in the Standard Lookup Field page. 2Click the Edit button in the Lookup Field area. A warning dialog box appears. 3Click the Yes button. The standard lookup field and all standard lookup field values are deleted. To add a lookup field value: 1Select a standard lookup field in the Standard Lookup Field page. 2Click the Add button in the Lookup Field area. The Add Choice Value dialog box appears. 3Define the name and description of the standard lookup field value. 4Click the OK button. The Add Choice Value dialog box closes. To edit a lookup field value: 1Select a standard lookup field in the Standard Lookup Field page. 2Select a standard lookup field value in the Lookup Value list. 3Click the Edit button in the Lookup Field area. The Edit Choice Value dialog box appears. 4Define the name and description of the standard lookup field value. 5Click the OK button. The Edit Choice Value dialog box closes. To delete a lookup field value: 1Select a standard lookup field in the Standard Lookup Field page. 2Select a standard lookup field value in the Lookup Value list. 3Click the Delete button in the Lookup Field area. A confirmation dialog box appears. 4Click the Yes button. The standard lookup field value is deleted. 1.8 Administering Time Categories DevSuite solutions support the tracking of data in multiple different languages including languages that use multi-byte encodings such as Chinese, Japanese, or Arabic. All field labels, system fields and custom fields in DevSuite solutions may track multi-byte characters. To enable multilingual support in the DevSuite site, please contact TechExcel support for further assistance. 1.9 Administering LinkPlus Integration DevSuite timeand price analysis features enable development organizations to estimate and track the cost developing new features and the income generated from those features. A time category is a system-level grouping of work activities that is defined by a default hourly rate. This hourly rate may represent the cost or income of development activities. System administrators can create different time groups, and under each time group, multiple time categories can be defined. In DevSuite, all time categories are defined at the system-level and are shared across all projects in a site.

47 Defining Time Groups To add a time group: 1 Click the New Time Group button in the Time Category page. The New Time Group dialog box appears. 2 Define the name of the time group, such as Development Time, QA Time and etc. 3 Select one of the system time type from the dropdown list. Available system time types are: Design Time, Development Time, Test Time and Others. 4 Click the OK button. A new time group has been successfully created. To edit or delate a time group: 1 Highlight the target time group and click the Edit or Delete button. Defining Time Categories To add a time category: 1Highlight the time group to which you wish to add a new time category. 2Click the New Time Category button in the Time Category page. The Add Time Category dialog box appears. 2Define the name of the time category in the Time Category text box. 3Define the hourly rate in the Default Hourly Rate text box. 4Click the OK button. The Add Time Category dialog box closes. To edit a time category: 1Select a time category in the Time Category list of Time Category page. 2Click the Edit button. The Edit Time Category dialog box appears. 3Edit the name of the time category in the Time Category text box. 4Edit the hourly rate in the Default Hourly Rate text box. 5Click the OK button. The Edit Time Category dialog box closes. To delete a time category: 1Select a time category in the Time Category list of Time Category page. 2Click the Delete button. A confirmation dialog box appears. 3Click the Yes button. The time category is removed from the Time Category list Managing DevSuite Admin Reports TechExcel LinkPlus enables administrators to integrate DevSuite projects with existing third-party software. In order for DevTrack to recognize a?ink?to LinkPlus, the Admin must first be configured to search for the specific application you have written. There is no limit to the number of links you can create to a single DevTrack server. When creating or editing a Link, you must select the project to which this link will apply. From there, you specify the linked system and project ID that has been programmatically assigned through your LinkPlus application User Information Report Project information Report Admin Change Log Report 1.11 Administering Welcome and Warning System Messages DevSuite Admin reports enable system administrators to track system-level and project-level information about the projects and users in a DevSuitesite

48 DevSuitefeatures three DevSuite Admin reports: User Information Report:The User Information Report displays detailed information about DevTrack users in a printable format. Project Information Report:The Project Information Report displays detailed information about DevTrack projects in a printable format. Admin Change Log Report:The Admin Change Log Report displays all of the changes made to the DevSuitesystem in a printable format. Chapter 2 DevSuite Web Administration 2.1 Understanding DevSuite Web Server Administration The DevSuite Web Server is an optional DevSuite component that enables distributed development teams to access to development and knowledge management projects over the Internet. All data is completely synchronized in real time to the site database.the DevSuite Web Server connects to the DevSuite Application Server to retrieve database access information and log on to the DevSuite Database Server through an ODBC connection. The DevSuite Web Server makes DevTrack development projects, KnowledgeWise knowledge management projects, and the Beta Customer Portal available to project stakeholders anywhere in the world. All that is required to access a project is a user name, password, and a standard web browser (Firefox or Internet Explorer). The DevSuite Web Server is an optional client. The DevSuite Web Server needs to be installedon the serverif userswould like toaccess DevTrack through the Web. Note:TechExcel recommends installing the DevSuite Admin module on the DevSuite Web Server computer so that changes made to the DevSuite Web Server can be quickly modified in DevSuite Admin. 2.2 Administering the DevSuite Web Server Once the DevSuite Web Server is installed on the machine, system administrators can configure the web server settings using controls available in the DevSuite Web sub-folders in the Start Menu. Configuring the DevSuite Web Server The DevSuite Web Server connects to the DevSuite Application Server to retrieve database access information and log on to the DevSuite Database Server through an ODBC connection. Connections to the DevSuite Application Server and DevSuite Database Server are automatically configured when DevSuite is installed. Connection settings may be changed or updated using controls in the DevSuite Web Server Configuration window. To configure or update DevSuite Web Server: 1Select Start > All Programs > TechExcel DevSuite > DevSuite Web > Configure DevSuite Web. The DevSuite Web Server Configuration shortcut is created in the DevSuite Web Server folder by default when the DevSuite Web Server is installed. The DevSuite Web Server Configuration window appears.

49 2To define the connection to the DevSuite Application Server, enter the server machinethathoststhe DevSuite Application Server and port number. 3To define the connection to the DevSuite Database Server, enter the DBMS, the server machine hosting the DevSuite Database Serverandthe database name 4Define the authentication method. To use Windows NT authentication, select the Windows NT Authentication option button. To use SQL Server authentication, select the SQL Server Authentication option button. Note:Additional configuration on the server side is needed if "Windows NT authentication" is used. Please contact TechExcel support for assistance. 5Verify if the Web Service URLs for KnowledgeWise Web Service, DevTime Web Service and DevTest Web Service are correct. Update the server name if needed. 6Click the OK button Administering DevSuite Web URLs in DevSuite Admin Client Administering Multiple DevSuite Web Servers 2.3 DevTrack Web Administration When changes made to the KnowledgeWise, DevSpec, DevTrack or DevTest projects in the Admin Client, settings have to be reloaded to the web in order for the change to be picked up on the web client side. The system uses the URLs defined under System Settings> Site Settings > General Settings page to handle the reload. Therefore, as an administrator you want to make sure all the URLs defined on this page is valid. Update the server name to the correct IP or fully qualified domain name in each of the URL. This would ensure the changes made in the Admin can be successfully carried over to the web piece without an IIS restart. How come DevTest Admin Web Service URL is read-only? DevTest-related URLs would appear as read-only in the Admin Client. It reads the URL defined in the Web Server Configuration

50 window. Go to Start > All Programs > TechExcel DevSuite > DevSuite Web > Configure DevSuite Web to bring up the dialog box. Make sure the DevTest Web Service URL defined here is correct, and the change made to this URL will be automatically reflected in the Admin Client Defining DevTrack Web Connections Defining DevTrack Web Issue List and Reporting Options Administering Interproject Switching Defining DevTrack Web Titles, Welcome Messages and Logout URL 2.4 Beta Customer Portal Administration Whenever a DevSuite site is implemented across wide area networks, remote users may sometimes report performance issues that are due to (1) latency across long distances and (2)lack of bandwidth at remote or home offices. TechExcel recommends that development organizations that have implemented their DevSuite site across multiple offices install one or more regional web servers to distribute the load across the regional web servers, reduce the processing required of the primary web server, and to eliminate regional bottlenecks. Installing a regional web server also guarantees performance by establishing a singlelink between the two offices, while cutting down on traffic going overseas. Since bandwidth is guaranteed between the database server and the regional web server, data transfer is constant and rapid. If there is no dedicated bandwidth between the remote DevTrack Web server and the central DB server, installing a remote DevTrack Web server may not result in faster performance. Install a regional web server if: A centralized web server is geographically distant from some offices Clients must connect from various local offices within a single region At least 2MB of dedicated bandwidth exists between the regional web server and the central DevTrack database server Using controls in the Multiple Web Server Support page, system administrators may enable support for multiple web servers, define connections to each DevSuite Web Server, and designate the primary DevSuite Web Server.

51 To define connections to multiple DevSuite Web Servers: 1Go todevsuite System Settings --> Web Information Settings --> Web Support --> Multiple WebServer Support page. 2Click the Add New button. The Add Web Server dialog box appears. 3Define the host name or the IP address of the machine running the DevSuite Web Server (make sure DXWebServerSetup.exe is installed on the specified machine) 4 Click the OK button. The Add Web Server dialog box closes. You will notice that after multiple web servers are defined, all the URLs will be listed for web setting reload when Admins click the "Reload Web Settings" button to push out the change. Note:Starting in V9.0, there is actually a better solution to handlinggeographically distributed team than deploying multiple web server support. Check out DevSuite Multi-site support with your sales. With Multi-Site, each geographically distributed team can have their own DevSuite system (which includes the database, the app server, the web server and ect), while the data is in sync with other sites at real time! 2.5 Administering Image and Multimedia Attachment Settings The DevTrack web client is a thin client that enables project team members to view, manage, and track incidents, events, and customers through the Internet using a web browser. Development organizations may deploy DevTrack using any combination of Windows and web clients. DevTrack Web may be used as a stand-alone product or in tandem with the DevTrack Windows client uniting internal and external development teams. All data is completely synchronized in real time to the central DevTrack database Defining DevTrack Web Image Attachment Settings Defining DevTrack Web Movies and Sound Attachments Settings 2.6 Administering DevTrack Web Authentication and Access Controls When DevTrack Web Server is installed and the web clients are accessed by users, the DevTrack web URL needs to be correctly specified in the DevSuite Admin. In this way, changes made through the Admin Client can be pushed and updated to the Web Client. To define a DevTrack Web connection: 1Select DevSuite System Settings > Web Information Settings > Web Support > General Settings. 2Define the DevTrack Web URL in the DevTrack Web Server Path box. The default URL ishttp://servername/scripts/texcel/devtrack (Please replace servername with the correct host name/ip/fully qualified domain name)

52 3 Optional: To test the connection, click the Connection Test button. Note:In DevSuite, project-level configurations and customizations may not be immediately displayed to users accessing those projects through the DevSuite Web Server. To ensure that all changes are properly displayed, system administrators must stop and restart the DevSuite Web Server. To stop and start the DevSuite Web Server, click the Reload Web Settings button in the tool bar of the DevSuite Admin client Configuring DevTrack Login and Password Authentication Configuring Windows NT User Authentication Configuring Third Party Authentication DevTrack Web SSO Chapter 3 Document Serve and Mail Service Administration 3.1 Understanding DevSuite Document Server The DevSuite Document Server stores the files (project control documents, specifications, requirements, test plans, knowledge items, and attachments) that are managed by the site knowledge base and enables distributed development teams to share files in a centralized repository. The DevSuite Document Server consists of three parts: (1) a repository that organizes and stores all files and manages version control; (2) an NT service that controls access to those files and enables project team members to upload and download files and add attachments to development issues and events; and (3) the DevSuite Web Service, which manages connections to the DevSuite clients, DevSpec client, DevPlan client, and DevSuite Web Server 3.2 Administering DevSuite Document Server Administering DevSuite Document Server mainly involves two parts: the installation of the document server setup and document server configuration in the Admin Client Installing and Configuring the Document Server Updating Document Server Info in the Admin Client 3.3 Troubleshooting File Attachment Issue On the DevSuite Server, use one of the following two ways to verify if the document server has been installed: 1. Verify if the following shortcut is available under Start Menu > All Programs > TechExcel DevSuite > DevSuite Document Server > Document Server Configuration. 2. Go to the Services panel. Check if DevSuite Document Server is listed as an available service here. If you don't have the document server installed already, follow the steps below to complete the installation: Run DXDocumentServerSetup.exe In the DevSuite Document Server dialog, if you want to change the directory, you can click the Change button. Otherwise click the Next button to continue. The Document Server Configuration dialog box will then be displayed.

53 Make sure the DevSuite Application Server Name and Port Number are correctly specified. Use the Connect button to verify the connection. Fill out the Document Server info such as server name and Server port. The default port DevSuite document server is using is Update it if you wish to have it run under a different port. The file repository is organized into two directories: the document root directory and the document revision directory. ---The document root directory is a directory where all files and attachments are stored. ---The document revision directory stores previous versions of the files stored in the document root directory. Click the Finish button to finish Document Server installation. 3.4 Understanding DevSuite Mail Services DevSuite document server settings can be configured under DevSuite System Settings >Document Server Settings >Document Server Setting page. In the Server Info section, check the settings and update them if necessary: 1. Make sure the server name is correctly specified. Please note that this server name refers to the name of the application server. 2. Make sure the port number is correctly specified. Please note that the port number refers to the port number under which the document server is running. The default port number is Confirm the Web Service URL path. This is the web service used to handle file upload/download. Please note that the server name or IP should be the machine

54 3. Confirm the Web Service URL path. This is the web service used to handle file upload/download. Please note that the server name or IP should be the machine where you have your web service component installed. 4. Click on the Connect button to test the connection. Note:If you are upgrading from an old DevTrack version (such as version 5.0), document conversion process needs to be performed. Please contact TechExcel Support for further assistance. 3.5 Administering DevSuite Mail Services It's possible that you may have users report issues regarding file upload/download in DevTrack. Below is a list of things you can check to troubleshoot the issue before you contact TechExcel Support: 1. Verify if users are having trouble uploading/downloading files in just the web client or in both the web client and the windows client. If the problem occurs in both clients, make sure that you have the document server correctly installed. Also check the Services panel to make sure the DevSuite Document Server is indeed running. 2. If the problem only occurs in the web client (and very likely this is the case), make sure the two URLs defined in the Admin Client can be browsed from the end user's machine: File Upload Web Service URLon the Document Server Setting page: Make sure you are not using localhost in the URL. Also make sure the server name or IP specified is accessible by the end users. Often times end users only have access to the server using the fully qualified domain name, not the host name. If that's the case, make sure fully qualified domain name is used. KnowledgeWise/DevSpec Web Service URLon the Site Settings >General Settings page:in DevTrack projects that are integrated with KnowledgeWise and DevSpec, this web service is also called while handling file attachments. Make sure this URL is correctly specified as well. Note:If you update the URLs mentioned above, a restart of IIS is needed in order for the change to kick in. 3. There could be problems uploading attachments if you use a mapped drive or an external drive for the document root directory. If so, please contact TechExcel Support for further assistance Installing and Configuring the Notification/ Retrieval Service Administering Error Handling Defining Trace Levels Defining Mail Service Sensitivity Settings Defining Error Log Files Defining Service Error Reports Troubleshooting DevTrack Notification Service Errors Chapter 4 Division Management 4.1 Understanding Divisions In DevSuite, adivisionis a group of project administrators and project members that own one or more projects. Each division is defined by an address, a set of applicable work projects, a set of project administrators, and a group of project members.

55 applicable work projects, a set of project administrators, and a group of project members. Divisions enable development organizations greater control to define and manage project-level access rights and access privileges. The ability of project administrators to manage work projects may be restricted based on division membership. A DevSuite site may be managed by three types of administrators: system administrators, project administrators, and division administrators. Division administrators are project administrators whose access rights are limited to thoseprojects that are applicable to their division. Division management is done in thedivision Management folderwithin the System Settings Project. Using the General Setting page, system administrators can enable division management, customize division terminology, enable cross Division user management, enable division administrator to view system settings, and enable cross-division inter-project copy. Enabling Division Management To enable support for divisions in a DevSuite site, select the Enable Division Management check box in the General Settings page of the Division Management folder of a system settings project. Customizing Division Terminology To customize the term that is used to refer to?ivisions?in a DevTrack site, input a term in the Refer Division As text box in the General Settings page of the Division Management folder of a system settings project. Enabling Cross-Division User Management To enable project administrators to act as division administrators for multiple divisions in a DevSuite site, select the Cross-Division User Management check box in the General Settings page of the Division Management folder of a system settings project. Enabling Division Admins to View System Settings To enable division administrators to view system settings in a DevTrack site, select the Enable Division Administrators to View System Settings check box in the General Settings page of the Division Management folder of a system settings project. Enabling Cross-Division Interproject Copying To enable project members to copy issues between projects belonging to different divisions, select the Enable Cross-Division Interproject Copy check box in the General Settings page of the Division Management folder of a system settings project Managing Divisions Chapter 5 Product Release Management 5.1 Understanding Produce Release Management Administration DevSuite product release management structures define and organize the product releases product families, products, versions, and builds under development in a DevSuite site and define a framework for controlling how these releases are designed and implemented. The DevSuite system provides administrators two ways to manage the product releases: via the Product Component Version Tree and via the Product Family Version Tree. Theproduct component version treeis a hierarchical structure consisting of folders and subfolders that organize the products, versions, and builds under development in a site. This structure enables project administrators to define and control the scope of the work carried out in individualdevspec, DevPlan and DevTrackprojects. An example of the product component version tree: In addition to the mandatory product component version tree that must be defined, we also provide product family version tree that organizes product releases by product family, product family version, and the applicable product components. An example of the product family version tree:

56 When to incorporate the product family version tree? You should turn on the product family version tree support when there is the product family concept in your release. Multiple products (each has its own version) can be put together to form a specific version of a product family. Take TechExcel s product line as an example. When we organize the release by product component version tree, the structure would look something like this with levels of products, versions and builds: Applications: --DevTrack --V70 Build0301 Build V80 Build1201 Build V90 Build DevSpec --V30 Build0301 Build V40 Build1201 Build V50 Buld DevPlan --V30 Build0301 Build V40 Build1201 Build V50 Build0601 On the other hand, TechExcel products have the product family concept and each release is actually delivered based on the product family. For example, DevSuite as the product family includes applications such as DevTrack, DevSpec and DevPlan. Therefore, to organize the releases by product family version tree, it would be like this: Applications: --DevSuite (product family) --V70 --DevTrack V70 --DevSpec V30 --DevPlan V30 --V80 --DevTrack V80 --DevSpec V40 --DevPlan V40 --V90 --DevTrack V90 --DevSpec V50 --DevPlan V50

57 These two kinds of product version trees enables you to manage your product release in a more flexible and thorough way. System-level product release management is the process of defining and organizing the products, versions, and builds under development in a DevSuite site and for defining theimplementation modulesthat are applicable to each product and version. System administrators can manage all the aspects of the product release in theproduct Release Managementfolder in the System Settings project Administering the Product Component Version Tree In DevSuite, the product tree is a hierarchical tree structure that organizes and represents the product categories, products, versions, and builds under development in a DevSuite site. Each product, version, and build represents a distinct deliverable that is managed and tracked in DevSuite. The product tree defines parent-child relationships between project deliverables: Product tree parent-child relationships enable project administrators to quickly identify and define appropriate product categories, products, versions, and builds as applicable to their development projects. Every product release deliverable is identified by the color of its folder and its relationship to the other deliverables in the product tree: Product Category:A product category is any grouping of products such as a product line that a business uses to organize the products that it develops. A product category may be the parent to one or more products or child product categories. Product:A product represents the release of a specific product that is under development in a DevSuite site. A product may be the parent of many different versions of that product. Every product is defined by its release status and one or more applicable implementation modules. Version:A version (release version) represents the release of a version of a product. Every version is the child of a single product and may be the parent to one or more builds. Every version is defined by its release status, a set of milestones, a set of version options, and one or more applicable implementation modules. Build:A build represents a specific build of a product version. Every build is the child of a single version. Every build is defined by its release status. All products, versions, and builds are defined by theirrelease status.a release status is an administrator-defined workflow state that identifies the progress of that deliverable within its development life cycle and determines the work that may be done on product deliverables in that state. For more information on the releases status of products, versions, and builds see Administering Product, Version, and Build Release Statuses. All products and versions are defined by theirimplementation modules. In DevSuite, a product implementation module is a tool for organizing a distinct area of development such as a platform (Windows, Linux), an application (thick client, thin client, smart client), plug-in, tool, widget, or any other development item. For more information on the implementation modules of products and versions see Administering Product Implementation Modules Administering Product Catogories Administering Products Administering Versions Administering Builds Defining Applicable Products/Versions in DevSpec/ DevTrack Projects 5.3 Administering the Product Family Version Tree A product category is any grouping of products that a business uses to organize the products that it develops. A product category may be the parent to one or

58 more products or child product categories. A product category is a tool for organizing the products under development in a DevSuite site. A product category may represent a product line, a suite of applications, or another other grouping of products that makes sense for the business. The scope of development activities in DevSpec and DevTrack projects may be defined by product category. To add a product category: 1Select Product Release Management > Define Product Tree in the tree panel. 2Select the root folder or a product category subfolder in the Product Tree. A product category may be the child of another product category or of the root folder in the product tree. 3Click the New Category button. The New Product Category dialog box appears. 4Define the title and description of the product category. 5Click the OK button. The product category folder is displayed in the product tree panel. To define a product category: 1Select Product Release Management > Define Product Tree in the tree panel. 2Select a product category in the product tree. 3Define product properties in the Product Properties tab. Every product category is defined by its title and description. To delete a product: 1Select Product Release Management > Define Product Tree in the tree panel. 2Select a product category in the product tree. 3Click the Delete button. A confirmation dialog box appears. 4Click the Yes button. 5.4 Administering Product, Version, and Build Release Statuses A product represents the release of a specific product that is under development in a DevSuite site. A product may be the parent of many different versions of that product. Every product is defined by its product category, release status, and one or more applicable implementation modules: Release Status:A release status is an administrator-defined workflow state that identifies the progress of that deliverable within its development life cycle and determines the work that may be done on product deliverables in that state. Implementation Module:An implementation module is a tool for organizing a distinct area of development such as a platform (Windows, Linux), an application (thick client, thin client, smart client), plug-in, tool, widget, or any other development item. The scope of development activities in DevSpec and DevTrack projects may be defined by product.

59 To add a product: 1Select Product Release Management > Define Product Tree in the tree panel. 2Select a product category subfolder in the Product Tree. All product category subfolders in the Product Tree are blue. Every product is the child of a product category. 3Click the New Product button. The New Product dialog box appears. 4Define a unique name for the product in the Product Name control. 5Click the OK button. The New Product dialog box closes. To define a product: 1Select Product Release Management > Define Product Tree in the tree panel. 2Select a product subfolder in the product tree. All product subfolders in the Product Tree aregreen. 3Define product properties in the Product Properties tab. A product is defined by its title, description, and release status. 4Identify the implementation modules that are applicable to the product in the Implementation Module tab. To delete a product: 1Select Product Release Management > Define Product Tree in the tree panel. 2Select a product subfolder in the product tree. 3Click the Delete button. A confirmation dialog box appears. 4Click the Yes button Defining the Product Release Lifecycle Administering the Version Release Lifecycle Administering Build Release Lifecycle 5.5 Administering Product Implementation Modules A version represents the release of a version of a product. Every version is the child of a single product and may be the parent to one or more builds. Every version is defined by its parent product, a release status, a set of milestones, a set of version options, and one or more applicable implementation modules. Release Status:A release status is an administrator-defined workflow state that identifies the progress of that deliverable within its development life cycle and determines the work that may be done on product deliverables in that state. Version Milestone:A milestone is a point in time that represents an important intermediate event in a project. Milestones commonly represent the completion of key components, reporting requirements, and the beginning or end of project phases. Every version milestone is based on a milestone date type. The scope of development activities in DevSpec and DevTrack projects may be defined by version.

60 To add a version: 1Select Product Release Management > Define Product Tree in the tree panel. 2Select a product subfolder in the Product Tree. All product subfolders in the Product Tree are green. Every version is the child of a product. 3Click the New Version button. The New Version dialog box appears. 4Define a unique name for the product in the Version Name text box. 5Click the OK button. The New Version dialog box closes and a version folder is displayed as the child of the select product in the product tree. To define a version: 1Select Product Release Management > Define Product Tree in the tree panel. 2Select a version subfolder in the Product Tree. All version subfolders in the Product Tree are gray. 3Define version properties in the Version Properties tab. A version is defined by its title, description, and release status. 4 Optional: To define version milestones, select the Select Applicable Dates button and select one or more milestone date types in the dialog box. To delete a version: 1Select Product Release Management > Define Product Tree in the tree panel. 2Select a version subfolder in the product tree.click the Delete button.a confirmation dialog box appears. 3Click the Yes button Adding Product Implementation Modules 5.6 Administering Product Version Options Every build in the product tree represents a build of a version in development in a DevTrack project. Each build is the child of a single version. Every build is defined by its parent version and its release status.a release status is an administrator-defined workflow state that identifies the progress of that deliverable within its development life cycle and determines the work that may be done on product deliverables in that state. The scope of development activities in DevSpec and DevTrack projects may be defined by build. To add a build: 1Select Product Release Management > Define Product Tree in the tree panel. 2Select a version subfolder in the Product Tree. All version subfolders in the Product Tree are gray. Every build is the child of a version. 3Click the New Build button. The New Build dialog box appears.

61 3Click the New Build button. The New Build dialog box appears. 4Define a unique name for the product in the Build Name text box. 5Click the OK button. The New Build dialog box closes and a build folder is displayed as the child of theselected version in the product tree. To define a build: 1Select Product Release Management > Define Product Tree in the tree panel. 2Select a build subfolder in the Product Tree. All build subfolders in the Product Tree are gold. 3Define build properties in the Build Properties tab. A build is defined by its title, description, and release status. To delete a build: 1Select Product Release Management > Define Product Tree in the tree panel. 2Select a build subfolder in the product tree.click the Delete button.a confirmation dialog box appears. 3Click the Yes button Defining Version Options Applying Version Options to Versions Chapter 6 Time and Cost Tracking Administration 6.1 Understanding Time and Cost Administration DevTrack enables development organizations to track the time that project members spend working in projects as well as on individual development issues. This feature helps development organizations review the length of each issue lifecycle, and thus further analyze development and user trends. Project-Level Time Tracking:Project-leveltime tracking enables development organizations to track the time that project members spend working in individual projects. Issue-Level Time Tracking:Issue-level time tracking enables development organizations to track the time that project members spend working on individual development issues. Time tracking is designed to be used with DevTrack s another innovate feature issue cost tracking, which provides an easy way for development organizations to calculate the cost of the development efforts. Development organizations can also generate time/cost tracking reports for business purposes. Issue-Level Cost Tracking:Issue-level cost tracking enables development organizations to calculate the cost of their development efforts. Note:DevTrack issue-time tracking is not an automatic time-recording system. Instead, team members will be prompted with a dialog box when forwarding an issue (or under other scenarios defined by the project administrator). In the dialog box, members can manually input the hours they spend working on the issue. 6.2 Administering Time Groups and Time Categories In the older version of DevTrack (prior to DevSuite 7), issue time/cost tracking is defined and managed at project level. Project administrators needed to create various work types to represent the work done by the team members in each of the project. Starting in DevSuite 7, issue time/cost tracking has presented itself as a global concept----various time groups and time categories can be defined at system level and implemented flexibly at project level. All projects across the DevSuite site can share and use the time categories defined in the System Settings Projects.

62 6.2.1 Creating Time Groups Editing Time Groups Creating Time Categories Editing Time Categories 6.3 Understanding Time and Cost Administration In DevSuite, a time group is defined by its title and itstime type. Every time group belongs to one of four time types: Design Time time type, Development Time time type, Testing Time time type, and Other time type. Using controls in the Time Category page, system administrators may create, edit or delete time groups. To create a time group: 1Select Time Category Page under the System Settings folder. 2Click the New Time Group button. The Add Time Group dialog box appears. 3 Define the name of the time group that best illustrates the time categories it is going to contain. 4 Select one of the system time types from the dropdown list that matches best with the to-be created time group. It can be one of the followings: Design Time time type, Development Time time type, Testing Time time type, and Other time type. 5 Click the OK button. The Add Time Group dialog box closes and the time group is displayed in the Time Category tree as a folder that can contain various time categories. 6.4 Administering Time Groups and Time Categories In DevSuite, a time group is defined by its title and itstime type. Every time group0 belongs to one of four time types: Design Time time type, Development Time time type, Testing Time time type, and Other time type. A time group may be the parent of multiple time categories. Using controls in the Select Time Category window, project administrators may identify applicable time categories.

63 Figure 11-2: Creating Time Groups Editing Time Groups Creating Time Categories Editing Time Categories Chapter 7 Managing DevSuite with Other Modules 7.1 Inter-Project Switching Settings 7.2 Project Portfolio Management 7.3 DevTime and Work Schedule Management 7.4 Kloud Integration Management Chapter 8 DevTest System Settings Administration 8.1 Understanding DevTest Site Administration In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site. A DevTest site is an implementation of adevtest Serverand may include multiple knowledge, test template, and work projects. DevTest system settings are configurations that define multiple projects in the site including the configuration and maintenance of core DevTest components such as the DevTest Database Server and DevTest Document Server, system services, and the configuration of system-wide messaging, communication, and usability tools. Site and System Administration The foundation of every DevTest implementation -- called adevtest site-- is the DevTest Server. The DevTest Server consists of five core components: the DevTest Database Server, DevTest Application Server, DevTest Document Server, and DevTest Web Services.

64 Figure 3-1: DevTest Core Architecture DevTest components may be distributed across multiple computers in a distributed network. At a bare minimum, DevTest is comprised of a three-tier structure: the DevTest Server accepts connections from the DevTest clients, which run on the user? machines. Connections to the DevTest Database Server are managed and controlled by the DevTest Application Server. DevTest Database Server - Accepts connections from DevTest clients and stores site and project data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-compliant DBMS. DevTest Application Server - Acts as a gatekeeper between the data stored in the DevTest Database Server and the clients and services that access that data. DevTest Web Service - A set of web services that manage connections between DevTest Admin client and the DevTest Application Server. DevTest Admin Client - Connects to the DevTest Application Server through the DevTest Web Service. Using the DevTest Admin Client, system and project administrators may configure, customize, and manage the DevTest site and multiple projects. DevTest Document Server - Enables organizations to attach files to support incidents and to upload and download files from the knowledge base. Both the DevTest client and DevTest Web Server use the DevTest Document Server to access files including file attachments, attachments, and knowledge items. Understanding System Administrator Privileges All system-wide settings are defined by a system administrator in DevTest Admin. To define system settings a project member must be assigned a system administrator account type. Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank)). The password is case-sensitive, however the user name is not case-sensitive. For security reasons TechExcel suggests changing this default login setting as soon as possible. 8.2 Administering DevTest Database Servers The DevTest Database Server accepts connections and stores data. TechExcel solutions run on the Microsoft platform, but DevTest supports any ODBC-compliant database. TechExcel DevTest supports five database management systems (DBMS): Microsoft SQL Server - TechExcel recommends Microsoft SQL Server 2000 Service Pack 3 as the first choice DBMS for running DevTest. DevTest may run on Microsoft SQL Server 6.5, Microsoft SQL Server 7, or Microsoft SQL Server Oracle - DevTest supports Oracle 7.3, 8, and 9i. The DevTest Installation Guide provides step-by-step instructions for installing and configuring the DevTest Database Server on the Microsoft SQL Server DBMS. Checking Database Integrity System administrators may use the System Integrity Check dialog box to perform a one-time check of database integrity whenever they upgrade their DevTest implementation. This procedure checks that all data was properly converted during the upgrade process. A check of database integrity should be run whenever data-related issues arise after an upgrade. For example, default issue templates not being properly converted, or Crystal Reports not showing you the proper data. System administrators do not need to check database integrity when they initially install DevTest. To check database integrity: 1Select System > System Integrity Check in the menu bar. The System Integrity Check dialog box appears. 2Click the Start button. Setting DevTest System Compatibility To define DevTest system compatibility: 1Select System > System Settings > General Settings in the menu bar. The General Settings window appears. 2Select an option from the Earliest DevTest Client Allowed dropdown list. Project members who try to log into the DevTest project with client that is older than the one specified in this field are denied access, and prompted to upgrade their client. Defining Memo Field Size Limits In DevTest, data fields used to track multiple lines of text are commonly calledmemo fields. Memo fields are represented as multiple-line text boxes in the clients. Common memo fields include Template and Task Description, Notes Description, and Link Comments. By default, the memo fields in a DevTest site are limited to 10K bytes. To define memo field size limits: 1Select System > System Settings > General Settings in the menu bar. The General Settings window appears. 2Select an option in the Maximum memo field size dropdown list Defining Name Display Formats To define the format of names in a site:

65 1Select System > System Settings > General Settings in the menu bar. The General Settings window appears. 2Select a display option. To display project team member names using the format First Name Last Name select the First_Name Last_Name option. To display project team member names using the format Last Name, First Name select the Last_Name, First_Name option. 8.3 Administering DevTest Application Servers In DevTest, the DevTest Application Server maintains data integrity, manages the user licenses, and manages date and time synchronization across the site. The DevTest Application Server is essentially agatekeeperbetween DevTest servers, clients, and components and the DevTest Database Server. The DevTest Application Server is implemented as a Windows NT Service that stores database connection information. All DevTest clients connect to the DevTest Application Server to retrieve the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database are using the same time clock standard. DevTrack clients may display the date and time in their time zone by using the offset to the time zone of the DevTest Application Server. For more information see "Administering System Date and Time Settings." Defining Application Server Connections Using controls in the DevTest Application Server Configuration manager tab, the system administrator may define the location of the DevTest Application Server. DevTest Application Server settings include the system name, the application server name, and the port number. Figure 3-2: DevTest Application Server Configuration Manager To define DevTest Application Server configurations: 1Select Start > All Programs > TechExcel DevTest > DevTest Application Server > Configure Application Server. The DevTest Application Server Configuration window appears. 2Define the system name, server name, and port number. Defining DevTest Database Server Connections In a DevTest site, all client, components, and modules connect to the DevTest Database Server through the DevTest Application Server. The DevTest Application Server is essentially agatekeeperbetween DevTrack application components and the DevTest Database Server. Administrators may use the DevTest Application Server manager to define a connection to the DevTest Database Server. Connection settings include the name of the database server machine, the database name, and authentication information. Using controls in the Database Configuration tab of the DevTest Application Server Configuration manager, the system administrator may define a connection to the DevTest Database Server. Figure 3-3: Database Configuration Tab of the DevTest Application Server Configuration Manager DevTest Database Server connection settings include the database server name and DBMS type, database name, and authentication settings. Database Type - DevTest may run on any ODBC-compatible DBMS. Database Server - The database server identifies the name of the machine on which the DevTest Database Server runs. Database Name - The database name identifies the name of the database on the DBMS. By default, the DevTest installer creates a database named DevTestDB DevTest supports two authentication modes: SQL Server Authentication - Uses a SQL Server user name and password, which must be identified to connect to the database. Windows NT Authentication - Uses Windows domain user and group accounts for authentication. SQL Server automatically authenticates users based on their user account names or group membership. They are not required to enter a password. 8.4 Administering the DevTest Document Server The DevTest Document Server stores the files (project control documents, specifications, requirements, test plans, knowledge items, and attachments) that are managed by the site knowledge base and enables distributed development teams to share files in a centralized repository. The DevTest Document Server consists of two parts: (1) a repository that organizes and stores all files and manages version control and (2) an NT service that controls access to those files and enables project team members to upload and download files and add attachments to project work items. Configuring DevTest Document Server Settings Using the Document Server Setting page, the system administrator may define the location of the DevTest Database Server enabling users to download and upload knowledge

66 items stored in the knowledge base. To define the DevTest Document Server connection: 1Select the Document Server Setting page in the Document & Web Server Settings folder. The Document Server Setting page appears. 2Input the server name and port number of the DevTest Document Server. Server Name - The exact name or IP address of the machine on which the DevTest Document Server service runs. Port Number - Defines the port number used by the DevTest Document Server. 3 Optional: To test the connection to the DevTest Database Server, click the Connect button Defining the Document Root and Document Revision Directories The DevTest Document Server organizes and stores all files and manages version control. The repository may manage up to five versions of each file. The repository is organized into two directories: the document root directory and the document revision directory. Document Root Directory - A directory where all files and attachments are stored. The Document root directory is defined during the installation of the DevTest Document Server. Document Revision Directory - Stores previous versions of the files stored in the document root directory. The document root directory and the document revision directory are defined when DevTest Document Server is installed on the server machine. The directories may be changed using the Document Server Configuration tool in the Windows Start menu. To change the document root directory and document revision directory: 1Select the Document Server Configuration command in the Windows Startup menu of the machine that hosts the DevTest Document Server. The Document Server Configuration window appears. 2 Optional: To edit the document root directory, update the path in the Document Root Directory text box. 3 Optional: To edit the document revision directory, update the path in the Document Revision Directory text box. 4Click the OK button. The Document Server Configuration window closes and the changes are saved. Configuring Document Server Settings The DevTest document server enables DevTest project to manage documents in a knowledge project. The system administrator can define Document Server properties in the Document Server Manager. All project-related documents are managed by a separate document server. The system administrator must configure the DevTest document server if the project administrators want to manage project documentation in a knowledge project. Administrators may use the Document Server Setting dialog box to configure the DevTest document servers that project administrators use to manage project documentation in DevTest projects. Document server properties enable DevTest projects to locate the external document server and download or upload documentation. Administrator-defined document server settings apply to every project in a DevTest implementation. Administrators must define two document server properties: The Server Name (or IP address) is the exact name or IP address of the computer where the document server resides. The Port Number represents the port number used by the document server. The default port number is To configure Document Server properties: 1Select System > Document Server. The Document Server Setting dialog box appears. 2Enter a name in the Server Name field. 3Enter a port number in the Port Number field. 4Click the OK button. 8.5 Administering System Date and Time Settings DevTest enables organizations to define standard date and time settings and formatting at the system-level. A system-defined time zone, date and time formats may be enforced globally to every project in the site or designated as default settings which may be overridden at the project or user-level. All DevTest clients connect to the DevTest Application Server to get the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database are using the same time clock standard. Administering Standard System Time Zones DevTest enables system administrators to define a standard time zone for each DevTest system and rules for enforcing that time zone. The system-defined time zone may be enforced globally to every project in the site or designated as the default settings which may be overridden at the project or user-level. To define a standard time zone: To define the standard time zone for a DevTest system, select a time zone in the System Time Zone dropdown list in the Date/Time Settings folder. To define a standard time zone rule: To define rules for implementing the standard system time zone, select an option in the Time Zone area of the System Time Zone dropdown list in the Date/Time Settings folder. To define rules for implementing the standard system time zone, select an option in the Time Zone area of the Date/Time Settings page. The Time Zone area displays four mutually exclusive options: Default - The standard time zone corresponds to the default time zone of the application server machine. System Level - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone. Project Level - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard

67 project time zone. User Preference - The standard time zone may be overridden at the use- level. Project members may define the time zone of all dates and times displayed in their clients. Defining System Date Formats To define the standard date format for a DevTest system, select a date format in the Date Format dropdown list in the Date/Time Settings folder. The Date Format dropdown list displays 13 date formats: M/d/yy yy/mm/dd yyyy-mm-dd dd/mmm/yyyy dd/mm/yyyy dd.mm.yyyy dd-mm-yyyy MM/dd/yyyy yyyy/mm/dd dd-mmm-yy dd/mm/yy dd.mm.yy dd-mm-yy Defining System Time Formats To define the standard time format for a DevTest system, select a time format in the Time Format dropdown list in the Date/Time Settings folder. The Time Format dropdown list displays four date formats: h:mm:ss am/pm H:mm:ss hh:mm:ss am/pm HH:mm:ss Administering Date and Time Privileges To define rules for implementing the standard system time zone, select an option in the Date/Time Format area of the Date/Time Settings page. The Date/Time Format area displays three mutually exclusive options: System Defined - The standard time zone is enforced throughout the site. Every project in the site stamps all actions and entries based on the system time zone. Project Defined - The standard system time zone may be overridden at the project level. Project administrators may accept the standard system time zone or define a standard project time zone. User Defined - The standard time zone may be overridden at the user level. Project members may define the time zone of all dates and times displayed in their clients. Displaying Date and Times in Reports To ensure that the date and time is displayed in the list panels and reports, click the Show Time Info check box. Defining Project Date and Time Settings DevTest enables testing organizations to define standard date and time settings and formatting at the system-level. A system-defined time zone, date and time formats may be enforced globally to every project in the site or designated as default settings which may be overridden at the project or user-level. All DevTest clients connect to the DevTest Application Server to get the current date and time. Date and time synchronization ensures that all users connecting to a DevTrack Database are using the same time clock standard. Administrators may use the System Time/Date manager to define all project date and time zone settings. Figure 3-4: System Time/Date Manager 8.6 Administering System Messages and Help The system administrator is responsible for creating and managing system messages in the DevTest system. System messages can be used to communicate information to DevTest user in every project in the system. DevTest Admin enables administrators to create two types of system messages: System Welcome Messages System Warning Messages Both system welcome messages and system warning messages appear in the same text area of the login screen. Whenever a warning message is created, that message automatically overrides the welcome message and appears in the login screen for the duration of its broadcast period. Both Welcome messages and Warning messages can be customized for both the Windows client and DevTest Web applications. DevTest Client System Messages System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project selection page, the first screen the user sees when he or she logs into DevTest. In the DevTest client, system messages appear on the Select Project to Login dialog box. DevTest Web System Messages System messages are given prominent placement within the DevTest client. In both the DevTest client and DevTest Web the system welcome and warning messages appear in the project selection page, the first screen the user sees when he or she logs into DevTest.

68 In DevTest Web, system messages appear on the home page. System administrators can format DevTest Web welcome messages using standard HTML markup tags. Defining System Welcome Messages DevTest Admin enables system administrators to define system-wide welcome messages that can be used to communicate critical information to all DevTest users. DevTest system administrators can customize warning messages for the DevTest client and the DevTest Web application. System administrators can format DevTest Web welcome messages using standard HTML markup tags. To define DevTest welcome messages: 1Select System > System Message > System Welcome. The System Message dialog box appears. 2Enter a message in the Message for DevTest Web (in HTML) text area. 3Enter a message in the Message for DevTest Client (in TEXT) text area. Administrators may format the message using standard HTML markup tags. 4Click the OK button. Defining System Warning Messages The System Warning page enables administrators to define system-wide warning messages that administrators may use to communicate critical information to all DevTest users. System administrators must define a beginning and ending date and time for all warning system messages. The warning system message is broadcast to all DevTest client and DevTest Web users for the duration of the broadcast period defined by the system administrator. During the broadcast period the system warning message displaces the welcome message in the project selection page. When the broadcast period is over, the welcome message returns to the page. To define DevTest system warning messages: 1Select System > System Message > System Warning The System Warning dialog box appears. - Enter a message in the Message for DevTest Web (in HTML) text area. - Enter a message in the Message for DevTest Web (in Text) text area. 2Select the Display message at project selection page checkbox. 3Choose the beginning time and date in the Date/Time From [control]. 4Choose the ending time and date in the Date/Time To [control]. 5To automatically log users off the system at a preset time, select the Log off the User from the System checkbox. All DevTest client users are automatically logged off the DevTest system at the time and date that administrators define in this page. Project team members cannot access the DevTest client for the duration of the outage. 6Choose the beginning time and date in the Date/Time From [control]. 7Choose the ending time and date in the Date/Time To [control]. 8Click the OK button. Administering User Sessions System administrator are responsible for maintaining the DevTest system. Administrators may need to log users off of the DevTest system to perform routine maintenance. DevTest Admin provides system administrators with two methods for managing user sessions: - Automatically log all users off the system using tools in the Warning System Message Manager - - Manually log users off the system using the Login Manager. Configuring Online Help Settings Administrators may use the Online Help Settings manager to define the location of DevTest online help and documentation for all projects in the DevTest system. Figure 3-5: Online Help Settings Manager Administrators may install a copy of the help files on a Web server, and all users can access them through a specific URL. Alternatively, individual users may install the online help files to the DevTest directory on their client machines and access the files locally. To configure online help settings: 1Select System > Online Help Setup. The Online Help Setting dialog box appears. 2Enter the URL for the online help system in the Client Help Path field.

69 3Click the Test Connection button to ensure that DevTest client online help is accessible at the address provided. 4Enter the URL for the DevTest Admin online help system in the Admin Help Path field. 5Click the Test Connection button to ensure that DevTest Admin online help is accessible at the address provided. 6Click the OK button. 8.7 Administering DevTest Admin Reports Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system. DevTest provides three different types of reports: The User Information Report displays detailed information about DevTrack users in a printable format. The Project Information Report displays detailed information about DevTrack projects in a printable format. The Admin Change Log Report displays all of the changes made to the DevTrack system in a printable format. Viewing Admin Reports Administrators may use DevTest Admin reports to view information about projects, project team members, and changes to the DevTest system. To view Admin reports: 1Select Tool > Admin Report. The Admin Report submenu appears. 2Select an option from the Admin Report submenu. The report window appears. 3To switch between reports, you can select a report type from the Project Selection dropdown list. 4To print the report, select the Print button. Understanding the User Information Report The User Information Report provides administrators with detailed information about DevTest users in a printable format. All DevTest users are listed by their login ID. The User Information Report shows detailed information for project member: Full Name License type Work phone address Address Status Privilege Home Phone Understanding the Project Information Report The Project Information Report provides administrators with detailed information about DevTest projects in a tabular format. The Project Information Report provides administrators a detailed report about five project-specific areas: Project Overview - This area shows the project name, project status, project ID, starting number, and project description. Project Administrator - This area lists all project administrators for the project. Account Type Privileges - This area shows the account type members and privileges for each account type. Groups - This area shows all project members by project group. Folders - This area shows all folders, folder owner groups, and the View, Put, and Get privileges for those account types that belong to each folder. 8.8 Administering DevTest Web The DevTest web client is a 'thin client' that enables project team members to view, manage, and track templates, test tasks, and knowledge items using a web browser. Testing organizations may deploy DevTrack using any combination of Windows and web clients. DevTest Web may be used as a stand-alone product or in tandem with the DevTest Windows client uniting internal and external development teams. All data is completely synchronized in real time to the central DevTest database. DevTest Web Server administration is the process of configuring the DevSuite Web Server, defining connections settings for every project in the site, defining web authentication settings and system runtime keys. Defining the DevTest Web Server Path To define DevTest Web Server paths: 1Select Tool > Web Setup. The Web Setup window appears. 2Enter the DevTest project URL in the DevTest Web Server Path field. 3 Optional: To test the connection, click the Connection Test button. 4Click the OK button. Defining DevTest Web Login Titles and Messages To define DevTest web server paths: 1Select Tool > Web Support > General Setting. The Web Support manager appears. 2Enter the title for DevTest Web in the Web Login Title field. 3Enter a message in the Web Login Message in HTML field. 4Click the OK button.

70 Defining DevTest Web Logout URLs In DevTest, system administrators may optionally identify the web page that is displayed in a user's web browser after he or she logs out of a DevTest project. By default, no Web logout URL is defined and all users are immediately directed to the DevTest Web Login page when they log out of a project. If Windows NT authentication is enabled for DevTest Web, project team members would be automatically logged into a DevTest project whenever they log out of a project. The DevTest Web Logout URL abrogates this error. To define a DevTest Web logout URL: 1Select Tool > Web Setup. The Web Setup window appears. 2Enter a URL in the Web Logout URL text box. 3To test the logout URL, click the Test Connection button. 4Click the OK button. The Web Setup window closes. Managing DevTest Web Idle Time-out Settings In DevTrack, administrator-defined time-out settings control access to projects and manage the distribution of floating licenses to project team members. DevTrack client users may be automatically logged out of DevTrack projects if they remain inactive for a period that exceeds the idle time-out period. Idle time-out settings define the amount of time that must pass (in minutes) between actions in client before a user is automatically logged out of the project. The minimum idle time-out setting is 15 minutes. System administrators may disable DevTrack idle time-out controls by entering 0 in the Idle Time-out control of the Login Manager. If zero 0 is entered in the Idle Time-out control, idle users are not logged out of DevTrack projects. To define DevTest Web idle time-out settings: 1Select Tools > Web Setup. The Web Setup window appears. 2Enter 0 or a number greater than 15 in the Automatically log out user after idle for Minutes text box.. 0 If zero is entered, DevTrack idle timeout controls are disable in the DevSuite site. 15 If a number is entered, the DevTrack idle timeout timer is set to automatically log off users that are inactive for periods that exceed the number entered. The minimum idle timeout setting is 15. Defining DevTest Web Authentication Preferences DevTest Web supports Windows NT authentication. System administrators may choose between two methods for authenticating users that log into DevTest projects over the Web: and Windows NT Authenticating. DevTest Login and Password Windows NT Authenticating Using Windows NT authentication, DevTest project team members may use their current NT user name and password (with which they are currently logged into their machine) to access DevTest projects through DevTest Web. If Windows NT authentication is enabled, project team members need only enter their Windows NT username and password the first time they log into a project through DevTrack Web. Users are automatically logged into the project for all future sessions. System administrators must configure IIS for either Basic Authentication or Windows Authentication to use Windows NT user authentication. To define DevTest Web authentication preferences: 1Select Tool > Web Authentication. The Web Authentication dialog box appears. 2Select an authentication method for the DevTest Web client. To enable standard DevTest login name and password authentication, select the DevTest Login and Password option button. To enable Windows NT authentication, select the Windows NT Authentication option button. 3Click the OK button. The Web Authentication dialog box closes. Configuring the DevSuite Web Server The DevTest Web Server connects to the DevTest Application Server to retrieve database access information and log on to the DevTest Database Server through an ODBC connection. Using controls in the DevTest Web Server Configuration window of the Control Panel, system administrators may define and update the connections between the DevTest Web Server and the DevTest Application Server and the DevTest Database Server.

71 Figure 3-6: DevTest Web Server Configurational Connections to the DevTest Application Server and DevTest Database Server are automatically configured when DevTest is installed. Connection settings may be changed or updated using controls in the DevTest Web Server Configuration window. Note:TechExcel recommends installing the DevTest Admin module on the DevTest Web Server computer so that changes made to the DevTest Web Server can be quickly modified in DevTest Admin. To configure DevTest Web Server: 1Select Start > All Programs > TechExcel DevTest > Configure DevTest Web. The DevTest Web Server Configuration shortcut is created in the DevTest Web Server folder by default when the DevTest Web Server is installed. The DevTest Web Server Configuration window appears. 2To define the connection to the DevTest Application Server, enter the server machine hosting the DevTest Application Server and port number. 3To define the connection to the DevTest Database Server, enter the DBMS, the server machine hosting the DevTest Database Server, the database name, and database path. 4Define the authentication method. To use Windows NT authentication, select the Windows NT Authentication option button. To use SQL Server authentication, select the SQL Server Authentication option button. 5Click the OK button. Starting and Stopping the DevTest Web Server In DevTest, project-level configurations and customizations may not be immediately displayed to users accessing those projects through the DevTest Web Server. To ensure that all changes are properly displayed, system administrators must stop and restart the DevTest Web Server. To stop and start the DevTest Web Server, click the Reload Web Settings button in the tool bar of the DevTest Admin client. Administering Multiple DevTest Web Servers Whenever a DevTest site is implemented across wide area networks, remote users may sometimes report performance issues that are due to (1) latency across long distances and (2) lack of bandwidth at remote or home offices. TechExcel recommends that development organizations that have implemented their DevTest site across multiple offices install one or more regional web servers to distribute the load across the regional web servers, reduce the processing required of the primary web server, and to eliminate regional bottlenecks. Figure 3-7: Regional DevTest Web Server Installing a regional web server also guarantees performance by establishing a single link between the two offices, while cutting down on traffic going overseas. Since bandwidth is guaranteed between the database server and the regional web server, data transfer is constant and rapid. If the there is no dedicated bandwidth between the remote DevTrack Web server and the central DB server, installing a remote DevTrack Web server may not result in faster performance. Install a regional web server if: - A centralized web server is geographically distant from some offices - Clients must connect from various local offices within a single region - At least 2MB of dedicated bandwidth exists between the regional web server and the central DevTrack database server Using controls in the Multiple Web Server Support page, system administrators may enable support for multiple web servers, define connections to each DevTest Web Server, and designate the primary DevTest Web Server.

72 Figure 3-8: Multiple Web Server Support Page In general, remote users accessing the remote Web Server should expect faster performance with the dedicated bandwidth between the remote DevTest Web server and the central DevTest Database Server especially if it is more than 2 MB. A remote user may still decide to access the central web server directly if such user has a reasonable network access bandwidth directly to the central DevTrack central web server. Because retrieving HTML pages directly from the central Web server only requires a small amount of bandwidth for good performance, a remote user with a may actually experience faster performance by accessing the central web server. To define connections to multiple DevTest Web Servers: 1Select System > Multiple Web Server Support. The Multiple Web Server Setting window appears. 2Click the Add New button. The Add Web Server dialog box appears. 3Define the host name and IP address of the machine running the DevTest Web Server. 4Click the OK button. The Add Web Server dialog box closes. 8.9 Administering DevSuite Integration Enabling and Defining DevSuite Integration DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family. To enable and define DevSuite integration: 1Select System > DevSuite Integration in the menu bar. The DevSuite Integration window appears. 2Click the Change button. 3Select the Enable DevSuite Integration check box. 4Select a DevSuite site in the DevSuite dropdown list. 5Input the DevSuite Web Service URL in the Admin Web Service URL text box. Enabling and Defining KnowledgeWise and DevSpec Integration To enable DevSuite integration: 1Select System > DevSuite Integration in the menu bar. The DevSuite Integration window appears. 2Select the Enable KnowledgeWise Integration check box. 3Input the KnowledgeWise Web URL in the KnowledgeWise Web URL text box. 4Input the DevSpec web service URL in the DevSpec Web Service URL text box Administering Multiple Sites A DevTest implementation, called a site, consists of one or more knowledge projects, one or more template base projects, and one or more work (test task) projects. Every project in DevTest site shares a common database and other system-level configurations. In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack or DevTest sites) that are joined together for the centralized management and control licenses. Figure 3-9: DevTest Site Family and Stand-Alone Site

73 QA organizations that operate multiple DevTest sites may centralize the management and control of licenses within a site family, so that licensed users worldwide may access and work in any project in the site family. Master Site Work Site The master site stores and manages all user licenses in the site family. System administrators may use controls in the master site to generate authentication codes that enable work sites to join the site family. A work site runs its own DevTest Database Server, DevTest Application Server, DevTest Document Server, and other DevTest services. Every site may create and manage any number of DevTest projects, knowledge projects, template base projects, and work projects. Standalone Site A standalone site is a DevTest implementation that controls and ma nages its licenses separately from other DevSuite implementations. DevTest multiple site management enables development organizations to manage user licenses in a central repository so that licensed users world wide may access and work in any project in the site family. Fixed licenses managed in the master site enable users from any work site to access any project belonging to any site in the site family. Traveling users may use their license to log project belonging to other DevTest sites. Floating licenses, however, are managed on a site-by-site basis. Each work site manages its own floating licenses. Users may not log into projects using floating licenses once the maximum number of users is exceeded.fixed A Administering a Site Family In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of DevSuite licenses. Using controls in the Multiple Site Family page, system administrators may define a DevTest site as the master site for a family of DevTest work sites. To define a site family: 1Select System > Multi Site Family. The Multiple Site Settings window appears. 2Click the Create a New Multiple Site Family button. A confirmation dialog box appears. 3Click the Yes button. The confirmation dialog box closes. The Create a Site Family dialog box appears. 4Input the name of the site in the Site Name edit box. 5Input the site family web service URL in the Site Web Service URL edit box. 6Click the OK button. The Create a Site Family dialog box closes. The site is displayed in the Site Family list of the Site Settings page. To add a work site to a site family: 1Select System > Multi Site Family. The Multiple Site Settings window appears. 2Click the Add button in the Site Settings window. The Add a Regular Work Site dialog box appears. 3Enter the name of the work site in the Site field. 4Enter the URL for the site? DevTest Web in the Web Server URL. 5 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric authentication key. 6Write down the authentication code and send the authentication code to the system administrator of the child work site. The work site must use the authentication key to join the site family. 7Click the OK button. The Add a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page. To edit work site settings: 1Select System > Multi Site Family. The Multiple Site Settings window appears. 2Select a work site in the Site Family list of the Site Settings page. 3Click the Edit button in the Site Settings manager. The Edit a Regular Work Site dialog box appears. 4Enter the name of the work site in the Site field. 5Enter the URL for the site? DevTest Web in the Web Server URL. 6 Optional: To generate an authentication code, click the Generate button An authentication code is required to join a site family. Each site is identified by a unique ten digit alphanumeric authentication key. 7Write down the authentication code. The authentication code is required for the work site to join the site family. 8Click the OK button. The Edit a Regular Work Site dialog box closes. The work site is added to the Site Family list in the Site Settings page. To allocate floating licenses to work sites: 1Select System > Multi Site Family. The Multiple Site Settings window appears. 2Click the Allocate Site Licenses button. The Multiple Site License Allocation dialog box appears.

74 3Select a site in the site list. The site list displays the name of every work site added to the site family and the number of floating licenses currently allocated to that site. Note:By default all floating licenses are initially allocated to the master site. To allocate floating licenses to work sites, one or more floating licenses must be reallocated from the master site. 4Click the Edit button. The Update Floating License dialog box appears. 5Input the number of floating licenses to be allocated to the selected site in the Floating License Number edit box. 6Click the OK button. The Update Floating License dialog box closes. Administering a Standalone Site In DevSuite, a standalone site is a work site that is not a member of a site family and which manages licenses internally. To define a standalone site: By default, every DevTest implementation is a standalone site and remains a standalone site so long as the system administrator does not create a site family or join a site family. To change a master site or work site into a standalone site: System master sites cannot be changed to a stand alone site as long as other sites belong to the site family. The system master site must first transfer the site family to another system master site, or all of the work sites must leave the site family before the site can be changed to a stand alone site. Joining a Site Family In DevSuite, a site family consists of a master site and one or more of work sites (DevTrack, DevSuite, or DevTest sites) that are joined together for centralized management and controls of DevSuite licenses. Using controls in the The Join Multi Site Family wizard, system administrators may join an existing DevTest or DevSuite site family. Figure 3-10: Join Multi Site Family Wizard DevTest-DevSuite integration requires that the DevTest site first is a member of a DevSuite site family. To join a site family: 1Select System > Multi Site Family. The Multiple Site Settings window appears. 2Click the Join Site Family button. The Join Multi Site Family wizard (Page 1) appears. 3Input the name of the site family in the Site Name text box. 4Input the site family web service URL in the Web Service URL text box. 5Input the authentication code in the Authentication Code text box. To join a site family, the site administrator must enter the authentication code generated for that site by the master site administrator. The master site administrator must send the appropriate authentication code to the work site administrators before those work sites can join the site family. 6 Optional: To test the connection to the site family web service. The Join Multi Site Family wizard (Page 2) appears. 7 Optional: To identify new users, select the check box next to the user name in the user list. The wizard identifies user account conflicts between the current project and the site family. If a user account is selected, user data will be overwritten with data imported from the master site. 8Click the Next button. The Join Multi Site Family wizard (Page 3) appears. The wizard identfies the project ID conflicts between the current projecty and the site family and creates new project ID numbers for the project.. 9Click the Next button. The Join Multi Site Family wizard (Page 4) appears. 10Click the Start button. The wizard updates project information, updates the project ID numbers, updates system administrator account. Update user information done 11Click the Next button. The Join Multi Site Family wizard (Page 5) appears. 12Click the Start button.

75 The wizard adds the current project to the selected site family. 13Click the Finish button. KnowledgeWise Projects Administration Chapter 1 KnowledgeWise Concepts 1.1 Understanding TechExcel KnowledgeWise and DevSuite TechExcel DevSuite is a family of integrated application lifecycle management (ALM) tools that place knowledge management from ideas, to formal specifications, to competitive information to issue resolution and customer insight at the core of any product development initiative. The DevSuite knowledge-centric strategy enables improve communication, keep up-to-date on changes, and reduce the development cycles so that the business may deliver the right products for the right markets in the shortest possible time. Figure 1-1: DevSuite Knowledge-Centric Development DevSuite places knowledge management at the core of all development processes. TechExcel KnowledgeWise provides for the easy and efficient collection and organization of informal ideas, gathered from a wide variety of sources, that area shared across multiple DevSpec, DevTrack, and DevTest projects. KnowledgeWise projects provide controlled access to documents, improve communication and coordination between distributed development teams, and facilitate the management and sharing of information between development teams and project stakeholders. TechExcel DevSuite leverages intellectual assets with KnowledgeWise, communicating a clear product vision and tactical execution strategy by linking ideas and customer feedback, specifications, requirements, designs, prototypes, and other documents to specific areas of work Understanding DevSuite ALM Solutions Understanding TechExcel Project Hierarchy 1.2 Understanding DevSuite Administration TechExcel DevSuite features five ALM solutions that operate in an n-tier architecture: TechExcel KnowledgeWise, TechExcel DevTrack, TechExcel DevPlan, TechExcel DevSpec, and TechExcel DevTest. All DevSuite products share the same core architecture the DevSuite Database Server, DevSuite Application Server, DevSuite Document Server, and DevSuite Web Services and are fully integrated enabling every branch of the development organization to communicate and work together. While each element is valuable even when functioning independently, the DevSuite architecture is founded upon the assumption of future scaling and is capable of advanced inter-module integration. Whether used as separate components or as an incorporated set of applications, the DevSuite solutions are ideal for companies at any stage in their product development Understanding DevSuite Site (System-Level) Administration

76 1.2.2 Understanding Project Administration 1.3 Understanding DevSuite Sample Projects and Templates At the core of every DevSuite implementation adevsuite site is one or more KnowledgeWise knowledge management projects that organize, manage, and track the knowledge collected in multiple DevSpec, DevTrack, and DevTest projects. All projects in a DevSuite site are organized into a hierarchical structure that defines the relationships between the projects in a DevSuite site. Every DevSpec or DevTrack project is the child of a parent KnowledgeWise knowledge management project and relies on that project to manage project intelligence. Figure 1-2: DevSuite Project Hierarchy KnowledgeWise enables development organizations to build a knowledge base of shared knowledge in many different media. All knowledge items may be linked with different areas of work so that internal teams and external customers can search the knowledge base for self-service content based on account type-based privileges and access controls. KnowledgeWise projects may be accessed by three methods: (1) the KnowledgeWise Web client, (2) the knowledge view of a child DevSpec project; (2) the knowledge view of a child DevTrack project Understanding Sample Projects Understanding Project Templates Understanding Solution Templates Chapter 2 Project Administration 2.1 Understanding KnowledgeWise Project Administration In DevSuite, administrative tasks are managed at two levels: the system-level and the project-level. This book describes project-level administrative tasks that apply to TechExcel DevTrack work projects. In DevSuite, the configuration and customization of work projects is the responsibility of a project administrator. Project administrative tasks include the creation and definition of projects, the definition of project settings and workflow, and team management structures Understanding Projects 2.2 Understanding the DevSuite Admin Workspace In DevSuite, a project is a tool for storing, organizing, and managing incident, event, employee, asset, knowledge, and project team data. Every DevSuite implementation called a DevSuite site may consist of multiple types of work projects including DevTrack development projects, DevSpec requirements management projects, KnowledgeWise knowledge management projects, and DevTest QA management projects. A work project is a tool for storing and managing work item and event data. The work items managed and tracked in a project are project-specific: development issues in DevTrack, test templates and test tasks in DevTest, and specifications, requirements, and change requests in DevTrack. Every work project represents a distinct area of work and is defined by unique team structures (account types, team groups, and group folders) and workflow rules Understanding Menu Bar Commands Understanding the Tool Bar Commands Logging into DevSuite Admin

77 2.2.4 Opening KnowledgeWise Projects Closing DevTrack Projects Understanding Keyboard Shortcuts 2.3 Administering KnowledgeWise Projects In DevSuite, all system- and project-level administrative tasks are performed in the DevSuite Admin client. When the System Settings project is opened, the DevSuite Admin client displays tools for configuring and administering an entire DevSuite site. Figure 2-1: DevSuite Admin Client The DevSuite Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-level features. The DevSuite Admin client is organized into four sections: Menu Bar:The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help menus. Tool Bar:The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. Tree Panel:The Tree Panel organizes administration tools into a hierarchical structure consisting of folders and folders. Page Panel:The Page Panel displays form-based administrative tools that enable the administrator to configure and maintain system-level settings Creating Knowledge Management Projects Opening KnowledgeWise Projects Backing Up KnowledgeWise Projects Restoring KnowledgeWise Projects Creating Projects Based from Backed Up Projects Copying KnowledgeWise Project Settings Understanding Active and Inactive Projects Active Projects Inactive Projects Deleting KnowledgeWise Projects Defining Project Names and Descriptions Defining Knowledge Item ID Prefixes

78 Defining Projects as Active and Inactive Defining Name Formatting Defining Project Time Zone Settings Chapter 3 Team Administration 3.1 Understanding Team Administration The KnowledgeWise clients provide project team members withcontrolledaccess to all development, facilitate communication and workflow, and improve the productivity and effectiveness of the organization. All KnowledgeWise development activities are controlled by account typed-based privileges, workflow rules, and access controls. The ability of a KnowledgeWise user account to access projects, views, folders, and pages depends on the role (account type) assigned to that user in the project. The account type concept provides administrators with the flexibility to customize project workflow and security to support their unique business requirements. KnowledgeWise team representation structures enable development organizations to define sophisticated and flexible workflow rules for managing project data and security. Project-level team administration is the process of defining team management structures (account types, team groups, and group folders), adding user accounts to the project, and assigning appropriate role and responsibilities to each project member. An account type is a set of access rights, privileges, and responsibilities that define the role that a user account plays in a project. Every user account is assigned one account type in each project. A team group is a collection of project team members that do not necessarily share the same account type but who share common responsibilities in the project. A group folder is a mechanism for managing the distribution of knowledge items in a project. 3.2 Administering Account Types, Access Controls, and Privileges In KnowledgeWise, privileges and access rights are not granted to user accounts directly, but assigned to administrator-definedaccount types. Users are assigned an account type when they join a project and assume the rights and privileges granted to that account type when a user s responsibility changes, he or she may be assigned a different account type. An account type defines the role assigned to a user account in a project and determines the projects, views, data, and reports that are available to a project team team member through the KnowledgeWise clients. In each project, the project administrator is responsible for creating all account types, granting privileges and access rights to those account types, and assigning these account types to each project members based on the role and responsibilities that user performs in the project Defining Account Types Administering Knowledge Management Privileges Administering Invisible Pages and Fields Administering Read-Only Pages and Fields Administering Report Access Controls and Privileges 3.3 Administering Project Team Members KnowledgeWise team representation provides development organizations with maximum flexibility to manage work items in workflow, enforce security, and ensure accountability. All account types are project-specific and defined by the project administrator. In KnowledgeWise, organizations are free to define the account types that best represent their business processes. For example, a typical development project might feature five different account types: the Manager account type, the System Architect account type, the Programmer account type, the Tech Support account type, and the QA account type.

79 Figure 3-1: Typical KnowledgeWise Project Account Types To create an account type: 1 Select Project Settings > Account Type in the tree panel. 2 Click the New button in the Account Types area of the Account Type page. The New Account Type dialog box appears. 3 Enter a name in the Account Type Name text box. 4 Optional: To copy privilege settings from another account type: Select the Copy Account Type Setting From check box. Select an account type from the dropdown list. 5 Click the OK button. To rename an account type: To rename an account type, select the account type in the Existing Accounts list and click the Edit button. To delete an account type.: To delete an account type, select the account type in the Existing Accounts list and click the Delete button Adding User Accounts to Projects Removing User Accounts from Projects 3.4 Administering Team Groups In KnowledgeWise, a privilege is the right to perform a specific task such as creating, editing, or deleting a work items such as a report, event, or knowledge item. In KnowledgeWise, privileges and access rights are not granted to user accounts directly, but assigned to administrator-definedaccount types. Users are assigned an account type when they join a project and assume the rights and privileges granted to that account type when a user s responsibility changes, he or she may be assigned a different account type. Using controls in the Privileges tab of the Account Type page, project members may grant knowledge item management privileges to project members of each account type in a KnowledgeWise project. Can access view:the Can Access View privilege enables the project member to access the knowledge view. Can manage all knowledge folder:the Can Manage All Knowledge Folder privilege enables the project member to create, edit, and delete knowledge folders. Can setup access control:the Can Setup Access Control enables the project member to define knowledge folder access controls. Can unlock documents checked out by other users:the Can Unlock Documents Checked Out By Other Users enables the project member to unlock knowledge items checked out by other project team members. Can perform group change:the Can Perform Group Change privilege enables the project member to edit multiple knowledge items simultaneously using a group action. Can define public query:the Can Define Public Query privilege enables the project member to create a public query. Can manually create knowledge version: The Can Manually Create Knowledge Version enables the project member to manually create a version of a knowledge item. Can delete knowledge version: The Can Delete Knowledge Version enables the project member to delete a version of a knowledge item. Can perform rollback: The Can Perform Rollback enables the project member to rollback a knowledge item to a previous version. Can create default value knowledge: The Can Create Default Value Knowledge enables the project member to define default value knowledge. Can import knowledge (including knowledge folder): The Can Import Knowledge (Including Knowledge Folder) enables the project member to import knowledge items or knowledge folders. Can access user preference: The Can Access User Preference enables the project member to personalize the KnowledgeWise client workspace. Can push user preference settings to other user:the Can Push User Preference Settings To Other User enables the project member to define personalization settings for other project team members.

80 3.4.1 Defining Team Groups Adding and Removing Project Members to Team Groups 3.5 Administering Group Folders Invisible page and field access controls enable project administrators to control which project team members may view project data based on their account type. Pages or data-entry controls that track confidential data may be displayed to project members of one account type for example, management and hidden from other account types. Using controls in the Account Type page, project administrators may define selected fields (data-entry controls) or entire pages as invisible. Figure 3-2: Invisible Tab in Account Type Page (Detail) Invisible page and field access controls are account type-based. Project administrators may also define workflow-based invisible field controls in which individual data-entry controls are hidden in particular workflow states. To define invisible pages and fields: 1 Select Project Settings > Account Type page in the tree panel. 2 Select an account type in the Account Types list. Invisible pages and fields may be uniquely defined for each account type. 3 Select the Invisible tab. The Invisible tab is only displayed in the Account Type page if invisible access controls are enabled in the project. 4 Select a page or field in the Invisible tab. The Invisible tab displays all pages and fields in a hierarchical tree structure. An invisible field is a data-entry control that cannot be viewed or edited in the client.data-entry controls may be defined as invisible fields based on account type-based access controls or state-based workflow rules. An invisible page is a system or custom page that cannot be viewed or edited in the client. Any system or custom page except the Description page may be defined as invisible to project account types. Administrators may, however, make all the individual fields in the Description page invisible Defining Group Folders Chapter 4 Knowledge Folder Administration 4.1 Administering Knowledge Item Folders In the KnowledgeWise client, knowledge items are managed in a hierarchical tree structure the knowledge item tree that organizes product knowledge items in the workspace, implements security, and enforces good development practices. Every area of development within the knowledge item tree framework is represented by a knowledge item folder. A knowledge item folder is a discreet area of work that corresponds to a specific product or version. Every knowledge item folder is defined by its folder type protected, public, or secured and a set of folder access and knowledge access controls. 4.2 Administering Knowledge Folder Function Pages The function page acts as a frame for displaying the custom and system pages that enable project team members to manage work items.project customization consists of creating custom pages and controls and adding those pages to function page so that they are displayed in the client.

81 Figure 4-1: Function Page Diagram KnowledgeWise enables project administrators to customize two knowledge folder function pages: the Add Knowledge Folder function page and the Edit Knowledge Folder function page Administering the Add Knowledge Folder Page Administering the Edit Knowledge Folder Page 4.3 Administering Knowledge Folder System Pages In the KnowledgeWise client, project members may create knowledge item folders and define knowledge item folder access controls, applicable owner rules, and applicable product rules using the Add Knowledge Item Folder window. Figure 4-2: Add Knowledge Item Folder Window The Add Knowledge Item Folder window displayed in the KnowledgeWise client is a manifestation of a customized Add Knowledge Item Folder function page. Add Knowledge Item Folder page customizations include the display of multiple system pages and custom pages. Using controls in the Knowledge Item GUI folder, project administrators may define which system pages and custom pages are displayed in the client. Project administrators may add up to three system pages and any number of custom pages to the Add Specification Folder function page. Folder Description: The Folder Description system page enables project members to define core knowledge folder properties including its title, workflow state, and owner. Applicable Product: The Applicable Product system page enables project members to identify the products and versions that are applicable to the knowledge item folder. Applicable Owner: The Applicable Owner system page enables project members to identify the user accounts, team groups, group folders, account types, and user variables that may manage the knowledge items in the folder. Access Control: The Access Control system page enables project members to define the folder type, knowledge item access level, and folder access level of each knowledge item folder. To customize the Add Knowledge Folder function page: 1Select Knowledge Folder GUI Settings > Function Pages > Submission Pages in the tree panel. 2Add or remove system pages and custom to the function page. The Available Pages list displays the Applicable Product, Applicable Owner, and Access Control system pages and all administrator-defined custom pages. To add a page to the function page, select a page in the Available Pages list and click the Right Arrow button. To remove a page from the function page, select a page in the Working Pages list and click the Left Arrow button.

82 3 Optional: To customize the title displayed in the KnowledgeWise client, input text in the Page Display Name text box Defining System Page Titles Customizing the Applicable Product System Page Customizing the Knowledge Folder Applicable Owner Page Customizing the Access Control System Page Customizing the Folder Order System Page 4.4 Administering Knowledge Folder System Fields In the KnowledgeWise client, project members may define knowledge item folder access controls, applicable owner rules, applicable product rules, and track knowledge item folder properties using the Edit Knowledge Item Folder window. Figure 4-3: Edit Knowledge Item Folder Window The Edit Knowledge Item Folder window displayed in the KnowledgeWise client is a manifestation of a customized Edit Knowledge Item Folder function page. Edit Knowledge Item Folder page customizations include the display of multiple system and custom pages. Using controls in the Knowledge Item GUI folder, project administrators may define which pages system pages and custom pages are displayed in the client. Project administrators may add up to six system pages and any number of custom pages to the Edit Knowledge Item Folder function page: Folder Description: The Folder Description system page enables project members to define core knowledge folder properties including its title, workflow state, and owner. Applicable Product: The Applicable Product system page enables project members to identify the products and versions that are applicable to the knowledge item folder. Access Control: The Access Control system page enables project members to define folder types public, protected, or secured, knowledge item access levels, and folder access levels of to each folder. Applicable Owner: The Applicable Owner system page enables project members to identify the user accounts, account types, team groups, group folders, and user variables that may own the knowledge items in the folder. Folder Order: The Folder Order system page enables project members to manage the order of the child subfolder displayed within a parent folder in the knowledge item tree panel. To customize the Edit Knowledge Folder function page: 1Select Knowledge Folder GUI Settings > Function Pages > Submission Pages in the tree panel. 2Add or remove system pages and custom to the function page. The Available Pages list displays the Applicable Product, Applicable Owner, Access Control, Change Log, Folder Order, and Time Report system pages and all administrator-defined custom pages. To add a page to the function page, select a page in the Available Pages list and click the Right Arrow button. To remove a page from the function page, select a page in the Working Pages list and click the Left Arrow button. 3 Optional:To customize the title of the page displayed in the KnowledgeWise client, input text in the Page Display Name text box Displaying Access Controls in Custom Pages

83 Chapter 5 Knowledge Item Administration abc 5.1 Understanding KnowledgeWise Knowledge Items In KnowledgeWise, knowledge items administration is the process of defining structures for recording, managing, and tracking knowledge items in a project. Knowledge Item management structures include knowledge item folders, knowledge items, and knowledge item workflow. All knowledge items are managed in the knowledge item view of the KnowledgeWise client. Project administrators may define the knowledge item object, define workflow rules, and customize the client GUI to enable project members to effectively manage those objects. 5.2 Administering Knowledge Item Function Pages The function page acts as a frame for displaying the custom and system pages that enable project team members to manage work items.project customization consists of creating custom pages and controls and adding those pages to function page so that they are displayed in the client. The function page acts as a frame for displaying the custom and system pages that enable project team members to manage work items.project customization consists of creating custom pages and controls and adding those pages to function page so that they are displayed in the client. KnowledgeWise enables project administrators to customize five knowledge item function pages: the Add Knowledge function page, Edit Knowledge function page, Forward Folder function page, Version function page, Knowledge Template function page, Group Change function page, Group Forward function page, KW Search function page, KW S page, and KW Search function page. Add Knowledge:The Add Knowledge function page enables the user to define core knowledge item properties and to submit new knowledge items to the project. Edit Knowledge:The Edit Knowledge function page enables the user to edit core knowledge item properties. Detail Knowledge:The Detail Knowledge function page enables the user to view knowledge item details. Forward Knowledge;The Forward function page enables the user to update core knowledge item properties and to forward a knowledge item to another user or workflow state. KW Search for KnowledgeWise Project Team Members:The KW Search for KnowledgeWise Project Team Members h function page enables KnowledgeWise project team members to search for knowledge items in the KnowledgeWise project. KW Search for Non- KnowledgeWise Project Team Members:The KW Search for Non-KnowledgeWise Project Team Members function page enables DevTrack and DevSpec project team members to search for knowledge items in the KnowledgeWise project. KW Search. for Non- Project Team Members:The KW Search. for Non- Project Team Member function page enables non-project members (such as customers) to search for knowledge items in the KnowledgeWise project Administering the Add Knowledge Item Function Page Administering the Edit Knowledge Item Function Page Administering the Knowledge Item Detail Function Page Administering the Forward Knowledge Item Function Page 5.3 Administering Knowledge Item System Pages In the KnowledgeWise client, project members may create new knowledge items and define knowledge item properties using the Add Knowledge Item window a multiple-page tabbed form. The Add Knowledge Item window displayed in the KnowledgeWise client represents administrator-defined Add Knowledge Item function page. The Add Knowledge Item function page may display the Knowledge Description system page and all custom pages. To customize the Add Knowledge Item function page: 1Select Knowledge GUI Settings > Function Pages > Submission Pages in the tree panel. 2Add or remove system pages and custom to the function page. To add a page to the function page, select a page in the Available Pages list and click the Right Arrow button. To remove a page from the function page, select a page in the Working Pages list and click the Left Arrow button. 3 Optional:To define the title displayed in the KnowledgeWise client, input text in the Page Display Name text box Administering the Knowledge History System Page Administering the Version System Page Administering the Knowledge Event System Page Administering the Knowledge Item All Links System Page Administering the Linked Knowledge System Page

84 5.4 Administering Knowledge Item Fields and Controls In the KnowledgeWise client, project members may define or update knowledge item properties in the Edit Knowledge Item window a multiple-page form that may display the All Links, Linked Knowledge, and Events pages as well as any number of custom pages. The Edit Knowledge Item window displayed in the KnowledgeWise client represents administrator-defined Edit Knowledge Item function page. The Edit Knowledge Item function page may three system pages and any number of custom pages: Knowledge DescriptionP:The Knowledge Description system page enables project members to define core knowledge item properties including its title, workflow state, and owner. All Links:The Knowledge Item All Links system page enables project members to track, link, and manage the knowledge items, knowledge items, and change requests that are associated with a knowledge item. Linked Knowledge:The Linked Knowledge system page enables project members to track, link, and manage the knowledge items, and knowledge items that are associated with a knowledge item. Events:The Knowledge Item Events page enables project members to create, edit, delete, and track the events. Version:The Version system page enables project members to manage and track multiple versions of knowledge items. To customize the Edit Knowledge Item function page: 1Select Knowledge GUI Settings > Function Pages > Editing Pages in the tree panel. 2Add or remove system pages and custom to the function page. To add a page to the function page, select a page in the Available Pages list and click the Right Arrow button. To remove a page from the function page, select a page in the Working Pages list and click the Left Arrow button. 3 Optional:To define the title displayed in the KnowledgeWise client, input text in the Page Display Name text box Understanding Knowledge Item System Fields 5.5 Administering Knowledge Item List Columns In the KnowledgeWise client, project members may manage and track knowledge item properties in the knowledge item detail panel of the knowledge item view. The knowledge item detail panel shows detailed information about a single knowledge item in multiple tabbed pages including the All Links, Linked Knowledge, History, and Events pages as well as any number of custom pages. Using controls in the Knowledge Item GUI folder, project administrators may add or remove system pages and custom pages to the Knowledge Item Detail function page: Knowledge Description:The Knowledge Description system page enables project members to define core knowledge item properties including its title, workflow state, and owner. All Links:The Knowledge Item All Links system page enables project members to track, link, and manage the knowledge items, knowledge items, and change requests that are associated with a knowledge item. Linked Knowledge:The Linked Knowledge system page enables project members to track, link, and manage the knowledge items, and knowledge items that are associated with a knowledge item. Version:The Version system page enables project members to manage and track multiple versions of knowledge items. Events:The Knowledge Item Events page enables project members to create, edit, delete, and track the events that are associated with a knowledge item History:The History system page provides project members with a read-only audit log of a knowledge item in four standard reports the Change Log report, the Owner State Change History report, the Summary report, the Tracking History report and any number of custom reports. To customize the Detail Knowledge Item function page: 1Select Knowledge GUI Settings > Function Pages > Detail Pages in the tree panel. 2Add or remove system pages and custom to the function page. To add a page to the function page, select a page in the Available Pages list and click the Right Arrow button. To remove a page from the function page, select a page in the Working Pages list and click the Left Arrow button. 3 Optional:To define the title displayed in the KnowledgeWise client, input text in the Page Display Name text box Displaying Knowledge System Fields in the Knowledge List Panel Customizing Knowledge Item List Indicator Icons Customizing Knowledge Item List Font Colors and Weights 5.6 Administering Knowledge Item-Level Knowledge Management In the KnowledgeWise client, project members may reassign knowledge items to other project members in workflow using the Forward Knowledge Item window a multiple-page form that may any number of custom pages. The Forward Knowledge Item window displayed in the KnowledgeWise client represents administrator-defined Forward Knowledge Item function page. No system pages are displayed in the Forward Knowledge Item page. The Forward Knowledge Item function page may display the Knowledge Description system page and all administrator-defined custom pages.

85 To customize the Forward Knowledge Item function page: 1Select Knowledge GUI Settings > Function Pages > Forward Pages in the tree panel. 2Add or remove system pages and custom to the function page. To add a page to the function page, select a page in the Available Pages list and click the Right Arrow button. To remove a page from the function page, select a page in the Working Pages list and click the Left Arrow button. 3 Optional:To define the title displayed in the KnowledgeWise client, input text in the Page Display Name text box Enabling Spell Checking in the Description Control Enabling HTML Formatting in the Description Control Chapter 6 Secured Access Level Administration 6.1 Understanding Secured Knowledge Access Level Security Secured access levels are an optional DevSuite Enterprise Edition feature that enable development organizations to define flexible folder-level and knowledge item-level access controls. In KnowledgeWise, every secured knowledge folder and secured knowledge item is defined by its name, status, and one or more access levels. An access level is a set of administrator-defined access controls that define which project members may view, create, edit, and delete a secured knowledge folder or secured knowledge item. In the KnowledgeWise, knowledge folders may be defined as public, protected, or secured. If the knowledge folder is a secured folder, it is defined by one or more access levels. Secured folder access controls and secured knowledge item access controls are defined on a folder-by-folder basis. Each secured folder may be defined by one or more access levels. Distinct access levels may be assigned to a secured knowledge folder and to the knowledge items it contains. Project Members may only manage a secured knowledge folder or secured knowledge item if they have been granted access rights within an access level that defines that knowledge folder or knowledge item. Secured knowledge access level administration is the process of creating knowledge folder and knowledge item access levels, and of assigning access types to project team members based on their account type, team group, or user account Understanding Access Level Conflict Resolution Rules Comparison with Public and Protected Access Controls 6.2 Administering Knowledge Folder Secured Access Levels Unlike public and protected access controls, which are strictly account type-based,secured access levelaccess controls are defined by account type, team group,anduser account. As a result, a project member may be granted three or more sets of access rights calledaccess types within the same access level: one for their account type, one for their user account, and one for each team group membership. Secured access level rules ensure that each project member is granted maximum access within each access level based on the access types assigned to them unless their access rights are assigned by name. For example, If Terry Johnson is assigned two access types one for hisaccount typeand one for histeam group, the access type that provides the greatest access defines his access rights in that access level. However, if Terry Johnson is assigned an access type based on his user account, he is assigned the access rights granted by that access type regardless of all other considerations. The access type assigned to a project team member by name that is, based on his or her user account always determines which access rights are granted to that user. If no access type is granted to the user by name, the access type that provides the project member with greater access is assigned to that project team member Defining Knowledge Folder Access Levels Defining User Account Access Levels 6.3 Administering Knowledge Item Access Levels In KnowledgeWise, project member access to knowledge folders and knowledge items may be controlled using account-type basedpublic access controls,protected access controls, orsecured access controls. All public and protected access controls are defined by the project administrator and are implemented uniformly throughout the project all public folders are

86 defined by the same access controls and all protected knowledge items are defined by the same access controls. Project team members may designate a knowledge folder as public or protected, but they cannot define access rights that are tailored to specific folders or knowledge items. Using secured knowledge access controls, project members may define the level of access (access level) that is required to view, create, edit, or delete the folders and knowledge items within a secured folder Defining Knowledge Folder Access Levels Defining User Account Access Levels 6.4 Administering Non-Member Access Levels Secured folder access levels are an optional DevSuite Enterprise Edition feature that enable development organizations to define flexible folder-level access controls. In KnowledgeWise, every secured knowledge folder is defined by its name, status, and one or moreaccess levels. An access level is a set of administrator-defined access controls that define which project members may view, create, edit, and delete asecured knowledge folder. The access level required to manage secured knowledge folders (and their contents) is defined on a folder-by-folder basis. A project member may view and manage a secured knowledge folder only if are granted access rights by an access level that is applicable to that secured folder. Within each access level, access rights are assigned to project members based their account type, user account, or team group membership. Chapter 7 Page, Field, and Control Administration 7.1 Understanding KnowledgeWise Client GUI Customization KnowledgeWise project administration is largely the process of defining structures for recording, managing, and tracking knowledge items in workflow and maintaining multiple versions of each knowledge item. Customized project management structures are manifested in the KnowledgeWise client as views, panels, folders, and pages. A view is an interface that displays and organizes data in the client workspace. Views enable project members to manage and track different types of data using structures that are specifically designed to manage that data. The building blocks of each view folders, pages, and controls may be customized to support custom business processes. knowledge tree panel:the tree panel is a hierarchal structure composed of folders and subfolders that organizes knowledge items into distinct areas of work. knowledge list panel:the list panel shows high-level information about multiple knowledge items in a tabular format of rows and columns. knowledge detail panel:the detail panel displays detailed about a single knowledge item or knowledge folder in one or more form pages. The building blocks of client interface include: controls, folder pages, and form pages. Control:A control is a GUI element displayed in a folder page or custom page that enables the user to define, update, and track data. KnowledgeWise supports system controls and custom controls. Controls are displayed in system pages and custom pages. Each controls represents a knowledge item field. The function page acts as a frame for displaying the custom and system pages that enable project team members to manage work items.project customization consists of creating custom pages and controls and adding those pages to function page so that they are displayed in the client.

87 7.2 Administering System Pages Figure 7-1: Function Page Diagram In KnowledgeWise, a system page is a predefined page that enables project members to perform a specific task such as collecting, managing, and tracking project data. Each system pages features one or more system controls. A system control is a system-defined control that represents a predefined system field and features control-specific functionality. System fields represent core object properties such as workflow states and object statuses and the data tracked in these fields is frequently forms the foundation of TechExcel businesses rules. Like custom pages, system pages may be added to function pages to build the multiple-page forms that enable project members to manage knowledge items in project view. Knowledge folder system pages enable a user to manage the knowledge folders in the knowledge tree panel of the knowledge view. 7.3 Administering Custom Pages In KnowledgeWise, a custom page is a form conceived, designed, and built by a project administrator that enables project members to collect, manage, and track project data. Each custom page may display system controls and custom controls. Using custom pages, system controls, and custom controls, a business may create forms that are uniquely designed to manage and track data that is specific to their environment and business. Figure 7-2: Custom Page Like system pages, custom pages may be added to function pages to build the multiple-page forms that enable project members to manage knowledge items in project views. Project administrators may add and remove system, custom, and multiple-selection controls to custom pages, customize the layout of controls in the page, and define their the tab order Creating Custom Pages Adding Controls to Custom Pages Removing Controls From Custom Pages Ordering Controls in Custom Pages Adding Static Labels

88 7.3.6 Understanding Custom Page Form Design Commands Aligning Custom Controls and Labels Resizing Controls and Labels 7.4 Administering System Controls A custom page is a form conceived, designed, and built by a project administrator that enables project members to collect, manage, and track project data. To create a custom page: 1Right-click a Custom Pages folder and select the Add New Page command in the shortcut menu. Custom pages may be created for knowledge folders or knowledge items. The custom page is displayed in the workspace. 2Input the title of the custom page in the Page Display Name text box. The display name defines the text that identifies the tabbed page in the client. By default, the custom page is given the title New Page. 3Add custom controls or system controls. 4Define the tab order of the controls displayed in the custom page. 7.5 Administering Custom Fields and Controls To add a control to a custom page: 1Right-click in the custom page and select the Add Control command in the shortcut menu. The Add New Field manager appears. The Add New Field manager displays every custom controls and system controls that may be added to the custom page. 2 Optional: To filter controls by control type, select an option from the Field Type dropdown list. The Field Type dropdown list displays multiple control types including the dropdown list control type, short text box control type, and the field label control type. KnowledgeWise enables administrators to define controls based on 17 different control types. 3 Optional: To define how the control is presented in the page, select an option from the Label Alignment dropdown list. The Label Alignment dropdown list displays three options: Right Aligned Left Aligned Center Aligned 4 Optional: To define control as read only in the page, select the Add It as Read Only check box. A read-only control is a control that is displayed, but cannot be edited. 5Click the OK button Understanding Control Types Customizing Check Box Controls Customizing Date-Time Controls Customizing Short Text Box Controls Customizing Multiple-line Text Box Controls Customizing Composed Field Controls 7.6 Customizing Selection and Combination Box Controls To remove a control to a custom page: 1Select a control in the custom page. 2Right-click and select the Delete Control command in the shortcut menu.

89 Note:The control is not deleted, but simply removed from the page. The control may subsequently be added to the page or another page. A confirmation dialog box appears. 3Click the Yes button Defining Selection List Options (Manually) Defining Selection List Options (From Lookup Fields) Defining Parent-Child Relationships Between Controls Customizing Autogrow Combo Box Controls Customizing Combo Box Controls Customizing Dropdown List Controls Customizing Multiple Selection Controls New Section 7.7 Administering Calculation Fields and Controls The control with the lowest tab order number is the control that is immediately active when the page is accessed in the client. To define the tab order of controls in a custom page: 1Select a custom page in a Custom Pages folder. 2Click the Define Field Tab Order button in the custom page. 3The Field Tab Order dialog box appears. The Field Tab Order dialog box displays a list of the custom controls and system controls that have been added to the custom page. 4Define the tab order of each control in the page relative to the other controls displayed in the page. To move the control up the list, select the control and click the Up arrow. The lower the tab order number, the earlier the control may be accessed. To move the control down the list, select the control and click the Down arrow. The greater the tab order number, the later the control may be accessed. 5Click the OK button Defining Numerical Calculation Controls Defining Date Calculation Controls Defining Selection Calculation Factors Chapter 8 Workflow Administration 8.1 Administering Knowledge Item Workflow Workflow is a business process that may be used to manage the tasks that compose a project. Workflow rules enable project managers to define and track the flow of work between individuals and teams. A well-defined set of workflow rules enables an organization to perform tasks in an efficient and repeatable manner. In KnowledgeWise, workflow defines the life cycle of the knowledge items managed in the project. The knowledge item lifecycle is comprised of multipleworkflow states each workflow state represents a specific stage in the knowledge item lifecycle and defines rules for managing the knowledge item at that stage. For example, project workflow might consists of six workflow states: {New}, Proposed, Approved, Draft, Finalized, and In Design.

90 Figure 8-1: Knowledge Item Workflow Transitions Each node represents a knowledge item workflow state. The arrows between each node represent the transition between those workflow states. The closed states are darkened. KnowledgeWise workflow is completely customizable. The lifecycle of project knowledge may consists of as many workflow states as are needed to represent the needs of a business. Every workflow state is as anopen workflow stateor aclosed workflow state. The status assigned to a workflow state determines how the knowledge item is managed in that state. The knowledge item life cycle consists of at least two workflow states: an open workflow state and an closed workflow state. By default, all new knowledge items start in thenew workflow state, an open state. Workflow administration is the task of defining workflow states and the transitions between those states, defining workflow-based access controls, and knowledgeitem versioning rules Enabling Support for Knowledge Workflow Rules Defining Workflow States Defining Workflow Transitions Defining State-Based Access Controls Defining Transition-Based Access Controls Defining State-Based Applicable Owners and Default Owners Defining Knowledge State Versioning Rules Defining State-Based Read-Only Knowledge Item Fields Defining State-Based Mandatory Knowledge Item Fields Defining State-Based Invisible Knowledge Item Fields 8.2 Administering Knowledge Item State Groups For every workflow state, the project administrator may defines rules for managing the knowledge item at that stage in the knowledge lifecycle. All KnowledgeWise workflow rules are optional and must be enabled by the project administrator before they may defined. Optional workflow rules include support state-to-state transitions, applicable owner rules, state-based invisible, read-only and mandatory fields, automatic versioning, and a choice between state-based or transition-based access controls: Using controls in the Workflow Option page, project administrators may enable KnowledgeWise workflow rules in a project. To enable workflow access control support: 1 Select Workflow > Workflow Options in the tree panel. 2 Optional: To enable support for state-to-state transitions, select the State-to-State check box. State-to-state transition rules define all possible transitions between workflow states. A knowledge item may pass from one workflow state to next only if a transition exists between those to workflow states. 3 Optional: To enable support for state-based applicable owner rules, select the Enable Applicable Owners check box. Applicable Owners rules define which project members may own a knowledge item in each workflow state based on their account type, team group, group folder, system variable, or user account. 4 Optional: To enable support for field-level access controls, select check box next to the appropriate field access control. KnowledgeWise supports workflowbased invisible fields, read-only fields, and mandatory fields. Read-only Fields Invisible Fields Mandatory Fields

91 5 Optional: To define state-based or transition-based access controls, select an option in the Who Can Change State dropdown list. Transition-based access controls State-based access controls WhoCanChangeStateaccess controls must be defined if the state-to-state workflow rule is enabled in the project. 6 Optional: To enable support for automatic versioning, select the Enable Automatic Version Increase check box and one or more knowledge item fields in the Version Increase list. Automatic Version Increase rules define which knowledge item properties may be automatically updated during knowledge item workflow Enabling Knowledge Item State Group Support Creating New Knowledge Item State Groups Defining Knowledge Item State Groups Chapter 9 Event Administration 9.1 Administering KnowledgeWise Events Throughout the project planning process, project managers may schedule and manage team meetings as events. An event is a management task that facilitates communication and collaboration between project stakeholders. Typical events include brainstorming sessions, team meetings, design reviews, management reviews, presentations, and product demos. In KnowledgeWise, events are the vehicle that drive the planning process and ensure the quality of the end product. Regular team meetings scheduled within KnowledgeWise enable project managers ensure that all project team members are working together to meet project objectives. Every KnowledgeWise event is based on an administrator-definedevent template. An event template is a blueprint for creating a specific type of event such as a meeting, presentation, or demo that defines the business rules that determine how that event is managed in the project. Event administration, therefore, is the largely a matter of creating event templates, defining the rules that manage events based on that template, and determining when events based on that event template may be created in the project. 9.2 Administering Event Templates An event template defines the business rules that are used to manage the events based on that template including the applicable owners, account type-based access controls, and workflow settings. Using controls in the Event Template page, project administrators may create and define multiple event templates. For each event template created in the Event Template page, the project administrator must define appropriate properties, access controls, an event group, and event workflow rules. Creating Event Templates Each event template represents a specific type of event such as a meeting, presentation, or demo and defines who may own the event, who may attend the event, and how the event is managed in workflow. To create an event template: 1Click the New button in the Event Template page of the Event subfolder. The Add a New Event Template dialog box appears. 2Define a unique, descriptive name for the event template in the Name text box control. The title of the event template is inherited by every event based on that template and is the default title for those event instances. For more information see Defining Default Event Titles and Descriptions. 3Define a brief description of the event in the Description field. Event template descriptions enable project manager to describe the purpose and functionality of an event template. 4Click the OK button. The Add a New Event Template dialog box closes. The event template is displayed in the Events folder of the Event Templates tree control. Editing Event Templates Project administrators may edit basic event template properties in the Properties tab of the Event Templates page in the Events folder. The Event Type property cannot be updated. Both event template properties are mandatory and can only be defined when the project administrator initially creates the event template. Deleting Event Templates Project administrators delete event templates in the Event Template page of the Event subfolder. To delete event templates:

92 1Select the Event Template page in the Admin Tree window. 2Select an event template in the Event Templates list. 3Click the Delete button in the Event Templates area. A confirmation dialog box appears. 4Click the Yes button. The event template disappears from the Event Templates tree control Defining Default Event Titles and Descriptions Defining Default Event Workflow States Defining Default Event Owners 9.3 Administering Event Workflow Every event is defined by a title and a description of the event. The title and description of events are tracked in two data-entry controls: the Title control and the Description control. Project administrators may define default event titles and event descriptions for each event template. Every event that is based on that event template inherits the predefined title and description. To define default event titles and descriptions: 1Select an event template in the Event Templates tree list control of the Event Templates page. 2Define the title of the event in the Title control. Every event based on the event template is automatically given the title defined in the event template. 3Define the description of the event in the Description control. Every event based on the event template automatically inherits the description defined in the event template. 4Click the OK button Creating Event States Editing Event States Deleting Event States 9.4 Administering Event Access Controls In the KnowledgeWise client, project members may track the progress of a event in the State dropdown list. Each event state represents a particular stage of the life cycle that defines an event from initial creation to its closure and one or more intermediary steps. The default workflow state is the event state that automatically defines newly created events. Project administrators may define default event workflow states for each event template Every event that is based on that event template inherits all administrator-defined event settings including the default event state. Project administrators may customize the title of data-entry control, define a default state, and define the options that are available in the State dropdown list in each event template. DevSpec Projects Administration Chapter 1 DevSpec Concepts 1.1 Understanding TechExcel DevSpec and DevSuite TechExcel DevSuite is a family of integrated application lifecycle management (ALM) tools that place knowledge management from ideas, to formal specifications, to competitive information to issue resolution and customer insight at the core of any product development initiative. The DevSuite knowledge-centric strategy enables improve communication, keep up-to-date on changes, and reduce the development cycles so that the business may deliver the right products for the right markets in the shortest possible time.

93 Figure 1-1: DevSuite Knowledge-Centric Development DevSuite places knowledge management at the core of all development processes. TechExcel KnowledgeWise provides for the easy and efficient collection and organization of informal ideas, gathered from a wide variety of sources, that area shared across multiple DevSpec, DevTrack, and DevTest projects. KnowledgeWise projects provide controlled access to documents, improve communication and coordination between distributed development teams, and facilitate the management and sharing of information between development teams and project stakeholders. TechExcel DevSuite leverages intellectual assets with KnowledgeWise, communicating a clear product vision and tactical execution strategy by linking ideas and customer feedback, specifications, requirements, designs, prototypes, and other documents to specific areas of work. 1.2 Understanding DevSuite ALM Solutions TechExcel DevSuite features five ALM solutions that operate in an n-tier architecture: TechExcel KnowledgeWise, TechExcel DevTrack, TechExcel DevPlan, TechExcel DevSpec, and TechExcel DevTest. All DevSuite products share the same core architecture the DevSuite Database Server, DevSuite Application Server, DevSuite Document Server, and DevSuite Web Services and are fully integrated enabling every branch of the development organization to communicate and work together. KnowledgeWise DevPlan DevSpec DevTrack TechExcel DevSuite leverages intellectual assets with KnowledgeWise, communicating a clear product vision and tactical execution strategy by linking ideas and customer feedback, specifications, requirements, designs, prototypes, and other documents to specific areas of work during a development project. Documents are shared with all resources involved in the execution of the project allowing for an uncompromised vision to direct the path of any development project. TechExcel DevPlan manages the transformation of concepts into formal strategic plans. DevPlan offers an intuitive planning hierarchy to formalize scope and optimize resource usage, team-based planning and calendaring capabilities. These features enable complete control over all product development projects from design planning to implementation and enables increased team efficiency and collaboration. TechExcel DevSpec is an integrated requirements management solution that is specifically designed to provide visibility, traceability and validation of your product or project requirements. DevSpec provides a frame work to create new requirements, specifications and features that can be linked to development and testing implementation projects. TechExcel DevTrack enables development teams to manage every aspect of the development process including issue

94 management, team management, and communications management. DevTest TechExcel DevTest is a test management solution that enables test organizations to manage every stage of testing life cycle from test case design, to test execution, to test analysis. DevTest provides testing groups with the tools they need work more effectively and efficiently, hold down costs, and to deliver higher quality products. While each element is valuable even when functioning independently, the DevSuite architecture is founded upon the assumption of future scaling and is capable of advanced inter-module integration. Whether used as separate components or as an incorporated set of applications, the DevSuite solutions are ideal for companies at any stage in their product development Understanding TechExcel Project Hierarchy 1.3 Understanding DevSuite Administration At the core of every DevSuite implementation adevsuite site is one or more KnowledgeWise knowledge management projects that organize, manage, and track the knowledge collected in multiple DevSpec, DevTrack, and DevTest projects. At the core of every DevSuite implementation adevsuite site is one or more KnowledgeWise knowledge management projects that organize, manage, and track the knowledge collected in multiple DevSpec, DevTrack, and DevTest projects. All projects in a DevSuite site are organized into a hierarchical structure that defines the relationships between the projects in a DevSuite site. Every DevSpec or DevTrack project is the child of a parent KnowledgeWise knowledge management project and relies on that project to manage project intelligence. Figure 1-2: DevSuite Project Hierarchy KnowledgeWise enables development organizations to build a knowledge base of shared knowledge in many different media. All knowledge items may be linked with different areas of work so that internal teams and external customers can search the knowledge base for self-service content based on account type-based privileges and access controls. KnowledgeWise projects may be accessed by three methods: (1) the KnowledgeWise Web client, (2) the knowledge view of a child DevSpec project; (2) the knowledge view of a child DevTrack project. 1.4 Understanding DevSuite Site (System-Level) Administration In DevSuite, administrative tasks are managed at two levels: system administration and project administration. Site Administration: DevSuite system administration is the process of configuring, administering, and maintaining a DevSuite site. System-level administration activities include maintaining the implementation, creating and defining new projects, managing user accounts, managing licenses, and configuring the DevSuite Server. Project Administration: DevSuite project administration is the process of defining project-level settings and business objects, customizing project GUIs, configuring workflow rules, managing project team representation and access controls, and integrating add-on modules. All DevSuite site and project administrative tasks are performed in the DevSuite Admin client. The DevSuite Admin client provides DevTrack, DevPlan, DevSpec, and KnowledgeWise system and project administrators with a single interface for defining, configuring, and administering TechExcel sites and projects. All DevSuite site and system-level administrative tasks are performed in a System Settings project. Every DevSuite site consists of a single System Settings project.

95 Settings defined in a system settings project apply to every work project in that site. All project-level administrative tasks are defined on a project-by-project basis and are only applicable to a single work project. In DevSuite 1, project administrators may define four types of projects: KnowledgeWise projects, DevSpec projects, DevTrack projects, and DevTime projects. Note: DevTest projects may be defined, configured, and administered in the DevTest Admin client. All other DevSuite projects are managed in the DevSuite Admin client. 1.5 Understanding Project Administration DevSuite system administration is the process of configuring, administering, and maintaining a DevSuite site. A site consists of a system settings project and one or more work projects. Every work project in a DevSuite site shares a common database, knowledge base, and other system-level configurations that are defined in the DevSuite Admin client. System-level configurations define the DevSuite site and the integration of every project within that site. In DevSuite, system administration is the process of defining system, user, and project settings that define work in a DevSuite site. A DevSuite site is an implementation of a DevSuite server and may include multiple DevTrack, DevSpec, DevPlan, and DevSpec projects. System-level settings are settings that apply to every project in the DevSuite site. DevSuite system administration tasks fall into seven general areas: System Administration: System-level settings administrative tasks include the configuration of the DevSuite Server. User Administration: System-level user administrative tasks include the definition and management of user accounts and project administrators. Optional system-level administrative tasks include multiple site management, division management, and LDAP directory server integration and administration. Multiple Site Administration: Multiple site administration includes the definition and management of a site family and management of user licenses for all member sites. License Management: System-level license administrative tasks include license management and allocation Web Administration: Web administration includes the definition and configuration of DevTrack Web Server settings for every DevTrack project in the site. Integration: integration and administration is the foundation of DevTrack, DevPlan, and DevSpec notification and escalation. Branch Development: Release management administration defines the product structures that are shared across DevTrack, DevSpec, and DevPlan project providing a common framework for organizing and managing the development of products, versions, and builds. Time And Cost Tracking Administration: Time and cost tracking administration defines the project management tools that enable a business to measure and track project resources. System-level user administrative tasks include license management and allocation, user account creation and definition, and the management of project administrators. Optional system-level administrative tasks include multiple site management, division management, and LDAP directory server integration and administration. 1.6 Understanding DevSuite Sample Projects and Templates DevSuite project administration is the process of defining project-level settings and business objects, customizing project GUIs, configuring workflow rules, managing project team representation and access controls, and integrating add-on modules. Project administrators define what is tracked in the project, how it is tracked, and who may track the data. All project-level configurations are project-specific and apply to a single KnowledgeWise, DevSpec, DevTrack, or DevTime project. Project administration tasks may be broken into five inter-related areas: Project Definition and Configuration Team Representation Administration Work Item Definition and GUI Customization Workflow Administration Add-on Module Integration 1.7 Understanding Sample Projects

96 DevSuite builds on TechExcel's commitment to the rapid deployment of its ALM by providing development organizations with the tools they need to quickly configure and implement projects that enforce good development practices and drive the quality of releases. To facilitate the configuration of a fully integrated site and projects that support your development processes, DevSuite provides developers with tools for evaluating and testing DevSuite features. Sample Projects: A sample project is a project that provides development organizations with a sandbox for configuring and evaluating DevSuite features and integrations in a risk free environment. Project Templates: A project template is a blueprint for creating a project of a s pecific type. Solution Templates A solution template is a preconfigured project that facilitates the definition of DevSpec projects that implement five proven development methodologies: CMMI, Scrum, SpecDD, TDD, and Iterative Development. 1.8 Understanding Project Templates In DevSuite, a sample project is a project that provides the development organization with a sandbox for configuring and evaluating features and integrations in a risk free environment. DevSuite features ten predefined projects that provide development organizations with a sandbox to experiment with KnowledgeWise, DevSpec, and DevTrack tools and features. All sample projects include sample data, sample project team members, and fully configured workflow rules. Project administrators may freely configure sample projects to represent their development processes. Project configurations and settings tried and tested in sample projects may be imported into newly created live projects. Sample projects provide development organizations with a tool for training new users or to introduce existing users to new features or changes in businesses processes. Using controls in the DevSuite Admin client, administrators may create additional sample KnowledgeWise, DevSpec, and DevTrack projects. 1.9 Understanding Solution Templates In DevSuite, a project template is a blueprint for creating a project of a specific type KnowledgeWise knowledge management projects, DevSpec requirements management projects, or DevTrack development projects. Each project template defines a complete set of project-level settings including the definition of all project business objects, workflow rules, team representation, and project integrations. Project templates may be used to quickly configure new projects whenever they are created in a DevSuite site. Chapter 2 Project Administration 2.1 Understanding DevSpec Project Administration In DevSuite, administrative tasks are managed at two levels: the system-level and the project-level. This book describes project-level administrative tasks that apply to TechExcel DevSpec work projects. In DevSuite, the configuration and customization of work projects is the responsibility of a project administrator. Project administrative tasks include the creation and definition of projects, the definition of project settings and workflow, and team management structures Understanding Projects 2.2 Understanding the DevSuite Admin Workspace In DevSuite, a project is a tool for storing, organizing, and managing incident, event, employee, asset, knowledge, and project team data. Every DevSuite implementation called adevsuite site may consist of multiple types of work projects including development projects, timesheet projects, KnowledgeWise projects, and DevTest projects. A work project is a tool for storing and managing work item and event data. The work items managed and tracked in a project are project-specific: development issues in DevTrack, test templates and test tasks in DevTest, and specifications, requirements, and change requests in DevSpec. Every work project represents a distinct area of work and is defined by unique team structures (account types, team groups, and group folders) and workflow rules. In DevSuite, the work projects in a DevSuite site are organized into a hierarchical structure that determines the relationships between KnowledgeWise projects, DevSpec projects, and DevTrack projects.

97 Figure 2-1: DevSuite Project Hierarchy Understanding Menu Bar Commands Understanding the Tool Bar Commands Logging into DevSuite Admin Opening DevSpec Projects Closing DevTrack Projects Understanding Keyboard Shortcuts 2.3 Administering DevSpec Projects In DevSuite, all system- and project-level administrative tasks are performed in the DevSuite Admin client. When the System Settings project is opened, the DevSuite Admin client displays tools for configuring and administering an entire DevSuite site. Figure 2-2: DevSuite Admin Client The DevSuite Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-level features. The DevSuite Admin client is organized into four sections: Menu Bar: The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help menus. Tool Bar: The tool bar displays controls that enable administrators to perform system-level and project-level administrative tasks. Tree Panel: The Tree Panel organizes administration tools into a hierarchical structure consisting of folders and folders. Page Panel: The Page Panel displays form-based administrative tools that enable the administrator to configure and maintain system-level settings Creating DevSpec Projects

98 2.3.2 Backing Up DevSpec Projects Restoring DevSpec Projects Creating Projects Based from Backed Up Projects Chapter 3 Team Administration 3.1 Understanding Team Administration The DevSpec client provides project team members with controlled access to all change management artifacts and activities, facilitates communication and workflow, and improves the productivity and effectiveness of the organization. All DevSpec change management activities are controlled by account typed-based privileges, workflow rules, and access controls. The ability of a DevSpec user account to access projects, views, folders, and pages depends on the role (account type) assigned to that user in the project. The account type concept provides administrators with the flexibility to customize project workflow and security to support their unique business requirements. DevSpec team representation structures enable development organizations to define sophisticated and flexible workflow rules for managing project data and security. Project-level team administration is the process of defining team management structures (account types, team groups, and group folders), adding user accounts to the project, and assigning appropriate role and responsibilities to each project member. Account Type:An account type is a set of access rights, privileges, and responsibilities that define the role that a user account plays in a project. Every user account is assigned one account type in each project. Team Group:A team group is a collection of project team members that do not necessarily share the same account type but who share common responsibilities in the project. Group Folder:A group folder is a mechanism for managing the distribution of work items in a project. 3.2 Administering Account Types, Privileges, and Access Controls In DevSpec, privileges and access rights are not granted to user accounts directly, but assigned to administrator-defined account types. Users are assigned an account type when they join a project and assume the rights and privileges granted to that account type when a user s responsibility changes, he or she may be assigned a different account type. In each project, the project administrator is responsible for creating all account types, granting privileges and access rights to those account types, and assigning these account types to each project members based on the role and responsibilities that user performs in the project. For example, a DevSpec project might provide controlled access to eight different account types: the Program Manager account type, the Project Manager account type,the Designer account type, the Lead Designer account type, the Developer account type, the Sales account type, and the Marketing account type. Figure 3-1: Typical DevSpec Project Account Types Each account type would confer a different set of access rights, privileges, and responsibilities as befit the role played in the project by its team members and stakeholders. DevSpec uses access rights and privilege controls to coordinate project members in workflow and implement security in projects. Access Right: An access right defines whether a project member may view or edit a page or data-entry control in the client. DevSpec supports both account type-based access controls and workflow-based access controls. Privilege:A privilege is a right to perform a task that is granted to project members based on their account type. Every project member is assigned an account type when they join a project. Project member roles, responsibilities, access rights, and privileges are defined by their account type.

99 3.2.1 Defining Account Types Granting Privileges to an Account Type Defining Page-Level and Field-Level Access Rights Renaming Account Types Deleting Account Types Understanding Specification View Privileges and Access Controls Privileges Access Control Understanding Requirement View Privileges and Access Controls Privileges Access Control Understanding Change Request View Privileges Understanding Report View Privileges Understanding Invisible Pages and Fields Understanding Read-Only Pages and Fields 3.3 Administering Secured Folder Access Levels An account type is a mechanism for assigning and managing access, security, and workflow in DevSpec projects. Every user is assigned an account type when they join a project and with that account type certain privileges, responsibilities and levels of access within the project. DevSpec team representation provides development organizations with maximum flexibility to manage work items in workflow, enforce security, and ensure accountability. Every user account is assigned one account type in each project. Users may be assigned different account types in different projects. To create an account type: 1 Select Project Settings > Account Type in the tree panel. 2 Click the New button. The New Account Type dialog box appears. 3 Input the name of the account type in the Account Type Name text box. 4 Optional: To copy privilege settings from a previously defined account type, select the Copy Account Type Setting From check box and select an account type in the dropdown list. 5 Click the OK button. The New Account Type dialog box closes and the name of the account type is displayed in the Account Types list Understanding Secured Folder Access Level Conflict Resolution Access type prioritization User account prioritization Defining Secured Work Item Access Levels

100 3.3.3 Defining Secured Folder Access Levels Updating Secured Folder Access Levels for All Users Chapter 4 Specification Administration 4.1 Understanding DevSpec Specifications In DevSpec, a specification represents a formal commitment to implement a feature or enhancement a particular product release. Every specification represents a set of requirements and provides the business with a framework for organizing and tracking the data and knowledge needed to implement those requirements. Specifications may correspond to a new feature, an enhancement of an existing feature, or even the detailed analysis of a defect that needs to be fixed. DevSpec specifications are fully customizable and may represent any number of properties: data such as time required, estimated cost, embedded images, attached detailed technical designs, behavior maps, diagrams with use cases, and any other data element that would help a user viewing the specification to understand it completely. As specifications progress through this lifecycle, development managers work with the product managers to define features, validate requirements, approve designs, and schedule their implementation. Specifications and Requirements In DevSpec, a requirement cannot be implemented until it is linked to a specification. Requirements roll up into specifications which, in turn, are managed according to custom review and approval processes. Specifications enable development organizations to manage and track groups of requirements together and to schedule those requirements for implementation in an integrated development project. Project members may link multiple requirements and knowledge items to specifications. DevTrack development issues and QA test issues may be linked to specifications. ServiceWise support incidents may be linked to specifications. Specification Tree Like requirements, DevSpec specifications are organized and managed in a hierarchical tree structure thespecification tree that that defines the framework for development, organizes product specifications in the workspace, implements security, enforces good development practices and accountability, and enables collaboration between distributed teams. Agile Development In projects using DevSuite blueprint agile development, the specification tree represents a backlog of features called thespecification backlog that organizes the specifications that are yet to be implemented in a development project. Specifications are implemented when they are assigned to aiterative a subproject.. An iteration subproject is a distinct area of work (as defined by a single specification) that needs to be completed within a set period of time. Every iterative subproject may be defined by a single specification. The specification defines the work required to deliver a feature within that iteration. DevSuite iterative development is an optional feature that must be enabled in each DevSpec project. For more information on configuring a DevSpec project to support iterative development see Implementation Integration Administration on page Understanding Specification Administration Enabling Specifications Defining Specification ID Prefixes Defining Specification Starting Numbers 4.2 Administering Specification Folders In DevSpec, specification administration is the process of defining structures for recording, managing, and tracking specifications in a project. All specifications are managed in the specification view of the DevSpec client. Project administrators are responsible for defining the specification object and customizing the client GUI to manage those objects Customizing the Add Specification Folder Function Page Administering the Edit Specification Folder Function Page

101 4.2.3 Administering Specification Folder System Pages Customizing the Spec Folder Applicable Owner System Page Customizing the Change Log System Page Customizing the Folder Order System Page Customizing the Access Control System Page Displaying Access Controls in Custom Pages 4.3 Administering Specifications In DevSpec, specification management is an optional feature that must be enabled in each DevSpec project. In the DevSpec client, specifications are managed in a hierarchical tree structure the specification tree that defines the framework for development, organizes product specifications in the workspace, implements security, enforces good development practices and accountability, and enables collaboration between distributed teams Administering the Add Specification Function Page Administering the Edit Specification Function Page Administering the Specification Detail Function Page Administering the Forward Specification Function Page Administering the Version Function Page Administering the Specification Template Function Page Administering the Group Change Specification Function Page Administering the Group Forward Specification Function Page Administering the Specification Change Function Page Administering the DevSpec User Function Page Chapter 5 Change Requests Administration 5.1 Understanding DevSpec Change Request Administration In DevSpec, Achange requestis a package of changes to requirements and specifications that may be managed and tracked together in the project. A change request represents a formal request to make adjustments to a system and enables change managers to review the effects of changes to specifications or requirements and track the status of the change request. Figure 5-1: Specification A change request may represent multiple specification changes and requirement changes and controls the progress of the corresponding specification or requirements. A change request is defined by its owner, workflow state, and other dynamic properties. Change requests are designed to manage and track the estimated cost and income of a set of changes. Change requests administration is the process of defining the structures that enable development teams to record, manage, and track change requests in the DevSuite client. Change request management structures include change request folders, change requests, and change request workflow.

102 5.2 Administering Change Request Folders In the DevSpec client, change requests are managed in a hierarchical tree structure the change request tree that organizes change requests in the workspace. The change request tree is a hierarchical structure composed of multiple folders and subfolders that organize requirements into distinct areas of work. Project members with the appropriate privileges may create any number of nested change request folders to any level of depth. Every area of development within the change request tree framework is represented by a change request folder. A change request folder is a discreet area of work that may represent a stakeholder, functional area, or any other category that is useful to a business Administering Change Request Folder Description Page System Fields 5.3 Administering Change Requests In the DevSpec client, project members may add or edit change request folders and subfolders using the Add Requirement Folder and Edit Requirement Folder windows. Both the Add Requirement Folder window and the Edit Requirement Folder window displayed in the DevSpec client is a manifestation of a customized Change Folder system page. Using controls in the DevSuite Admin client, project administrators may add two system fields and any number of custom fields to the Change Request Folder system page Administering Change Request System Pages Administering the Edit Change Request Function Page Administering the Change Request Detail Function Page Administering the Forward Change Request Function Page Administering the Applicable Product System Page Administering the Change Request History System Page 5.4 Administering Change Request Workflow System fields are system-defined folder property fields that have a designated use in the DevSpec project the data integrated is other TechExcel DevSpec features for change request management or reporting. Two system fields may be displayed in the Change Request Folder Description page: 1001 Folder Name Long (<=255) Text (Edit Box) 1002 Folder Description Multiple-line Edit Box Project administrators may make only limited customizations to system controls. The title of the corresponding data-entry control may be customized. The Folder Description field may be customized to support spell checking, time stamping, and HTML tags. To customize the Change Request Folder page: 1Select Change GUI > Change Request Folder > System Pages > Description Page. 2 Optional:To customize the title displayed in the DevSpec client, input text in the Page Display Name text box Enabling Change Request Workflow Options Creating Change Request Workflow States Editing Change Request States Deleting Change Request States Defining Change Request State Transitions Defining Change Request State Transition Rules

103 5.4.7 Defining Change Request State Applicable Owners Defining Default Owners by Change Request State Defining State-Based Read-Only Change Request Fields Defining State-Based Mandatory Change Request Fields Defining State-Based Invisible Change Request Fields Chapter 6 DevSpec GUI Gustomization 6.1 Understanding DevSpec GUI Customization DevSpec project administration is largely the process of defining structures for recording, managing, and tracking work items requirements, specifications, change requests in a project. Customized project management structures are manifested in the DevSpec client as views, panels, folders, and pages. A view is an interface that displays and organizes data in the client workspace. DevSpec supports three customizable views: the requirements view, the specifications view, and the change request view. Views enable project members to manage and track different types of data using structures that are specifically designed to manage that data. The building blocks of each view folders, pages, and controls may be customized to support custom business processes. The building blocks of client interface include: controls, folder pages, and GUI pages. Control:A control is a GUI element displayed in a folder page or custom page that enables the user to define, update, and track data. DevSpec supports system controls and custom controls. Controls are displayed in system pages and custom pages. System Page:A system page is a predefined form that enables project members to collect, manage, and track project data in a project. A system page displays a predefined set of system controls. Custom Page:A custom page is a form conceived, designed, and built by a project administrator that enables project members to collect, manage, and track project data. A custom page may display system controls and custom controls. Function Page:A function page is a compound page composed of multiple custom pages and system pages. In the DevSpec client, function pages are displayed as multiple-page forms that enable the user to perform a particular function such as adding or updating a folder or a requirement. 6.2 Administering System Pages In DevSpec, a system page is a predefined page that enables project members to perform a specific task such as collecting, managing, and tracking project data. Each system pages features one or more system controls. A system control is a systemdefined control that represents a predefined system field and features control-specific functionality. System fields represent core object properties such as workflow states and object statuses and the data tracked in these fields is frequently forms the foundation of TechExcel businesses rules. Like custom pages, system pages may be added to function pages to build the multiple-page forms that enable project members to manage requirements, specifications, and change requests in each view. 6.3 Administering Function Pages A function page is a compound page composed of multiple custom pages and system pages. In the DevSpec client, function pages are displayed as multiple-page forms that enable the user to perform a particular function such as adding or updating a folder or work item. The function page acts as a frame for displaying the custom and system pages that enable project team members to manage work items.project customization consists of creating custom pages and controls and adding those pages to function page so that they are displayed in the client.

104 Figure 6-1: Function Page Diagram 6.4 Administering Custom Pages In DevSpec, a custom page is a form conceived, designed, and built by a project administrator that enables project members to collect, manage, and track project data. Each custom page may display system controls and custom controls. Using custom pages, system controls, and custom controls, a business may create forms that are uniquely designed to manage and track data that is specific to their environment and business. Figure 6-2: Custom Page Like system pages, custom pages may be added to function pages to build the multiple-page forms that enable project members to manage requirements, specifications, and change requests in project views. Project administrators may add and remove system, custom, and multiple-selection controls to custom pages, customize the layout of controls in the page, and define their the tab order Adding Custom Pages Adding Controls to Custom Pages Removing Controls From Custom Pages Ordering Controls in Custom Pages 6.5 Administering System Fields and Controls A custom page is a form conceived, designed, and built by a project administrator that enables project members to collect, manage, and track project data. Project administrators may create custom pages for use in the requirements view, specification view, and change request view. To create a custom page: 1Right-click a Custom Pages folder and select the Add New Page command in the shortcut menu. Custom pages may be created for the requirements folder, requirements GUI, specification folder, specification GUI, and change request folder, and change request GUI

105 The custom page is displayed in the workspace. 2Input the title of the custom page in the Page Display Name text box. The display name defines the text that identifies the tabbed page in the client. By default, the custom page is given the title New Page. 3Add custom controls or system controls. 4Define the tab order of the controls displayed in the custom page Understanding Specification Folder System Fields Understanding Specification System Fields Understanding Requirement Folder System Fields Understanding Requirement System Fields Understanding Change Request Folder System Fields Understanding Change Request System Fields Understanding Document and File Attachment System Controls Document System Control (1105) File Attachment System Control (1121) 6.6 Administering Custom Fields and Controls To add a control to a custom page: 1Right-click in the custom page and select the Add Control command in the shortcut menu. The Add New Field manager appears. The Add New Field manager displays every custom controls and system controls that may be added to the custom page. 2 Optional: To filter controls by control type, select an option from the Field Type dropdown list. The Field Type dropdown list displays multiple control types including the dropdown list control type, short text box control type, and the field label control type. DevSpec enables administrators to define controls based on 17 different control types. 3 Optional: To define how the control is presented in the page, select an option from the Label Alignment dropdown list. The Label Alignment dropdown list displays three options: Right Aligned Left Aligned Center Aligned 4 Optional: To define control as read only in the page, select the Add It as Read Only check box. A read-only control is a control that is displayed, but cannot be edited. 5Click the OK button Understanding Control Types Customizing Check Box Controls Customizing Date-Time Controls Chapter 7 Event Administration 7.1 Understanding DevSpec Events Throughout the project planning process, project managers may schedule and manage team meetings as events. An event is a management task that facilitates communication and collaboration between project stakeholders. Typical events include brainstorming sessions, team meetings, design reviews, management reviews, presentations, and product demos. In DevSpec, events are the vehicle that drive the planning process and ensure the quality of the end product. Regular team meetings scheduled within DevSpec enable project managers ensure that all project team members are working together to meet project objectives. Every DevSpec event is based on an administrator-definedevent template. An event template is a blueprint for creating a specific type of event such as a meeting,

106 presentation, or demo that defines the business rules that determine how that event is managed in the project. Event administration, therefore, is the largely a matter of creating event templates, defining the rules that manage events based on that template, and determining when events based on that event template may be created in the project. 7.2 Administering DevSpec Event Templates An event template defines the business rules that are used to manage the events based on that template including the applicable owners, account type-based access controls, and workflow settings. Using controls in the Event Template page, project administrators may create and define multiple event templates. For each event template created in the Event Template page, the project administrator must define appropriate properties, access controls, an event group, and event workflow rules Defining Event Templates Defining Default Event Titles and Descriptions Defining Default Event Workflow States Defining Default Event Owners Defining Event Template Scope 7.3 Administering Event Workflow Each event template represents a specific type of event such as a meeting, presentation, or demo and defines who may own the event, who may attend the event, and how the event is managed in workflow. To add an event template: 1In the DevSpec Admin, navigate to Advanced Features->Event, Click the New button in the Event Template page of the Event subfolder. The Add a New Event Template dialog box appears. 2Define a unique, descriptive name for the event template in the Name text box control. The title of the event template is inherited by every event based on that template and is the default title for those event instances. 3Define a brief description of the event in the Description field. Event template descriptions enable project manager to describe the purpose and functionality of an event template. 4Click the OK button. The Add a New Event Template dialog box closes. The event template is displayed in the Events folder of the Event Templates tree control. To delete event templates: 1Select the Event Template page in the Admin Tree window. 2Select an event template in the Event Templates list. 3Click the Delete button in the Event Templates area. A confirmation dialog box appears. 4Click the Yes button. The event template disappears from the Event Templates tree control Defining Event States 7.4 Administering Event Management Privileges Every event is defined by a title and a description of the event. The title and description of events are tracked in two data-entry controls: the Title control and the Description control. Project administrators may define default event titles and event descriptions for each event template. Every event that is based on that event template inherits the predefined title and description. To define default event titles and descriptions: 1Select an event template in the Event Templates tree list control of the Event Templates page. 2Define the title of the event in the Title control. Every event based on the event template is automatically given the title defined in the event template.

107 3Define the description of the event in the Description control. Every event based on the event template automatically inherits the description defined in the event template. 4Click the OK button Defining Event Management Privileges Chapter 8 Implementation Integration Administration 8.1 Understanding DevSpec Iterative Development Management Administration Subprojects Applicable Products and Versions Baselines Specification Backlog Implementation Modules Implementation Linking Specification State Automation 8.2 Administering DevSuite Development Integration Optional DevSuite integration features include baselines, applicable product and versions, and specification backlog management Enabling Baseline Support Defining Applicable Products and Versions 8.3 Administering Implementation Linking and Time Management In DevSpec, a baseline is a snapshot of a group of work items (requirements and specifications) at a particular point in time enabling the development team to compare the baseline copies of work items with their current copies. A baseline may represent a grouping of requirements, specifications, or requirements and specifications based on the user-defined criteria. Each baseline captures key reference points for multiple work items including the title, status, owner, and description. Using controls in the baseline detail view, project team members may compare the a current requirement or specification with a baseline version of that work item To enable baseline management: 1Select Project Setting > Baseline in the tree panel. 2Select the Enable Baselines check box Enabling Implementation Link Time Management Tools Defining Implementation Link Options Defining Applicable Implementation Modules 8.4 Administering Specification Backlogs In DevSuite, the product tree identifies the products, product versions, and builds under development site and provides a common framework for organizing and managing the development of products, versions, and builds. Every requirements folder may be defined by one or more applicable products and versions. For more information see Customizing the Applicable Product and Version System Page on page 54. To use the product, version, and build structures, the project administrator must identify which products, versions, and builds in the product tree are applicable to their project. Only those release folders that have been defined as applicable may be utilized in the project. To select applicable products, versions, and builds: 1Select Product Settings > Applicable Product/Version in the tree panel. 2Click the Select button. The Select Product dialog box appears. The Product Tree displays the product categories, products, versions, and builds that have been defined in site. 3Select all applicable products, versions, and builds. The products, versions, and builds selected in the product tree may define DevTrack subproject structures. 4Click the OK button.

108 8.4.1 Enabling Specification Backlog Management Defining Spec Management Options for Child Development Projects Defining State-Based Specification Assignment Rules Defining State-Based Pending Specification Linking Rules Defining Assigned Implementation Link Spec State Automation Defining Closed Link Specification State Automation Administering the Implementation Module Control Chapter 9 Time and Cost Analysis Administration 9.1 Understanding DevSpec Time, Cost, and Income Estimates DevSpec enables development organizations to track the estimated time, cost, and expected income of development efforts. Using tools in the DevSpec client, project team members may log estimations of the time required, the cost per unit, and the total cost of development efforts. Figure 9-1: Time and Cost Tracking in the DevSpec Smart Client All DevSpec time, cost, and income analysis is based on estimates entered in the DevSpec smart client. Entries are tracked in system-defined time estimation controls which may be added system or custom pages. The time and cost estimates defined and tracked in DevSpec mirror the actual time and costs of development efforts tracked in DevTrack development projects. The time and cost of development tasks may be calculated on a requirement-by-requirement basis or specification-by-specification basis. Requirements-Based Time and Cost Estimates:Time and cost estimates that are logged for each requirement in the DevSuite smart client. Time and cost estimates roll up into specifications. Specifications-Based Time and Cost Estimates:Time and cost estimates that are logged for each specification in the DevSuite smart client. All time and cost analysis tools and structures are defined by a project administrator in the DevSuite Admin client. Both DevSpec time estimates and DevTrack time and cost entries are based on administrator-definedtime categories. In DevSpec, time categories enable the development organization to measure the estimated time, cost, and 9.2 Administering Project, Time, Cost, and Income Estimation Settings Using controls in the Time Settings page, project administrators may enable time, cost, and income estimation, choose time estimation tracking preferences, and identify the time categories that are applicable to the project. Figure 9-2: Time Settings Page in the Advanced Setting Folder Enabling Time and Cost Analysis

109 9.2.2 Defining Time and Cost Analysis Preferences Defining Time/Cost Tracking Defining Time/Income Tracking Selecting Applicable Time Categories Updating Time Categories 9.3 Administrating Time, Cost, and Income Estimation Controls In DevSpec, time, cost, and income analysis are optional features that must be enabled and configured on a project-by-project basis. To enable time and cost analysis: 1Select Advanced Features > Time and Price Analysis. 2Select the Support Time/Cost check box Administering Requirement Estimation Controls Administering Specification Estimation Controls DevTrack Projects Administration Chapter 1 DevTrack Concepts 1.1 Understanding TechExcel DevTrack and DevSuite TechExcel DevSuite is a family of integrated application lifecycle management (ALM)tools that place knowledge management from ideas, to formal specifications, to competitive information to issue resolution and customer insight at the core of anyproduct development initiative. The DevSuite knowledge-centric strategy enables improve communication, keep uptodate on changes, and reduce the development cycles so that the business may deliver the right products for the right markets in the shortest possible time. Figure 1-1: DevSuite Knowledge-Centric Development DevSuite places knowledge management at the core of all development processes. TechExcel KnowledgeWise provides for the easy and efficient collection and organization of informal ideas, gathered from a wide variety of sources, that area shared across multiple DevSpec, DevTrack, and DevTest projects. KnowledgeWise projects provide controlled access to documents, improve communication and coordination between distributed development teams, and facilitate the management and sharing of information between development teams and project stakeholders. TechExcel DevSuite leverages intellectual assets with KnowledgeWise, communicating a clear product vision and tactical execution strategy by linking ideas and customer feedback, specifications, requirements, designs, prototypes, and other documents to specific areas of work.

110 1.1.1 Understanding DevSuite ALM Solutions Understanding TechExcel Project Hierarchy 1.2 Understanding DevSuite Administration TechExcel DevSuite features five ALM solutions that operate in an n-tier architecture: TechExcel KnowledgeWise, TechExcel DevTrack, TechExcel DevPlan, TechExcel DevSpec, and TechExcel DevTest. All DevSuite products share the same core architecture the DevSuite Database Server, DevSuite Application Server, DevSuite Document Server, and DevSuite Web Services and are fully integrated enabling every branch of the development organization to communicate and work together. KnowledgeWise TechExcel DevSuite leverages intellectual assets with KnowledgeWise, communicating a clear product vision and tactical execution strategy by linking ideas and customer feedback,specifications, requirements, designs, prototypes, and other documents to specific areas of work during a development project.documents are shared with all resources involved in the executionof the project allowing for an uncompromised vision to direct the path of any development project. DevPlan TechExcel DevPlan manages the transformation of concepts into formal strategic plans. DevPlan offers an intuitive planninghierarchy to formalize scope an optimize resource usage,team-based planning and calendaring capabilities. These features enable complete control over all product development projects from design planning to implementation and enables increased team efficiency and collaboration. DevSpec TechExcel DevSpec is an integrated requirements management solution that is specifically designed to provide visibility,traceability and validation of your product or project requirements.devspec provides a frame work to create new requirements, specifications and features that can be linked to development and testing implementation projects. DevTrack TechExcel DevTrack enables development teams to manage every aspect of the development process including issue management, team management, and communications management. DevTest TechExcel DevTest is a test management solution that enables test organizations to manage every stage of testing life cycle from test case design, to test execution, to test analysis. DevTest provides testing groups with the tools they need work more effectively and efficiently, hold down costs, and to deliver higher quality products. While each element is valuable even when functioning independently, the DevSuite architecture is founded upon the assumption of future scaling and is capable of advanced inter-module integration. Whether used as separate components or as an incorporated set of applications, the DevSuite solutions are ideal for companies at any stage in their product development Understanding DevSuite Site (System-Level) Administration Understanding Project Administration 1.3 Understanding DevSuite Sample Projects and Templates At the core of every DevSuite implementation adevsuite site is one or more KnowledgeWise knowledge management projects that organize, manage, and track the knowledge collected in multiple DevSpec, DevTrack, and DevTest projects. All projects in a DevSuite site are organized into a hierarchical structure that defines the relationships between the projects in a DevSuite site. Every DevSpec or DevTrack project is the child of a parent KnowledgeWise knowledge management project and relies on that project to manage project intelligence.

111 Figure 1-2: DevSuite Project Hierarchy KnowledgeWise enables development organizations to build a knowledge base of shared knowledge in many different media. All knowledge items may be linked with different areas of work so that internal teams and external customers can search the knowledge base for self-service content based on account type-based privileges and access controls. KnowledgeWise projects may be accessed by three methods: (1) the KnowledgeWise Web client, (2) the knowledge view of a child DevSpec project; (3) the knowledge view of a child DevTrack project Understanding Sample Projects Understanding Project Templates Understanding Solution Templates Solution Guide Report Chapter 2 Project Administration 2.1 Understanding DevTrack Project Administration In DevSuite, administrative tasks are managed at two levels: the system-level and the project-level. This book describes project-level administrative tasks that apply to TechExcel DevTrack work projects. In DevSuite, the configuration and customization of work projects is the responsibility of a project administrator. Project administrative tasks include the creation and definition of projects, the definition of project settings and workflow, and team management structures Understanding Projects 2.2 Understanding the DevSuite Admin Workspace In DevSuite, a project is a tool for storing, organizing, and managing incident, event, employee, asset, knowledge, and project team data. Every DevSuite implementation called a DevSuite site may consist of multiple types of work projects including DevTrack development projects, DevSpec requirements management projects, KnowledgeWise knowledge management projects, and DevTest QA management projects. A work project is a tool for storing and managing work item and event data. The work items managed and tracked in a project are project-specific: development issues in DevTrack, test templates and test tasks in DevTest, and specifications, requirements, and change requests in DevTrack. Every work project represents a distinct area of work and is defined by unique team structures (account types, team groups, and group folders) and workflow rules. In DevSuite, the work projects in a DevSuite site are organized into a hierarchical structure that determines the relationships between KnowledgeWise projects, DevSpec projects, and DevTrack projects.

112 Figure 2-1: DevSuite Project Hierarchy Understanding Menu Bar Commands Understanding the Tool Bar Commands Logging into DevSuite Admin Opening DevTrack Projects Closing DevTrack Projects Understanding Keyboard Shortcuts 2.3 Administering DevTrack Projects In DevSuite, all system- and project-level administrative tasks are performed in the DevSuite Admin client. When the System Settings project is opened, the DevSuite Admin client displays tools for configuring and administering an entire DevSuite site. Figure 2-2: DevSuite Admin Client The DevSuite Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-level features. The DevSuite Admin client is organized into four sections: Menu Bar:The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help menus. Tool Bar:The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. Tree Panel:The Tree Panel organizes administration tools into a hierarchical structure consisting of folders and folders. Page Panel:The Page Panel displays form-based administrative tools that enable the administrator to configure and maintain system-level settings Creating DevTrack Projects Backing Up DevTrack Projects

113 2.3.3 Restoring DevTrack Projects Creating Projects Based from Backed Up Projects Copying DevTrack Project Settings 2.4 Overview Settings The Overview page contains the most essential settings for the DevTrack project. The Overview page is located under the Project Settings folder. Project Name: Name of the project, this can be changed later if needed. Project Identifier:This identifier is used to uniquely identify the project. DevTrack provides a set of features to allow users to view the issue directly by using a specific format of url with the project identifier included. The format of the URL is as below: identifer>&issue=<issue id> For example if the project identifier was "techexcel" and you wanted to see issue #10, the link would be similar to: 2. users will be able to access individual DevTrack issues in a read-only format using the following URL: Viewtask?{ProjectIdentifier}&{IssueID} Project Type: The project type is used to distinguish DevTrack, DevSpec and KnowledgeWise projects. Once a project has been created, the associated project type will be defined and cannot be altered. For DevTrack projects, the project type is Development Management. Sample Project Option:You can set a DevTrack project to be either a sample project or a live project. A sample project is mainly for evaluation purposes and only sample users would be allowed to be added to a sample project (since sample users take up no licenses) There is also a limit on the number of issues you can create in the sample project. Use the "Change" button to switch this option. Project Description: This section is used for project administrators to give a brief description of what the project is for. A good practice is to note which features are enabled so other administrators may be able to configure and understand the project as well. Issue Prefix: Administrators are able to add a prefix to all issues created for the project. The prefix can only be 4 characters long. Active Project: This setting is used to disable the project. Unchecking the box makes the project inactive. Prior to making it inactive, it is recommended to backup the project first. Once a project has been deactivated, administrators may delete it from the system. Use the "Change" button to modify this setting. Name display format: Administrators may define whether names appear as first name last name or vice versa throughout the entire project. This is a project-level setting. Time format: In this section, administrators may define the way dates and time appear. By default, the date format is: MM/DD/YY and the time format is: hh/mm/ss. In addtion, the time zone can also be set. Please note that this setting can only be changed and used if system administrators define the date/time option to be at the project level rather than at the system level. Workflow option: This setting allows administrators to quickly define whether the workflow will be transition based or state based. Use the ellipsis button to modify the setting. For additional information, please see the wiki help for understanding workflows.

114 2.5 Project Login Tip The project tip page allows project administrators to define a tip to display when project members log into the project. It appears as a popup and the administrator is able to change the title of the dialogue title as well as the contents of the tip window. The project Login Tip is located under the Project Settings folder. To enable project tip, select the "Enable Project Tip" check box. For your convenience, project tip is enabled by default with pre-populated content. To change the tip content, use the Edit button to bring up the HTML Editor. We also provide a setting to enable allowing users to skip the project tip screen. This is how the tip window looks like in the web client: And you can use the "Reset user project tip preferences" button in the Admin Client to force all users to see the project tip shall you make changes or annoucements in the tip section. 2.6 Web Setup The Web Setup page contains the essential settings for Web Client configuration. The Web Setup page is located under the Project Settings folder. Project RuntimeKey: With the project runtime key, users can log onto this particular project using a project-specific login window. Plus the runtime key provides an extra layer of security to your web client. The runtime key can contain both numbers and characters. To access a project-specific login, use the following URL: Web Login Title for the project: When accessing the project-specific login (with URL mentioned above), you can define the login title you want the project

115 members to see. Web Welcome Message:When accessing the project-specific login (with URL mentioned above), you can define the welcome message you want the project members to see. URL for logo: You can define the URL you want users to be taken to when the TechExcel DevTrack logo is clicked (logo highlighted in the screenshot below): Max Number of issues per Page: At the project level, administrators can define the maximum number of issues displayed per page in the web client. Note that there is another setting at the user level for users to define how many issues they want to see per page. The user-defined number has to be within the range of the project-level number. Issue list: Define the max number of issues displayed per page in the Issue List pane. Report: Define the max number of issues displayed per page in Reports tab. Note: It's important to define a reasonable number for this setting especially in projects that contains a lot of issues/tasks. Loading all issues in one page is very likely to slow down the performance. Auto refresh when idle: Issue list can be auto refreshed according to the timer you define to ensure the most updated info can be displayed. Note that high refresh rate may slow down the web performance though. We recommend that you set the timer no less than 300 seconds. Enable Quick Search Mode: You can enable the quick search mode in the web client in addition to the detailed search feature. Once quick search is enabled, users in the web client will see an extra button (highlighted in the screenshot below) to perform easy and quick searches. Enable Readonly URL for Task: By turning on the read-only URL for DevTrack tasks, users will be able to access individual DevTrack issues in a read-only format using the following URL: 2.7 KnowledgeWise/ DevSpec Integration DevTrack is a core module within DevSuite and it can be integrated with other modules such as KnowledgeWise and DevSpec. KnowledgeWise is a Wiki-based knowledge management tool. The knowledge-centric concept enforces the reuse of the knowledge resource. By turning on KnowledgeWise integration with DevTrack, you can essentially have multiple DevTrack projects share the same repository for knowledge access and management. DevSpec is a requirement management tool that can also be integrated with DevTrack. By turning on the integration between the two, product managers can manage product requirements and specifications in DevSpec and then directly assign requirement and specification items to DevTrack to create linked development tasks. The integration can be turned on at the project level, so you can have some standalone DevTrack projects and some integrated DevTrack projects within the same system. This provides administrators greater flexibilityin terms of choosing and combining what's needed for the team. To administer KnowledgeWise and DevSpec integration, go to Project Settings >KnowledgeWise/DevSpec Integration page. Use the change button to enable or disable KnowledgeWise/DevSpec integration. A few things to note here: 1. Changing the linked DevSpec project will remove all links previously established and leads issues to data integrity. Please contact TechExcel Support if you think the change is a must. On the other hand, it is fairly safe to turn on the integration if it hasn't been integrated with DevSped projects yet. 2. KnowledgeWise integration must be enabled in order to use DevSpec integration.

116 Chapter 3 Team Administration 3.1 Understanding Team Administration The DevTrack clients provide project team members withcontrolledaccess to all development work items and activities, facilitate communication and workflow, and improve the productivity and effectiveness of the organization. All DevTrack development activities are controlled by account typed-based privileges, workflow rules, and access controls. The ability of a DevTrack user account to access projects, views, folders, and pages depends on the role (account type) assigned to that user in the project. The account type concept provides administrators with the flexibility to customize project workflow and security to support their unique business requirements. DevTrack team representation structures enable development organizations to define sophisticated and flexible workflow rules for managing project data and security. Project-level team administration is the process of defining team management structures (account types, team groups, and group folders), adding user accounts to the project, and assigning appropriate role and responsibilities to each project member. An account type is a set of access rights, privileges, and responsibilities that define the role that a user account plays in a project. Every user account is assigned one account type in each project. A team group is a collection of project team members that do not necessarily share the same account type but who share common responsibilities in the project. A group folder is a mechanism for managing the distribution of development issues in a project. 3.2 Administering Account Types, Access Controls, and Privileges In DevTrack, privileges and access rights are not granted to user accounts directly, but assigned to administrator-definedaccount types. An account type defines the role assigned to a user account in a project and determines the projects, views, data, and reports that are available to a project team team member through the DevTrack clients. Users are assigned an account type when they join a project and assume the rights and privileges granted to that account type when a user s responsibility changes, he or she may be assigned a different account type. In each project, the project administrator is responsible for creating all account types, granting privileges and access rights to those account types, and assigning these account types to each project members based on the role and responsibilities that user performs in the project Defining Account Types Enabling Advanced Access Control Support Enabling the New Issue Deletion Option Administering Issue Management Privileges Administering Invisible Pages and Fields (Standard Access Controls) Administering Read-Only Pages and Fields

117 3.2.7 Administering On Submission Access Controls Administering On Existing Issues Access Controls Administering DevTrack Knowledge Management Privileges Administering Report Access Controls Windows Client Reporting Web Client Reporting Administering Subproject Management Privileges 3.3 Administering Project Members DevTrack team representation provides development organizations with maximum flexibility to manage work items in workflow, enforce security, and ensure accountability. All account types are project-specific and defined by the project administrator. In DevTrack, organizations are free to define the account types that best represent their business processes. For example, a typical development project might feature five different account types: the Manager account type, the System Architect account type, the Programmer account type, the Tech Support account type, and the QA account type. Figure 3-1: Typical DevTrack Project Account Types Every licensed DevTrack user may be a member of multiple projects and may be assigned a different account type in each project. To create an account type: 1Select Project Settings > Account Types. 2Click the New button in the Account Types page. The New Account Type dialog box appears. 3Enter a name in the Account Type Name text box. 4 Optional: To copy standard access privilege settings from another account type:

118 Select the Copy Account Type Setting From check box. Select an account type from the dropdown list. 5Click the OK button. To rename an account type: 1Select Project Settings > Account Type. 2Click the Rename button. The Rename Account Type dialog box appears. 3Enter a name in the Name field. 4Click the OK button. To delete an account type: 1Select Project Settings > Account Type. 2Select an account type in the Account Type list. 3Click the Delete button. The Delete Account Type warning appears Adding User Accounts to Projects Editing Project Member Account Types Removing User Accounts from Projects Viewing Project Member Information 3.4 Administering Team Groups In DevTrack, access controls determine whether a project team member may view or edit a page or data-entry control in the client. DevTrack pages and fields (data-entry controls) may be defined as read-only or invisible to project members belonging to certain account types. DevTrack supports two types of account type-based access controls: standard access controls and advanced access controls: Standard Access Controls:Standard access controls enable the project administrator to define account type-based access rights for pages and fields. Advanced Access Controls:Advanced access controls enable the project administrator to grant distinct access rights to project team members based on the status of a development issue. Account types may be granted different access rights depending the whether they submit an issue or update an existing issue.

119 Advanced Access Control management is a DevTrack Enterprise Edition feature. DevTrack Enterprise Edition is an optional upgrade that includes all of the features in the Standard Edition of DevTrack and adds a number of enterprise features including event management and the Beta Customer Portal. To enable advanced access control support: 1Select Project Settings > Account Types page in the tree panel. 2Click the Setup button. The Page and Field Access Control dialog box appears. 3Select the Advanced Access Control option button. 4Click the OK button. The Page and Field Access Control dialog box closes. TheOn SubmissionandOn Existing Issuetabs are displayed in the Account Type page Defining Team Groups Adding and Removing Project Members to Team Groups 3.5 Administering Group Folders DevTrack privileges or workflow rules may restrict the ability of project team members to delete development issues based on the user s account type or the issue s workflow state. Project administrators may use the Allow Users to Delete Issues if They Have Not Been Updated controls to enable project members to delete development issues that they have submitted to a project, if those issues have not been updated subsequent to their initial submission. To enable new issue deletion: 1Select Project Settings > Account Types page in the tree panel. 2Select the "Allow submitters to delete issuesif they havenot yet been updated" check box Defining Group Folders Chapter 4 Development Issue Administration 4.1 Administering General Settings for Main View GUI Design On the General Settings page under Main View GUI Design, project administrators can define the following settings: 1. Whether to show attachment icon in issue list or not: Show event file attachment Show note file attachment 2.Whether to turn on screen capture at issue submission or at the Notes page in the Windows Client or the web client application:

120 Enable screen capture at issue submission via windows client Enable screen capture from note pages via windows client Enable screen capture at issue submission via web client Enable screen capture from note pages via web client For example, if you want users to utlize the screen capture tool only in the new issue submission window in the web client, select the 3rd check box. 3. Whether to turn on HTML editor for the description field or not: Project administrators can decide whether to use plain text box or the HTML editor for the description field. Use the ellipsis button to switch the settings. 4.Whether or not to allow previous selections if they are not applicable to current state master-detail relationship: Enable the check box if project administrators do not want to allow previous selections to be available if they are not applicable to the current state master-detail relationship. This would mainly wipe out the selection as they are no longer applicable. 5.Time field display format selections: Project administrators can select from one of the three kinds of time field display formats that applys to the project: Hours, Days or Days:Hours. 6.Field choice sort option: Administrators can use this feature to control whether dropdowns and definable select fields in a project are sorted alphabetically or based on a pre-defined order. These options apply to both the field controls and the search window. With automatic sorting, for example, when a user adds a new value to a definable select field via the web interface, the new value will be placed in the list and sorted alphabetically. This simplifies the work for administrators since they need not trouble themselves with constantly resetting field option orders. Project administrators should only select the "Sort field choices according to admin defined order" box if the order defined in each of the field control wishes to be used. 4.2 Administering the Issue List Panel The issue list panel provides project members with high-level information about many issues simultaneously. Project members may use controls in the DevTrack clients to filter and sort the issues displayed in the issue list panel by issue properties. Therefore, it is important for project administrators to define the default columns(such as type, urgency, current owner and etc) in the list view to reflect the importance of certain issue properties. Under themain View GUI Design folder > Issue Listpgae, project administrators may determine which issue properties are displayed by default in the issue list panel of DevTrack.Project administrators may also edit the column headers for each data field, and set the default order for the columns in the issue list panel. The graphic display for the list view can also be defined on this page Adding or Removing List Columns Editing List Column Headers Changing Column Order Defining List Indicator Icons and Text Colors Displaying Note and Event Attachment Icons 4.3 Administering the Issue Detail Panel

121 Project administrators may use the Issue List manager to define which list columns are displayed in the issue list panel of the DevTrack clients. Project administrators may only define thedefaultsettings for each project. Individual project members may customize the issue list panel in their clients to display or hide issue properties. To add or remove list columns: 1Select the Issue List page in the Main View GUI Design folder of the Admin Tree window. 2Add or remove columns by moving them between the Available Data Fields list and the Issue List View Columns panels.. To add columns to the Issue list, highlight options in the Data Fields list and click the Right arrow to move them to the Issue List View Columns list. To add columns to the Issue list highlight options in the Issue List View Columns list and click the Left arrow to move them to the Data Fields list. 3 Use the Reset button to set the Issue list view back to the default view. The default column includes the following fields in the order below: Issue ID Title Priority Progress Status Current Owner Date Assigned Defining Issue Detail Panel Page Order Customizing the Issue Detail Panel in the Windows Client Customizing the Issue Detail Page of the Web Client Multiple page display Single page display 4.4 Administering Function Pages Project administrators may use the Issue List page to edit the title of list column headers displayed in the issue list panel of the DevTrack client. Project administrators may change the column headers for the Issue ID, Progress Status, Current Owner and other columns in the issue list panel. Customizations made to the field are manifested in other pages, including the Current Status page, the New page, and the Search manager. To edit list column headers: 1Select Main View GUI Design > Issue List in the Tree window. 2Move the field from the Data Fields list to the Issue List View Column list. 3Highlight the field. 4Edit the header label in the Edit Column Header textbox Administering the New Issue Window system controls Defining Manager Options in the Windows Client Detailed action display Simplified action display Administering the Forward Issue Window Administering the Close Issue Window 4.5 Administering System Pages Project administrators may use the Issue List page to change the order of columns displayed in the issue list panel of the DevTrack client. To change issue list panel column order: 1Select Main View GUI Design > Issue List in the Tree window.

122 2Select a field in the Issue List View Columns List. 3Change the placement of the field in the issue list panel. Press the Up button to move the field to the left in the issue list panel. Press the Down button to move the field to the right in the issue list panel Administering the Issue Description System Page Administering the Issue Detail System Page Administering the Current Status System Page Administering the Notes System Page Administering the Link System Page 4.6 Administering Custom Pages Project administrators may use the List View Graphic Indicator Setting manager to customize the appearance of issues in the issue list panel based on issue properties. Project administrators may customize the following features in the issue list panel: Customize the font weight of text of issues in the Issue list based on issue property values. Customize the color of text of the issue in the Issue list based on issue property values.. Customize the icons that identify issue state based on issue property values. The List View Graphic Indicator Setting manager enables administrators to define the appearance of the issue displayed in the issue list panel. Figure 4-2: Graphical Indicator Manager Project administrators may choose to display a list indicator icon in the issue list panel to indicate the current status of issues based on a single issue property. In the List View Graphic Indicator manager administrators may associate a icon with the property values of 11 system fields: Type Priority Component Version Platform Reason Current Owner Progress Status Target Release Submitted By Assigned By If the administrator associates an icon for each Priority field value (for example, Urgent, High, Medium, Low), issues in the issue list panel are identified by the appropriate icon. Project administrators may also use colored and boldface text to identify specific issue property values. Note:Indicator icons may be defined for one and only one issue property at a time. Indicator icons (and indicator text) identifying the value assigned to an issue based on a single issue property. Defining indicator icons for other issue properties immediately deletes all settings defined for the previous issue property. To define Issue List issue icons: 1Select the Issue List in the Main View GUI folder of the Admin Tree window. The Issue List manage appears. 2Select the List View Graphic Display Settings button. The List View Graphic Indicator Setting manager appears.

123 3Select an option from the Indicator Field Selection dropdown list. The Field Selection dropdown list displays multiple issue properties. The options displayed in the Available Choices list depend on the issue property option selected in the Field Selection dropdown list. Note:List indicators may be defined for one and only one issue property at a time. Each indicator color is associated with the values of a single issue property. 4Select a field option in the Available Choices list. The Available Choices list displays the options available for the selected issue property as well as multiple system-defined objects. Project administrators may not customize the icon displayed for system-defined objects. 5Click the Select Icon button. The Select an Icon dialog box appears. 6Choose an icon option from the Icon Field area. 7Click the OK button. The Select an Icon dialog box closes. The icon appears next to the option selected in the Available Options list. 8Click the OK button. To change the color of issue records: 1Select the Issue List in the Main View GUI folder of the Admin Tree window. The Issue List manage appears. 2Select the List View Graphic Display Settings button. The List View Graphic Indicator Setting manager appears. 3Select an option from the Indicator Field Selection dropdown list. The Field Selection dropdown list displays multiple issue properties. The options displayed in the Available Choices list depend on the issue property option selected in the Field Selection dropdown list. Note:List indicators may be defined for one and only one issue property at a time. Each indicator color is associated with the values of a single issue property. 4Select a field option in the Available Choices list. The Available Choices list displays the options available for the selected issue property as well as multiple system-defined objects. Project administrators may not customize the icon displayed for system-defined objects. 5To set the issue in boldface type select the Text Bolded check box. 6To define the color of issue text select an option from the Text Color dropdown list. 7Click the OK button Creating Custom Pages 4.7 Administering Page Design Project administrator may enable project members to indicate in the issue list panel whether there is an attachment to a DevTrack Issue. The General Settings page of the Main View GUI Design contains two controls: The Show Event File Attachment control enables project members to see if there is an attachment to a child event. The Show Note File Attachment control enables project members to see if there is an attachment to an issue note. Project members must add the Attachment property to the columns displayed in the issue list panel. Once the Attachment property is added, the Attachment icon is displayed in the issue list panel for all applicable issues Adding Controls to Custom Pages Ordering Controls in Custom Pages

124 4.7.3 Removing Controls From Custom Pages Chapter 5 Methodology Support Administration 5.1 Administering Methodology Settings DevSuite supports both Agile and none Agile processes at the space level. In other words, in one DevTrack project you can have some Dev Spaces utilize the Agile method, while some use the none Agile approach. Under Methdology Support >Methodology Settings page, we allow administrators to define/rename the methodology terms in both Agile and non Agile settings to better reflect the development needs. Administrators can also decide whether to turn on features related to Dev Spaces, releases and iterations or not on this page Settings for Agile Development Spaces Settings for Non Agile Development Spaces Other Methodology-related Settings 5.2 Administering Iterative Sub Project Templates In the "For agile development space" section, you have the option of relabeling "iteration" to other terms to reflect your actual methodology. Iterations are short development time frames that typically last from one to four weeks. For example, in SCRUM, you might want to call an iteration a sprint instead. Use the Ellipsis button to update the naming. In an Agile development space, you can choose whether to limit the task assignments to iteration folders only. Choose "Task can only be assigned to iteration and its children folder" if you want to turn on this limitation. Use "Task can be assigned to any folder within a Dev space" if you want to allow tasks to reside in any folder level, such as a release, a team or a regular folder. 5.3 Administering Backlog Support In the "For none agile development space" section, you can choose whether to turn on developmenet iterations or not. Again iterations are short development time frames that typically last from one to four weeks. Without enabling iterations, you'll be using the regular folders to manage the development release. In None Agile development, the development time frames are usually called "Milestones". You can use the Ellipsis button to relabel the naming if needed Defect Backlog V.S. Release Backlog Using Backlogs Without DevSpec Implementation Link Time Management 5.4 Administering Implementation Module and Task Assignment Settings The following milestone/iteration cycle related settings can also be found on this page: Support multiple teams under a release:turning on multiple teams support allows product managers to create an extra "team" layer under a release to manage the development work using the team concept. Without turning this on, only iteration folders and regular folders can be created under a release. Use the Ellipsis button to relabel team as a differnet term. Disable work assignment for past iteration subproject: Turn on "Disable work assignment for past iteration subproject" if you wish to stop the task assignment to iteration folders that are due. This is useful to prevent tasks being assigned to iterations that is not worked on anymore or will soon not be worked on. Enter the number of days after the subproject end date to mark as an iteration as a past one. For example, if you enter 2 days in the edit box and the subproject end date is April 20th, then users will no longer be able to assign tasks to the iteration starting on April 22nd. Support predefined Iteration Development Duration:An iteraton is a short development time frame that usually lasts for one to four weeks. There are usually multiple iterations in one release in order to deliver a working product and the duration of each iteration folder should by theory be the same, so that product managers would have a better understanding and utilization of the resource in the repeated time frame. Use the predefined iteration development duration feature to specify the default duration of newly created iterations. This offers ease and convenience to product managers, preventing them from having to manually set the

125 duration each time they create an iteration folder. Chapter 6 Development Issue Workflow Administrati 6.1 Administering Development Issue Workflow A workflow is a business process in which all activities are organized into repeatable patterns of work. DevTrack issue workflow is conceived as a series of issueworkflow statesthat are connected bytransitions. Each workflow state represents a distinct stage in the issue life cycle. A transition represents a passage between two workflow states. A workflow is a business process in which all activities are organized into repeatable patterns of work. These patterns calledworkflow rules facilitate the efficient processing of work items by identifying which tasks are applicable to each work item at every point in the development life cycle. Each issue must go through a series of stages (workflow states) from its initial submission to its closure DevTrack issue workflow is conceived as a series of issueworkflow statesthat are connected bytransitions. Each workflow state represents a distinct stage in the issue life cycle. A transition represents a passage between two workflow states.in DevTrack, workflow is conceived as a series of issue workflow states that are connected by transitions. Each workflow state represents a distinct stage in the issue life cycle. A transition represents a passage between two workflow states. States:Issue workflow states represent the various the stages that an issue may go through during the development life cycle. Each issue workflow state has an open status or a closed status. Transitions:Transitions define the path that issues may take in project workflow. Issues may be forwarded from one issue workflow state to another issue workflow state only if a transition exists between those two workflow states. Incident workflow rules define the tasks that are required to manage issues in a DevTrack project, identify the project members that perform those tasks, and determine which tools are displayed in the DevTrack client. In DevTrack, project workflow may be based on one of two different workflow models: state-based workflow and transition-based workflow. The tasks required to update and forward issues differ in each model: In the state-based workflow model, issues progress from workflow state to workflow state based on explicit changes to the issue workflow state property of development issues by project members. All workflow rules are state-dependent. In the transition-based workflow model, issues progress from workflow state to workflow state based on actions performed by project members. Workflow rules may be state-dependent or transition-dependent. In DevTrack, workflow rules may bestate-dependentortransition-dependent. State-dependent workflow rules are defined on a state-by-state basis and control the changes that may be made to an issue in each workflow state. Transition-dependent workflow rules are defined on a transition-by-transition basis and control the changes that may be made to an issue in each transition. Transition-based workflow supportsbothtransition-dependent and state-dependent workflow rules. Transition-based workflow provides project administrators much greater flexibility and control when defining workflow rules in a project. Transition-based workflow rules may be both state-dependent and transition-dependent. Transition-based workflow supports multiple workflow (subworkflows) by which DevTrack workflow is integrated with subprojects. DevTrack transition-based workflow administration is the process of enabling support for state-dependent and transition-dependent workflow, defining issue workflow states and transitions and the rules that govern each state and transition. 6.2 Configuring Project Workflow Using controls in the Workflow Options page, project administrators may enable transition-based workflow and support for state-dependent and transitiondependent workflow rules.

126 Figure 5-1: Transition-Based Workflow Options Page Transition-based workflow provides administrators much greater control and flexibility than state-based workflow and each workflow option enabled both adds to the flexibility of the workflow model and complexity of defining workflow rules in that project. In transition-based workflow, project administrators may enable multiple project workflow, state-dependent workflow rules, transition-dependent workflow rules, transition-driven parent-child relationships between selection controls, and either state-dependent or transition-dependent issue creation triggers. In state-based workflow, project administrators may enable state-dependent workflow rules and state-dependent issue creation triggers. In DevTrack, transition-based workflow supports bothstate-dependentandtransition-dependentworkflow rules:. State-Dependent Rules:State-dependent workflow rules are based on the current workflow state of issues. Administrators may define rules that define applicable owners, mandatory fields, read-only fields, and invisible fields based on the workflow state of DevTrack issues. For more information see Administering Issue Workflow States. Transition-Dependent Rules:Transition-dependent workflow rules are based on the transitions between workflow states. Administrators may define rules that define mandatory fields, read-only fields, invisible fields, and Who Can Perform rules based on the transitions between two workflow states. For more information see Administering Transitions Enabling Transition-Based Workflow and Transition-Dependent Rules Enabling State-Based Workflow and Workflow Rules Enabling Transition Dependent Access Controls 6.3 Administering Issue Workflow States Transition-based workflow provides administrators much greater control and flexibility than state-based workflow and each workflow option enabled both adds to the flexibility of the workflow model and complexity of defining workflow rules in that project. In transition-based workflow, project members may submit, edit, forward, and close development issues by performing actions in the client. An action is a task such as creating, editing, or forwarding an issue that represents a transition between two workflow states or between a workflow state and itself. In transition-based workflow, multiple transitions may exist between each state, a transition may exist between a workflow state an itself, and each transition is explicitly named and represented by an action button in the client. Figure 5-2: Transition-Based Workflow The Workflow Type control displays two options: State-based Workflow option and the Transition-based Workflow option. If the Transition-based option is selected, the Workflow Options page displays the transition-based workflow options that the administrator may enable and define in the project. Transition-based workflow supports the both state-dependent workflow rules and transition-dependent workflow rules: Multiple Workflow:Multiple project workflow (subworkflow) enables administrators to define subworkflows within the larger master workflow. Each subworkflow may be managed by a set of autonomous workflow rules for the workflow states and transitions in the subworkflow. State-Dependent Access Controls:State-dependent access controls define which project team members to own, view, or update development issues in each workflow state. DevTrack supports four state-dependent access controls: applicable owner rules, mandatory fields, read-only fields, and invisible fields.

127 Transition-Dependent Access Controls:Transition-dependent access controls define which project team members may perform actions and update issue properties in each transition. DevTrack supports four transition-dependent access controls: Who Can Change rules, mandatory fields, read-only fields, and invisible fields. Conditional Transitions:A conditional transition rule is defined by its name, a condition, and a target state. Every transition may be defined by multiple conditional transition rules. Issue Creation Triggers:In DevTrack, an issue creation trigger is a state-workflow rule that prompts the creation of new development issues based administrator-defined criteria. DevTrack supports both transition-dependent and statedependent issue creation triggers. To enable transition-based workflow: 1Select Workflow > Workflow Options. 2Click the Workflow Type ellipsis button. The Workflow Type dialog box appears. 3Select the Transition-based option in the Workflow Type dropdown list. 4Click the OK button. The Workflow Type dialog box closes. To enable workflow rules in transition-based projects: 1Select Workflow > Workflow Options. 2Enable the transition-based workflow model. 3 Optional: To enable support for state-dependent access controls, select the check box next to the rule: In the transition-based workflow model, five state-dependent access controls are supported. Applicable Owners:Applicable owner access controls define which project team members may own development issues in each workflow state based on their account type or team group. Mandatory Fields:Mandatory field access controls define specific fields as mandatory in particular workflow states. Read-Only Fields:Read-only field access controls define specific fields as read-only in particular workflow states. Invisible Field:Invisible field access controls define specific fields as invisible in particular workflow states. 4 Optional: To enable support for transition-dependent access controls, select the check box next to the rule: In the transition-based workflow model, five state-dependent access controls are supported: Mandatory Fields:Mandatory field access controls define specific fields as mandatory in particular transitions. Read-Only Fields:Read-only field access controls define specific fields as read-only in particular transitions. Invisible Fields:Invisible field access controls define specific fields as invisible in particular transitions. Who Can Perform:Who Can Perform access controls define which project team members may perform each transition based on their account type or team group. 5 Optional: To enable support for transition-dependent field choices, select the Support Transition-driven Field Choice Selection and select a rule option: 6 Optional: To enable transition-dependent new issue triggering, select a triggering option button. 7 Optional: To enable transition-dependent automation triggering, select the an automation option button. 8Click the OK button Adding Workflow States Deleting Issue Workflow States Defining State-Dependent Workflow Rules Defining State-Dependent Applicable Owner Access Controls Defining State-Dependent Default Issue Owners Defining Applicable Workflow States Defining State-Dependent Mandatory Fields Defining State-Dependent Read-Only Fields Defining State-Dependent Invisible Fields

128 6.4 Administering Transitions The state-based workflow model enables development organizations to define simple workflow defined by rudimentary workflow rules, access controls, and triggers. In the state-based workflow model, issues progress from workflow state to workflow state based on explicit changes to the issue workflow state property of development issues by project members. State-based workflow may be graphically represented as a series of boxes and arrows.in state-based workflow, a single,unnamedtransition may connect any two Figure 5-3: State-Based Workflow states in workflow. Every workflow state may be defined by one or more applicable next states workflow states that development issues may pass to from that state. In project using the state-based workflow model, all workflow rules, access controls, and automation triggers are state-dependent. State-dependent workflow rules define the ability of project team members to own, view, or update development issues on a state-by-state basis. The relative lack of flexibility and power of the state-based workflow model means that workflow states and workflow rules may be quickly defined. The statebased workflow model does not support transition-dependent workflow rules, multiple workflows, State-based workflow supports the following state-dependent workflow rules: To enable state-based workflow: 1Select Workflow > Workflow Options. 2Click the Workflow Type ellipsis button. The Workflow Type dialog box appears. 3Select the State-based option in the Workflow Type dropdown list. 4Click the OK button. The Workflow Type dialog box closes. To enable state-dependent workflow rules in state-based projects: 1Select Workflow > Workflow Options. 2Enable the state-based workflow model. 3 Optional: To enable support for applicable workflow state rules or graphical workflow, click the Change button in the Workflow Options area. To enable applicable workflow state rules, click the Applicable State Changes (Next State) check box. To define state-based workflow using graphical workflow tools, select the Define Graphically option button. To define state-based workflow using workflow settings controls, select the define through Workflow Settings option button. 4 Optional: To enable state-dependent support for access controls, select the check box next to the rule: In the state-based workflow model, five state-dependent access controls are supported. Applicable Owners:Applicable owner access controls define which project team members may own development issues in each workflow state based on their account type or team group. Mandatory Fields:Mandatory field access controls define specific fields as mandatory in particular workflow states. Read-Only Fields:Read-only field access controls define specific fields as read-only in particular workflow states. Invisible Field:Invisible field access controls define specific fields as invisible in particular workflow states. 5 Optional: To enable state-dependent new issue triggering, select the Enable New Issue Triggering Creation check box. 6 Optional: To enable interproject action automation triggering, select the Based on Target State option button. 7Click the OK button Adding Transitions Editing Transitions Defining Transition-Dependent Workflow Rules

129 6.4.3 Defining Transition-Dependent Workflow Rules Defining Transition-Dependent Issue Management Privileges Defining Transition-Dependent Mandatory Fields Defining Transition-Dependent Read-Only Fields Defining Transition-Dependent Invisible Fields 6.5 Administering Transition-Dependent Master-Detail Relationships A transition-dependent access control is a workflow rule that is enforced on a transition-by-transition basis. Using transition-dependent workflow rules, development organizations may restrict the ability of project team members to perform certain transitions or restricts their ability to make changes within a transition. Transition-dependent access controls may be defined in projects using transitionbased workflow only. DevTrack supports four transition-dependent access controls: Mandatory Fields:Mandatory field access controls define specific fields as mandatory in particular transitions. Read-Only Fields:Read-only field access controls define specific fields as read-only in particular transitions. Invisible Fields:Invisible field access controls define specific fields as invisible in particular transitions. Who Can Perform Access Controls:Who Can Perform access controls define which project team members may perform each transition based on their account type or team group Enabling and Configuring Transition-Dependent Master-Detail Rules Defining Transition-Dependent Master-Detail Relationships 6.6 Administering Conditional Transitions In DevTrack, the lifecycle of a development issue is defined byworkflow statesandtransitions. An issue workflow state represents a distinct stage in the lifecycle of a development issue. and determines how that issue is managed in workflow. An issue workflow state may be defined by its name and description, status (open,closed: success, orclosed: failed), graphical attributes, and state-dependent workflow rules. Figure 5-4: States and Transitions in State-Based Workflow Issue workflow state administration is the process of enabling support for state-dependent workflow rules, defining issue workflow states, and defining statedependent workflow rules for each workflow state. Workflow state statuses In DevTrack, every issue workflow state is defined by itsstate status. The status of a workflow state indicates the relative success of development issue, the next steps (transitions) in the development lifecycle, and rules for managing issues. DevTrack supports three workflow state statuses: Open, Closed: Success, or Closed: Failed. An open workflow state a workflow state with anopen status represents a stage in the issue lifecycle. Open development issues are actively tracked in a project.while an issue is in an open state it may be updated and forwarded to other issue workflow states and project members. A closed workflow state a workflow state with either theclosed: Success statusorclosed: Failure status represents the last stage of the issue lifecycle. Closed issues cannot be updated or forwarded unless they are reopened by a project member and routed to an open state. A project may have multiple closed issue workflow states. The ability to reopen closed issues may be controlled using account type-based access controls. State-dependent workflow rules State-dependent workflow rules are an optional DevTrack feature that may be enabled in projects using either state-based workflow or transition-based workflow. Using state-dependent workflow rules, development organizations may restrict the ability of project team members to own, view, or update development issues

130 when those issues are in specific workflow states. State-dependent workflow rules define how development issues are managed in each issue workflow state.devtrack supports four optional state-dependent workflow rules: applicable owner, mandatory field, invisible field, and read-only field access controls. Applicable Owner:Anapplicable owneris a project team member or group folder that may be assigned ownership of a development issue when that issue is in a particular workflow state. Mandatory Fields:A mandatory field is a data-entry control that must be defined in an issue workflow state before the issue may progress to the next stage in its lifecycle. Read-Only Fields:A read-only field is a data-entry control that may be viewed, but not edited in an issue workflow state before the issue may progress to the next stage in its lifecycle. Invisible Fields page:an invisible field is a data-entry control that is not displayed in an issue workflow state. Data tracked in the invisible control may not be viewed or edited while the issue is in that workflow state Enabling Conditional Transition Support Defining Conditional Transition Rules Defining Conditional Transition Rule Conditions 6.7 Administering Inter-project Action Automations An issue workflow state is defined by its name and description, status (open, closed: success, or closed: failed), graphical attributes, and state-dependent workflow rules. The Add a State manager may display up to eight tabbed form pages including the General Settings tab, the Applicable Owners tab, the Read-Only Fields tab, the Mandatory Fields tab, the Invisible Fields tab, the Triggering tab. Each tab enables project administrators to definestate-dependent workflow rulesfor the current workflow state. For more information see Defining State-Dependent Workflow Rules. To add an issue workflow state (in graphical workflow): 1Select Workflow > Workflow Design. 2Right-click in the workflow design page and select the Add a State command in the shortcut menu. 3Define the title and description of the workflow state in the Properties tab. 4Define the workflow status of the workflow state. 5To define the status of the issue workflow state, select the Open, Closed - Success, or Closed - Failed option button. In DevTrack, every issue workflow state is defined by a workflow status: Open, Closed: Success, or Closed: Failed. Open:An open workflow state a workflow state with an Open status represents a development stage in which development issue are considered active. Closed: Success:A closed workflow state a workflow state with aclosed: Success status represents the final stage in the issue lifecycle of work items that have been successfully completed. Closed: Failed:A closed workflow state a workflow state with aclosed: Failure status represents the final stage in the issue lifecycle of work items that have not been successfully completed Defining State-Dependent Inter-project Automation Rules Defining Transition-Dependent Inter-project Automation Rules 6.8 Administering Issue Creation Triggers Deleting a workflow state automatically deletes all of the transitions linked to that state Defining Transition-Dependent Issue Creation Triggers Administering State-Dependent Issue Creation Triggers Chapter 7 Administering Advanced Features 7.1 Administering DevTrack Development Issue Routing In DevTrack, issue autorouting is an optional feature by which development issues may be automatically assigned to applicable issue owners based on the workload or skill-level of those project team members. The recipients of routed issues are determined by administrator-defined issue routing rules. Routing rules define the criteria for selecting an appropriate issue owner (workload, skill, or a combination of workload and skill), the criteria for routing development issues (fields and field values), and the default owner of issues that do not meet the routing criteria.

131 To be subject to issue routing rules a development issue must be forwarded to the{auto-assignment} rule in the course of project workflow. Issues that are owned by the {Auto-Assignment} rule are automatically routed to the appropriate project team member or group folder based on administrator-defined routing rules. Issue routing may be very valuable to development organizations that need to automatically distribute development issues to project team members based on their workload or the skill-level of its project team members. Issue routing may be used to meet the following needs: A programmer fixes an issue, but does not have the privilege to assign the issue to another owner. A team member submits a new issue, but does not know the appropriate owner for the issue. A manager needs to submit a large number of issues before an approaching deadline. The Routing agent can assign the issues to owners with the proper skill level and reasonable workload. Using controls in the Auto-Routing page, administrators may enable issue routing, define the multiple rules for routing issues based on issue properties, and determine the criteria that is used to assign those issues to DevTrack project members Enabling Issue Routing Defining Issue Routing Rule Criteria Defining the Default Recipient of Routed Issues Defining Issue Routing Rules (Criteria) Defining Issue Routing Targets (Potential Owners) 7.2 Administering Personal Folders In DevTrack, issue autorouting is an optional feature that must be enabled in each DevTrack development project. All issue routing rules are project-specific. To be subject to issue routing rules a development issue must be forwarded to the{auto-assignment} rule in the course of project workflow. Issues that are owned by the {Auto-Assignment} rule are automatically routed to the appropriate project teammember or group folder based on administrator-defined routing rules. For more information see Defining State-Dependent Applicable Owner Access Controls To enable development issue routing: 1Select Advanced Features > Auto-Routing in the tree panel. 2Select the Enable Auto-Routing check box Enabling Personal Folder Support Defining Personal Folders 7.3 Administering Issue Templates In DevTrack, administrator-defined routing rules are based on one of three different criteria:workload,skills, orworkload & skills. The issue routing rule criteria selected determines the method that is used in that project for identifying the appropriate owners of routed issues. Issue routing rules define a formula for identifying the most appropriate owner of development issues based on a combination of issue property values and the skills or workload of potential issue owners. Skill-Based Assignment:In projects employing skill-based routing rules, development issues are automatically assigned to project team members based on their expertise (skill-level) a numerical value assigned to each project team member by the project administrator. Workload-Based Assignment:In projects employing workload-based routing rules, development issues are automatically assigned to project team members based on their workload the project member that owns the fewest issues is assigned the issue. Formula-Based Assignment:Formula-based routing rules route issues to target owners based an administrator defined formula that weighs both the skill level of the potential target owners and the workload of those potential owners. To define project routing criteria: 1Select Advanced Features > Auto-Routing in the tree panel. 2Select a routing criteria in the Routing Property list. To use workload-based criteria for routing issues, select the Based on Workload option button. To user skill-based criteria for routing issues, select the Based on Skill option button. To user formula-based criteria for routing issues, select the Based on Formula option button and define the relative weights of workload and skill in evaluating routing options Defining Issue Template Options

132 7.4 Administering Link Types The default target of routed issues is the project team member or group folder that is automatically assigned routed development issues that do not meet any of the criteria identified by at least one routing rule. Project administrators may control issue routing usingissue routing ruleswhich define the criteria (issue field values) that must be met for a development issue to be automatically routed to the appropriate project team member. Issues that do not meet the criteria defined by at least one issue routing rule are automatically assigned to the default owner of routed issues. To define the default recipient of routed issues: 1Select Advanced Features > Auto-Routing in the tree panel. 2Select a project team member in the Default Target If No Criteria Are Met dropdown list. The Default Target If No Criteria Are Met dropdown list displays the names of all project team members, group folders, and the{unassigned} variable Understanding Interproject Linking Defining Referential Link Types Defining Parent-Child Link Types Deleting Link Types 7.5 Administering Custom Crystal Reports In DevTrack, an issue routing rule is a set of criteria that identify which development issues are subject is administrator-defined routing rules based on issue field values. Every issue routing rule consists of a set of one or more issue fields and corresponding issue field values. Issue routing rule criteria may be based on the following fields: Component Fix Target Platform Priority Progress Status Type Version If a development issue is routed and the issue does not meet the criteria identified by any of the routing rules, the DevTrack workflow engine automatically assigns the issue to the default target. For more information see Defining the Default Recipient of Routed Issues. To define an issue routing rule: 1Select Advanced Features > Auto-Routing in the tree panel. 2Click the New Criteria button. The New Routing Rule dialog box appears. 3Select a issue property in the Field Name list. The Field Name list displays seven issue property fields. 4Select an issue property value in the Selection list. The Selection list displays field values that define the selected issue property field. 5Click the OK button Choosing DevTrack Reporting Platforms Defining Custom Crystal Report Template Folders Adding User-Defined Custom Reports 7.6 Managing Issue Priority To define the default recipient of routed issues: 1Select Advanced Features > Auto-Routing in the tree panel. 2Select the Add Owner button. The Add Owner dialog box appears. 3Select a project team member. Routing targets (owners) must be created to complete an auto-assignment rule. An issue that meets the defined criteria defined will be routed to one of these targets. Each criterion has its own list of target owners.

133 4Enter a numerical value in the Skill Level text box. 5Click the OK button. The Add Owner dialog box closes Defining Priority Order Management Settings Defining Priority Value Management 7.7 Administering Status Groups In DevTrack, personal folders are an optional feature that enable project team members organize and manage their development issues and, optionally, those of their teams using personal folders the issue tree panel of the DevTrack client. Personal folders may be used to organize DevTrack issues for many different purposes. For example, personal folders may represent the relative priority of issues, organize issues by specific products or components, or by any other category that is useful to the business. DevTrack issue may be added to personal folder by three methods: Project members may drag and drop issues and events into their personal folders in the DevTrack client. Issues may be automatically sent to DevTrack project members based on issue notification rules or issue escalation rules. Shortcuts to development issues may be added or deleted from personal folders based on event notification rules or event escalation rules. Project administrators may define unique personal notification actions for each personal folder. All personal folders are administrator-defined. Project administrators may enable personal folder support, create, edit, and manage personal folders in the Personal Folder page of the Enterprise Editions folder. DevTrack project members may view two different types of personal folders in their clients: The My Personal Folder contains the personal folders that may contain issues assigned to the project member. Project members may drag and drop issues into these folders. The Team Member s Folder contains personal folders belonging to other project members belonging to the same group Enabling Status Group Support Defining Status Groups Chapter 8 Issue Notification & Escalation Adminis 8.1 Administering Issue Notifications and Escalations DevTrack issue notifications and issue escalations provide development organizations the means to ensure that issue stakeholders are automatically notified at key junctures in the issue lifecycle, enforce accountability, and drive the quality of their products. All issue notifications and issue escalations are based on administrator-defined rules which identify the triggers, conditions, notification methods and messages, and recipients of every notification or escalation action. Issue notifications and escalations enable to ensure that issue stakeholders are kept abreast of the status of their issues. The primary difference between DevTrack issue notification and issue escalation is how these rules are triggered: Issue Notification:Issue notifications alert issue stakeholders whenever key changes are made to their development issues subscribers may be notified whenever issues are created, updated, or closed in a development project. Issue Escalation:Issue escalations alert issue stakeholders at key points in the lifecycle of development issues or when insufficient action is taken on an issue in a defined time period and provide for the reassignment of escalated issues to other project members and workflow states. Both DevTrack issue notification and issue escalation support: Customized notification triggers. The trigger defines the specificaction(issue notification) orlack of action(issue escalation) that prompts the delivery of the notification message. Customized conditions that limit the scope of the trigger to a subset of issues based on an administrator-defined query. Customized notification messages and notification methods ( , pager, mobile phone, and personal folder) Customized subscription rules including mandatory and optional notification subscriptions. Notification and escalation triggers The primary difference between DevTrack issue notifications and issue escalations is how these rules are triggered: Push and pull notification subscriptions TechExcel DevTrack supports bothpush notification subscriptionsandpull notification subscriptions. All issue notifications and escalations are defined by administrator-definedsubscription rules. Subscription rules determine whether a project team member must,

134 can, or cannot receive a notification. Subscriptions rules may mandate that certain project members receive issue notifications for certain issues while others mayopt inoropt outof individual subscriptions. Project administrators may also mandate that certain project memberneverreceive issue notifications based on issue notification rules. Push notifications are instantly and actively transferred (pushed) to subscribers. A project member is subscribed to all issues and is always notified when changes are made to issues based on that rule. Pull notifications are optionally sent. A project member may choose to subscribe to a notifications on an issue-by-issue basis. 8.2 Administering the DevTrack Mail Service The DevTrack Mail Service enables development organizations to integrate DevTrack workflow, issue notification, event scheduling, and issue escalation with the convenience of . All , pager, and mobile phone notifications are sent to subscribers through the the DevTrack Mail Service. DevTrack issue notification and escalation and event notification and escalation require the installation and configuration of the DevTrack Mail Service. The DevTrack Server communicates with the DevSuite Database Server and server to find and send messages generated within a DevTrack project. The DevTrack Mail Server retrieves the user name and password needed to access to the DevSuite Database Server from the DevSuite Application Server Managing Outgoing Server Settings Defining Issue Notification Sending Addresses Reloading Settings to DevTrack Mail Service Defining Issue Notification Activity Dates 8.3 Administering Issue Notifications To define outgoing mail server properties: 1Select Advanced Features > Settings. 2Select the Outgoing Mail Server tab. 3Define SMTP server address. Specify the name or the TCP/IP address of the outgoing mail server. 4 Optional: To define authentication, select the mail server requires authentication option and specify required user account information. The account information can be either a domain user account or the server computer account with privileges of using the outgoing mail server service. To define outgoing character set: 1Select Advanced Features > Settings. 2Select the Outgoing Mail Server tab. 3Select the character set from the dropdown list. To define outgoing text wrapping: 1Select Advanced Features > Settings. 2Select the Outgoing Mail Server tab. 3Select the character set from the dropdown list. 4Define text wrapping for outgoing Enabling Issue Notification in a DevTrack Project Defining Issue Notification Rules Administering Issue Notification Triggers Defining Custom Issue Notification Status Change Triggers Defining Custom Field Change Triggers 8.4 Administering Issue Escalations

135 All , pager, and mobile phone issue notifications are sent from a single, administrator-defined address. Project administrators may define the sending address and the name of the sender for all project issue notifications in the Issue Notifications page of the Issue Notification subfolder in the Advanced Settings folder. To define the issue notification sending address: 1Select the Issue Notifications page of the Issue Notification subfolder. 2Define the sending address for project issue notifications in the Address control. 3Define the name of the sender of issue notifications in the Name control Administering Issue Escalation Rules Understanding Issue Escalation Triggers Administering Issue Escalation Actions Administering Issue Escalation Schedules Chapter 9 Integration Administration 9.1 Administrating DevTrack Integration This chapter covers a wide range of -related features and -related administrative tasks. The tasks described in this chapter are both system-level administrative tasks and project-level administrative tasks. System administrators are responsible for installing the DevTrack Server service, the DevTrack Retrieval service, and configuring the DevTrack environment to operate properly. System administrators are also responsible for defining error handling rules. Project administrator may enable and define -based tools that enable project members to work together more effectively. DevTrack integration is a prerequisite for the following features: Issue autosubmission enables project members to submit issues to DevTrack by . DevTrack automatically creates new issues based on the content of the subject line and body of the . Customer contacts may send s containing issue information to co-workers through the Beta Customer Portal. Issue notification enables project members to be notified automatically whenever an administrator-defined issue notification rule is triggered. Administrators may define all appropriate triggers, conditions, and recipients. Issue escalation enables project members to be notified automatically whenever an administrator-defined issue escalation rule is triggered. Administrators may define all appropriate triggers, conditions, and recipients. Event notification enables project members to be notified automatically whenever an administrator-defined event notification rule is triggered. Administrators may define all appropriate triggers, conditions, applicable event templates, and recipients. Event escalation enables project members to be notified automatically whenever an administrator-defined event escalation rule is triggered. Administrators may define all appropriate triggers, conditions, and recipients. The DevTrack mail server must be installed before project administrator may enable notification features. 9.2 Administrating the Retrieval Service Project administrators may use tools in the Integration page to define the incoming mail server, the outgoing mail server, and specify which account types may submit issues through . The Integration page is divided in three tabs: the General Settings tab, Incoming Mail Server tab, the Outgoing Mail Server tab, and the Auto Submit tab. Each tab enables administrators to manage a different aspect of their project integration settings. TheGeneral Settings tabenables administrators to enable submission, define the submission address, and define the protocol for the project. The Incoming Mail Server tab enables administrators to define the POP3 incoming mail server properties. Incoming mail settings enable the DevTrack system to retrieve from the server. The Outgoing Mail Server tab enables administrators to define SMTP outgoing mail server properties. Outgoing mail settings enable users to send from within the DevTrack client, and notification to be automatically delivered. The Auto Submit tab enables administrators to define which account types may submit issues through . retrieval administrative tasks include: Defining Incoming Mail Server Settings Defining Incoming Mail Server Properties Defining Autosubmit Settings Managing Issue Submission by Defining Incoming Mail Server Settings

136 9.2.2 Defining Incoming Mail Server Properties Defining Autosubmit Settings 9.3 Managing Issue Submission by Project administrators may use controls in thegeneral Settings tabof the in the Integration page to enable or disable the submission, define the address to which issues are to be sent, and define the protocol for the project, and select an protocol. Administrators must enable submission and otherwise project members may not submit issues through . Administrators must define an address to which all issues submitted through are sent. Only s submitted to this address by approved users will be automatically converted into new issues. The return address is specific to the current project, as different development projects may use different accounts for submission. To define general integration settings: 1Select the Settings page in the Admin Tree window. 2Select the General Settings tab. 3Select the Support Submission check box. If this check box is not selected, no user may submit an issue through regardless of other settings. 4Specify the dedicated incoming mail account where team members will submit issues in the Address for issue submission field. 5Select the protocol to use for integration: SMTP/POP3 or Microsoft MAPI. If administrators choose to use Microsoft MAPI, administrators must also specify a profile name Understanding Advanced Issue Autosubmission The [Issue Properties] tag The [Description] tag Custom tags for multiple lines of text Chapter 10 Subproject Administration 10.1 Understanding DevSuite Subprojects In DevSuite, a subproject is a tool for organizing development issues into smaller, more manageable groupings of issues. Development teams may create subproject folders with subproject folders to organize their work and define subproject statuses, prioritize subprojects, and set due dates for all subprojects. Each subproject has its own description, priority, status, and start and end dates. Every work project represents a distinct area of work and is defined by unique team structures (account types, team groups, and group folders) and workflow rules. Subprojects provide developers the means to organize, schedule, prioritize, and track groups of issues and to implement an additional layer of security within the project. Subprojects are ideal for development organizations that wish to develop multiple products within a single DevTrack project. Subprojects are also useful to organizations developing products made up of multiple components or modules, or who wish to track many different types of issues in a single DevTrack project. The subproject hierarchy is displayed in both the DevTrack Windows and Web client and the DevPlan smart client providing development organizations with a common framework for managing, tracking, and scheduling tasks. In DevTrack, the subproject hierarchy is displayed in the issue tree panel and organizes development issues by product, version, and build. Figure 9-1: Subproject Enabled Client GUI In DevPlan, the subproject hierarchy is displayed in the issue tree panel and organizes development issues by product, version, and build.

137 Figure 9-2: Subproject Enabled Client GUI Subprojects serve three primary purposes in DevTrack projects: Subprojects facilitate the management of multiple development projects within a single DevTrack project. Subprojects enable development teams to define rules for managing issues within a subproject. Subprojects enable development teams to use multiple workflow to manage project issues Note:If TechExcel DevPlan integration is enabled for a DevTrack project, all subproject management tasks are performed in the DevPlan smart client. Project team members may create and manage subprojects in the DevTrack client only if DevPlan integration is not enabled. In DevTrack Admin, project administrators may define rules for defining the status and priority of subprojects, and account type access privileges, which determine which project members may create, edit, and delete subprojects within the DevTrack project. The status of a subproject enables project members to indicate the current progress state of a subproject. The status of a subproject may be defined independently or be linked to the progress state of the issues in the subproject. The priority of a subproject enables project members to indicate the current priority of a subproject relative to other subprojects. All subproject properties may be defined in the Subproject manager within the DevTrack client. Administrators may use tools in the Subprojects subfolder to enable subprojects, define subproject statuses, subproject priorities, and subproject access privileges Understanding Subprojects and the Beta Customer Portal 10.2 Administering Subproject Settings Projects that are using the Beta Customer Portal may wish to route all issues submitted from beta customers through the Beta Customer Portal to a subproject. Project administrators may define a default subproject for every customer created in a customer base project. All issues submitted by that customer are submitted to a DevTrack project would by default be created in the selected subproject Enabling Subproject Support Defining Subproject Terminology Defining Default Subprojects Defining Applicable Issue Types 10.3 Administering Subproject Statuses In DevSuite, a subproject is a discreet area of work that corresponds to a specific product, feature, version, or build. Using subprojects, development teams may divide a DevTrack project into smaller, more manageable groupings of issues. Project members may schedule, prioritize, and track those issues using subproject properties and, optionally, subproject workflow. Using controls in the General Settings page, project administrators may enable subproject support in a DevTrack project and to enable team member access controls, applicable issue owners, and applicable issue statuses in subprojects. Project administrators must enable support for subprojects in each DevTrack project. If subproject support is not enabled no subproject settings can be implemented within the project and the issue tree panel does not appear in the DevTrack Windows client Defining Independent Subproject Statuses Defining Subproject Status Based on Highest Ranking Defining Subproject Status Based on Lowest Ranking

138 Defining Subproject Status Based on Issue Status 10.4 Administering Subproject Priorities In TechExcel DevTrack, subprojects are an optional Enterprise Edition feature that must be enabled in each work project. Basic subproject administrative tasks include enabling subproject support, enabling DevPlan integration support, and defining how subprojects are identified and managed in the integrated DevSuite site. To enable subprojects: 1Select the General Settings page in the Subprojects subfolder. 2Select the Enable Subproject Support check box. 3Enter an alternative title for subprojects the Refer As field. The Refer As option enables project administrators to change the Subproject label displayed in the DevTrack client. The text entered in the Refer As field is displayed instead of the wordsubprojectthroughout the project in both the Windows and Web clients. The text entered does not change the title of the Project Issues folder in the Issue Tree window of the DevTrack Windows client. 4Select a default subproject from the Default Subproject Creation dropdown list Creating Independent Subproject Priorities Defining Highest Subproject Priorities Defining Lowest Subproject Priorities Defining Linked to Issue Subproject Priorities Chapter 11 Time and Cost Tracking Administration 11.1 Understanding DevSuite Development Time and Cost Tracking DevTrack enables development organizations to track the time that project members spend working on development issues and calculate the cost of their development efforts. In DevTrack, the time and cost spent on development tasks Time and cost tracking data may be viewed enabling development organizations to identify and analyze development and user trends. Time Tracking:Time tracking measures the amount of time that project members spend working on different kinds of development tasks. Time entries enable project teams to track the time that each project member spends on an issue. Cost Tracking:Cost tracking calculates the cost of the hours each project member spends on development tasks based on an administrator-defined hourly rate that is defined for each work type. The hourly rate for each work type may be defined by account type or user account. Issue-level time cost tracking are optional DevTrack features that must be enabled in the project by an administrator. Time tracking may be implemented without cost tracking, but the cost-tracking feature requires that time tracking features be enabled and defined Understanding DevSuite Time and Cost Tracking Administration 11.2 Administering Time Groups and Categories DevTrack development time and costs are tracked bytime groupandtime category. DevSuite time tracking and cost tracking are interrelated tools that rely on administrator-defined time groups and time categories to manage and track development tasks. Development tasks and costs are defined at two levels providing the organization the flexibility to group many different types of tasks for reporting and cost calculation. In DevSuite, time and cost tracking is defined at both the system-level and the project-level. System Level:Time groups and time categories are defined at the systemlevel and are shared by every project (DevSpec or DevTrack) in a DevSuite site. Project Level:In DevTrack and DevSpec, time and cost tracking may be enabled on a project-by-project basis. Time groups and time categories must be defined as applicable to a project to be used for time and costing tracking in that project. Time category default costs may be overridden at the project-level. In DevSuite, time groups and time categories are defined at the system-level and are shared by all DevTrack and DevSpec projects in a DevSuite site. Project administrators may enable time tracking and cost tracking in DevTrack projects and to define time tracking settings in the Issue Level Time Track page Selecting Applicable Time Categories Enabling Time Tracking

139 Enabling Cost Tracking Defining Project Time Tracking Methods Defining Hourly Rate by Account Type Defining Hourly Rate by User Account 11.3 Administering Time and Cost Tracking Privileges All DevTrack issue-level time and cost tracking is based on administrator-defined time groups and time categories. DevSuite time groups and time categories provide the organization the flexibility to group many different types of tasks for reporting and cost calculation. Each administrator-defined time category represents a development task or a set of development tasks that the business wishes to track together. Time Group:A time group is an administrator-defined grouping of time categories that identifies different types of work that share common characteristics. Each time group belongs to one of four time types: Design Time time type, Development Time time type, Testing Time time type, and Other time type. Time Category: Time categories enable development organizations and group together many different tasks for reporting and cost calculation. Time groups and time categories enable development organizations to manage and track development tasks and costs. Time groups and child time categories are managed in the time category tree, a hierarchical structure of folders and subfolders. In DevSuite, all time groups and time categories are defined at the system-level and are shared by every other DevTrack and DevSuite project in the DevSuite site. Project administrators are responsible for enabling support each time category that is used in their project. Chapter 12 Knowledge Management Administration 12.1 Understanding DevTrack Knowledge Management Project knowledge managementis the control of knowledge items (documents, files, topics, and URLs) that are relevant to multiple issues, subprojects, or the project itself. DevTrack knowledge management tools enable development organizations to manage multiple versions of documents and to link versioncontrolled documents to relevant development issues. Issue knowledge managementis the control and tracking of issue-specific data. Development issues are tools for tracking development tasks and for sharing key information with all issue stakeholders. The Note page provides development organizations with a central repository for storing and sharing information about that specific development task Administering KnowledgeWise Integration Enabling KnowledgeWise Integration Enabling DevSpec Integration Migrating Knowledge View Data 12.3 Administering Project-level Knowledge Management To integration a DevTrack development project with a KnowledgeWise knowledge base project, select the Enable KnowledgeWise Integration check box in the KnowledgeWise Integration page Understanding KnowledgeWise Understanding Knowledge Items Understanding Knowledge View Access Controls Enabling the Knowledge View Selecting a Revision System Defining the Maximum Number of Revisions Customizing the Description Page

140 Customizing the History Page Customizing the Resolution Page Backing up the Document Files 12.4 Administering Issue-level Knowledge Management To integration a DevTrack development project with a DevSpec project, select the Enable DevSpec Integration check box in the KnowledgeWise Integration page Understanding the Notes Page Enabling the Notes Page Customizing Note Page List Columns Understanding Memo Field Time Stamping Managing Note Types Managing Note Access Controls DevTrack Projects Administration (Enterprise) Chapter 1 DevTrack Concepts 1.1 Understanding TechExcel DevTrack and DevSuite TechExcel DevSuite is a family of integrated application lifecycle management (ALM) tools that place knowledge management from ideas, to formal specifications, to competitive information to issue resolution and customer insight at the core of any product development initiative. The DevSuite knowledge-centric strategy enables improve communication, keep up-to-date on changes, and reduce the development cycles so that the business may deliver the right products for the right markets in the shortest possible time. Figure 1-1: DevSuite Knowledge-Centric Development DevSuite places knowledge management at the core of all development processes. TechExcel KnowledgeWise provides for the easy and efficient collection and organization of informal ideas, gathered from a wide variety of sources, that area shared across multiple DevSpec, DevTrack, and DevTest projects. KnowledgeWise projects provide controlled access to documents, improve communication and coordination between distributed development teams, and facilitate the management and sharing of information between development teams and project stakeholders. TechExcel DevSuite leverages intellectual assets with KnowledgeWise, communicating a clear product vision and tactical execution strategy by linking ideas and customer feedback, specifications, requirements, designs, prototypes, and other documents to specific areas of work Understanding DevSuite ALM Solutions

141 1.1.2 Understanding TechExcel Project Hierarchy 1.2 Understanding DevSuite Administration TechExcel DevSuite features five ALM solutions that operate in an n-tier architecture: TechExcel KnowledgeWise, TechExcel DevTrack, TechExcel DevPlan, TechExcel DevSpec, and TechExcel DevTest. All DevSuite products share the same core architecture the DevSuite Database Server, DevSuite Application Server, DevSuite Document Server, and DevSuite Web Services and are fully integrated enabling every branch of the development organization to communicate and work together. KnowledgeWise TechExcel DevSuite leverages intellectual assets with KnowledgeWise, communicating a clear product vision and tactical execution strategy by linking ideas and customer feedback,specifications, requirements, designs, prototypes, and other documents to specific areas of work during a development project.documents are shared with all resources involved in the executionof the project allowing for an uncompromised vision to direct the path of any development project. DevPlan TechExcel DevPlan manages the transformation of concepts into formal strategic plans. DevPlan offers an intuitive planninghierarchy to formalize scope an optimize resource usage,team-based planning and calendaring capabilities. These features enable complete control over all product development projects from design planning to implementation and enables increased team efficiency and collaboration. DevSpec TechExcel DevSpec is an integrated requirements management solution that is specifically designed to provide visibility,traceability and validation of your product or project requirements.devspec provides a frame work to create new requirements, specifications and features that can be linked to development and testing implementation projects. DevTrack TechExcel DevTrack enables development teams to manage every aspect of the development process including issue management, team management, and communications management. DevTest TechExcel DevTest is a test management solution that enables test organizations to manage every stage of testing life cycle from test case design, to test execution, to test analysis. DevTest provides testing groups with the tools they need work more effectively and efficiently, hold down costs, and to deliver higher quality products. While each element is valuable even when functioning independently, the DevSuite architecture is founded upon the assumption of future scaling and is capable of advanced inter-module integration. Whether used as separate components or as an incorporated set of applications, the DevSuite solutions are ideal for companies at any stage in their product development Understanding DevSuite Site (System-Level) Administration Understanding Project Administration 1.3 Understanding DevSuite Sample Projects and Templates At the core of every DevSuite implementation a DevSuite site is one or more KnowledgeWise knowledge management projects that organize, manage, and track the knowledge collected in multiple DevSpec, DevTrack, and DevTest projects. All projects in a DevSuite site are organized into a hierarchical structure that defines the relationships between the projects in a DevSuite site. Every DevSpec or DevTrack project is the child of a parent KnowledgeWise knowledge management project and relies on that project to manage project intelligence. Figure 1-2: DevSuite Project Hierarchy KnowledgeWise enables development organizations to build a knowledge base of shared knowledge in many different media. All knowledge items may be linked with different areas of work so that internal teams and external customers can search the knowledge base for self-service content based on account type-based privileges and access controls.

142 KnowledgeWise projects may be accessed by three methods: (1) the KnowledgeWise Web client, (2) the knowledge view of a child DevSpec project; (2) the knowledge view of a child DevTrack project Understanding Sample Projects Understanding Project Templates Understanding Solution Templates Chapter 2 Iterative Development Administration 2.1 Understanding DevSuite Iterative Development TechExcel DevSuite provides complete documentation for implementing each methodology that describes how DevSuite workflow and automation may be used to implement and enforce best practices. Each solution template defines DevSuite project settings based on software development best practices so that development organizations may get up and running quickly. Once these business rules are in place, development teams may subsequently customize the project settings to suit their individual needs using TechExcel's award-winning project customization tools. Using DevSuite, development methodologies longer merely serve as guidelines, but define and direct the daily activities of every team member. 2.2 Administering Project-Level Iterative Development Enabling Iterative Development Iterative development is an optional DevSuite feature that must be enabled on a project-by-project basis. To enable iterative development: 1 Select Project Settings > Methodology Support>Methodology Settings 2 Select the Enable Iterative Development check box Specifying Iterative Development Terminology Defining Iteration Durations Resource Allocation on Iterations Iterative Subproject Templates 2.3 Understanding Implementation Modules DevSuite supports five development methodologies. Methodology Iteration Term Iteration Group Term CMMI Iteration Iteration Group Iterative Development Scrum Development Sprint Milestone Specification Driven Development Test Driven Development Table 2-1: Iterative Terms To specify iterative development methodology: 1 Select Project Settings >Methodology Support>Methodology Settings> Development Method Different terms are used to refer to iterative processes in different development methodologies. In DevSuite, project administrators may customize the terms used to refer to key development terms to suite their individual needs. To specify iterative development terminology: 1 Select Project Settings > Iterative Development. 2 Input text in the Refer Iteration As text box. 3 Input text in the Refer Iteration Group text box.

143 2.4 Administering Development Backlogs The default duration of an iteration may be predefined to any period between a week and three months: One Week Two Weeks Three Weeks Four Weeks Semi Month One Month Two Months Three Months Alternately, project administrators may choose to enable project team members to freely define the duration of each iteration by selecting the {Freely Defined} option. To define iteration duration settings: 1 Select Project Settings > Methodology Support>Methodology Settings>Iterative Development 2 Select the Enable Predefined Iteration Duration check box. 3 Select an option from the Iteration Duration dropdown list. In addition, DevSuite can prevent assigning new issues/tasks after an iteration end date. To disable work assignment: 1 Select Project Settings > Methodology Support>Methodology Settings>Iterative Development 2 Select the Disable Work Assignment For Past Iteration check box. 3 Specify the number of days after a subproject end date for it to become a past iteration. Any issue/task assignment after this date cannot be assigned to this iteration Specifying Backlog Terminology Chapter 3 Enterprise Edition Features 3.1 Understanding DevTrack Enterprise Edition DevTrack Enterprise Editionis an optional upgrade that includes all of the features in the Standard Edition of DevTrack and adds a number of enterprise features including event management, subproject management, and the Beta Customer Portal. DevTrack Enterprise Edition features include: Multi Sites Subproject management DevTrack Search Engine Event management Event Notification Event Escalation Beta Customer Web Portal Multiple workflow 3.2 Administering the DevTrack Search Engine The DevTrack search engine enables project members to quickly search the notes, memo fields, and descriptions of DevTrack issues and events. Unlike the standard search engine built into each DevTrack project, the DevTrack Search Engine enables project members to search multiple notes fields (the Description field, issue history, link comments, and so on). Project administrators may also periodically index these fields to enhance project searches. Project administrators may install multiple DevTrack Search Engines in their DevTrack site. Each DevTrack project may have its own Search Engine or multiple projects may share the same DevTrack Search Engine. Once the Search Engine is installed and configured, project members may use keywords to search the following DevTrack fields: Description Close Note History Issue Notes Link Comments Event Description

144 The DevTrack Search Engine is a feature of the DevTrack Enterprise Edition.DevTrack Enterprise Editionis an optional upgrade that includes all of the features in the Standard Edition of DevTrack and adds a number of enterprise features including event management, subproject management, and the Beta Customer Portal. DevTrack Search Engine management tasks include: Installing the DevTrack Search Engine Defining Search Engine Settings Indexing the DevTrack Search Engine Installing the DevTrack Search Engine Defining Search Engine Settings Indexing the DevTrack Search Engine 3.3 Administering User Identity Authentication Project administrators may install the DevTrack Search Engine to enhance the searching capabilities of project members in DevTrack projects. The DevTrack Search Engine runs as a service and may managed using the Services manager in Administrative Tools of a Windows operating system. The DevTrack search service must be installed on the machinebeforea project may enable DevTrack Search Engine support and index the searchable fields in the project. To install the DevTrack Search Engine: 1Run the SearchSetup executable. The DevTrack Search Server Installation wizard installs the DevTrack Search Engine. 2During the installation the administrator must: Accept the license agreement. Ensure that the DevTrack Search Engine can connect to the DevTrack Application Server. 3The TechExcel DevTrack Search Engine Configuration dialog box appears. 4Define the name of the current DevTrack Search Engine in the Referred as Service Name field. Each DevTrack Search Engine installed in a DevTrack site may have its own name. Project administrators may choose which search engine is used for each DevTrack project. Multiple projects may use the same search engine. Naming search engines enable administrators to identify search engines in the system. 5Define the location of the index directory. 6Click the OK button. 7Click the Finish button. Chapter 4 Issue Types and Multiple Workflow Admin 4.1 Understanding Multiple Workflow and Issue Types TechExcel DevTrack is a tool for managing and tracking development tasks such as bug fixes, enhancements, or features in workflow. All development tasks are represented and tracked in the project asdevelopment issues. A development issue is a collection of data that represents a particular task or set of tasks that must be processed in the course of a development project. Every issue is defined by a unique issue ID, description, workflow state, owner, work description, and other dynamic properties. Issue typing and multiple workflow enable development organizations to define many different workflows that are specifically designed to suit development issues of a particular type. In DevTrack, different workflows and workflow rules may be defined for different issue types. Support for multiple workflow and issue typing is a DevTrack Enterprise Edition that must be enabled in each DevTrack project. Administrative tasks include the definition of issue types, the definition of subworkflows, and the assignment of subworkflows to the administrator-defined issue types. 4.2 Administering Multiple Workflow and Workflow Assignment In DevTrack, a single development project may support multiple workflows (subworkflows) to better manage different areas of development within the project. A workflow is a business process in which all activities are organized into repeatable patterns of work. Using multiple workflow, a development organization may define distinct workflows and access controls to manage differentissue types(for example, product defects, enhancements, and features). Multiple project workflow enables administrators to define subworkflows within the larger master workflow. Each subworkflow may be managed by a set of autonomous workflow rules for the workflow states and transitions in the subworkflow. Multiple workflow administration is the process of enabling support for multiple workflow and issue typing, selecting multiple workflow settings, defining workflow assignment settings, and workflow initialization options.

145 4.2.1 Enabling Multiple Workflow Defining Multiple Workflow Settings Defining Subworkflows Understanding Workflow Assignment Methods Defining Issue Type Subworkflow Initialization Granting Issue Type Assignment Privileges 4.3 Administering Issue Types DevTrack also features multiple project workflow (subproject workflow) that is only available in projects using transition-based workflow. Multiple project workflow enables administrators to define workflow rules for individual subprojects within the larger master workflow. Administrators may optionally define a unique set of workflow rules for the workflow states and transitions within each subworkflow. Using multiple workflow options, each subproject may have its own workflow and workflow rules within the larger project workflow (Master workflow). Subproject workflow enables administrators to define multiple sets of workflow rules for workflow states and transitions, and tie those workflow rules to a subproject. An administrator may define different sets of subproject workflow rules to manage different subsets of issues. For example, both product defect issues and new feature issues may share the same workflow path, but be governed by entirely different workflow rules. For more information see Administering Multiple Workflow and Workflow Assignment Defining Development Issue Type Terms Linking Issue Type Property to Issue Property Fields Adding Issue Types Defining Default Issue Types Defining Issue Types Chapter 5 Development Event Administration 5.1 Administering DevTrack Development Events A development event represents a subtask of a development issue. Development events enable organizations to divide a development task into many different subtasks, assign each of those subtasks to a different project member, define separate start and due dates for each subtask, and manage and track each of those tasks independently in its own workflow. Development events enable project members to manage issue subtasks within a specific issue workflow state. Development events may be manually created by project members or automatically created based on administrator-defined workflow rules. All development events are based on administrator-defined development event templates. A development event template is a set of rules for managing events in project workflow. The life cycle of a development event and the rules that determine how that event is managed in workflow are defined by the event template that was used to create it. Development event administration, therefore, is the largely a matter of creating development event templates, defining the rules that manage events based on that template, and determining when events based on that event template may be created in the project. Development events and development event workflow are optional, DevTrack Enterprise Edition features. 5.2 Administering Event Groups An event group is a group of event templates that share a common set of workflow rules and that are managed together in a DevTrack project. DevTrack supports two different types of event groups in each DevTrack project. Regular event groups are event groups that may be used to represent and manage event templates belonging to the regular event type. Project administrators may create any number of regular event groups to manage regular development event templates. Co-owner event groups are event groups that represent and manage event templates belonging to the co-owner event type. The co-owner event group represents both linked and unlinked single-selection co-owner event templates. Project administrators may create any number of co-owner event groups to manage regular development event templates. In addition to the administrator-defined regular event groups and co-owner event groups, DevTrack also uses a single, system-defined {All Development Event} group to organize and manage multiple-selection co-owner event templates.

146 5.2.1 Creating Event Groups Ordering Event Groups Ordering Event Templates within Event Groups 5.3 Administering Regular Development Event Templates Event groups are tools that enable project administrators to better manage development event workflow in DevTrack projects. Project administrators may create, edit, and delete regular event groups and co-owner event groups in the Event Group page. All multiple variable co-owner event templates belong to the system-defined {All Development Events} event group. To create event groups: 1Click the New button in the Event Group page of the Event Group subfolder in the Events folder. The Add Event Group dialog box appears. 2Define a unique, descriptive name for the event group. 3Select the event type. Project administrators may create two types of event groups: regular event groups and co-owner event groups. To create a regular event group, select the Regular Event Group radio button. To create a co-owner event group, select the Co-Owner Event Group radio button. 4Enter a brief description of the event group in the Note control. 5Click the OK button Defining Regular Event Templates Editing Event Templates Defining Default Event Titles and Descriptions Defining Event Description Timestamping Rules Defining Default Event Workflow States Defining Default Event Owners Defining Default Event Start and Due Dates Defining Regular Development Event Attachment Rules 5.4 Administering Co-Owner Event Templates Project administrators may order administrator-defined event group folders within the parent regular event group folder and co-owner group folders within the parent co-owner event group folder. The Event Group tree list control organizes event groups and event templates into a hierarchical tree structure that hastworoot folders. the Regular Event Group folder and the Co-Owner Event Group folder. To order event groups: 1Select an event group in the Event Group tree list the Event Group subfolder in the Events folder. The Event Group tree list displays all administrator-defined event groups organized by event group type. Project administrators may create and edit two types of event groups:regular event groups and co-owner event groups. 2Move the event group higher or lower in the event group type folder. To move an event group higher, select the Up button. To move an event group lower, select the Down button Creating Co-Owner Event Templates Administering Event Variables

147 5.4.3 Enabling Co-owner Events and Event Variables Creating Unlinked Event Variables Creating Linked Event Variables Defining Co-Owner Event Attachment Rules 5.5 Administering Applicable Owners of Development Events Project administrators may order administrator-defined event templates within an event group in the Event Group tree list control of the Event Group page. To order event templates within event groups: 1Select an event template in the Event Group tree list the Event Group subfolder in the Events folder. The Event Group tree list displays all administrator-defined event groups organized by event group type. 2Move the event template higher or lower in the event group folder. To move an event group higher, select the Up button. To move an event group lower, select the Down button. 5.6 Administering Event Management Privileges and Access Controls In DevTrack, an event template is a set of business rules that defines how a development subtask is managed in a project. Every event template is defined by its applicable owners, account type-based access controls, attachment rules, as well as standard and advanced workflow rules. A regular event template is a template for creating and managing regular development events. A regular event instance inherits all of its properties from the event template used to create it. The owner of a regular event is limited to a list of applicable owners that are identified in the event template. Project administrators may create and define event templates in the Event Template page of the Events subfolder in theenterpriseedition folder. For each event template created in the Event Template page, the project administrator must define appropriate properties, attachment rules, access controls, an event group, event workflow rules, event notification rules, and event escalation rules Defining Event Access Controls Understanding Event Privileges 5.7 Administering Customer Access to Development Events A regular event template is a template for creating and managing regular development events. Regular event templates define the business rules that are used to manage regular development events in DevTrack projects. Every development event is based on an event template and is managed by the rules defined in that template. For each regular event template created in the Event Template page, the project administrator must also define appropriate properties, a set of applicable owners, attachment rules, access controls, an event group, event workflow rules, event notification rules, and event escalation rules. To define regular event template properties: 1Click the New button in the Event Template page of the Development Event subfolder. The Add a New Event Template dialog box appears. 2Define a unique, descriptive name for the event template in the Name text box control. The title of the event template is inherited by every development event based on that template and is the default title for those event instances. For more information see Defining Default Event Titles and Descriptions. 3Select the Regular Event option from the Event Type dropdown list. The Event Type dropdown list displays two options: The Regular Event option enables the administrator to create a regular event template. The Co-owner Event option enables the administrator to create a co-owner event template. 4 Optional:To assign the event template to an event group, select an event group from the Event Group dropdown list. The Event Group dropdown list displays all regular event groups and the {Ungrouped} system option. To assign the event template to an event group, select a regular event group in the Event Group dropdown list. Each regular event template may be assigned to one regular event group. To not assign the event template to an event group, select the {Ungrouped} option in the Event Group dropdown list. Ungrouped standard event templates are not subject to group advanced workflow rules. Event groups are an optional DevTrack Enterprise Edition feature that enable development organizations to define more powerful and flexible rules for

148 managing development events. For more information about event groups and group advanced workflow rules see Administering Event Groups. 5Define a brief description of the event in the Description field. Event template descriptions enable project manager to describe the purpose and functionality of an event template. 6Click the OK button. The Add a New Event Template dialog box closes. The regular event template is displayed in the Regular Events folder of the Event Templates tree control Understanding Event Customer Access Rights Defining Event Customer Access Controls 5.8 Administering Event Workflow Project administrators may edit basic event template properties in the Properties tab of the Event Templates page in the Development Events folder. Two key event template properties cannot be edited or updated. The Event Type property determines whether the event template may be used to create standard development events or co-owner development events. The Event Group property defines how events based the event template are managed using group advanced event workflow rules. Both event template properties are mandatory and can only be defined when the project administrator initially creates the event template. Chapter 6 Event Notification & Escalation Adminis 6.1 Administering Event Notifications and Escalations DevTrack event notifications and event escalations provide development organizations the means to ensure that event stakeholders are automatically notified at key junctures in the event lifecycle, enforce accountability, and drive the quality of their products. All event notifications and event escalations are based on administrator-defined rules which identify the triggers, conditions, notification methods and messages, and recipients of every notification or escalation action. Event notifications and escalations enable to ensure that event stakeholders are kept abreast of the status of their events. The primary difference between DevTrack event notification and event escalation is how these rules are triggered: Event Notification:Event notifications alert event stakeholders whenever key changes are made to their development events-subscribers may be notified whenever events are created, updated, or closed in a development project. Event Escalation:Event escalations alert event stakeholders at key points in the lifecycle of development events or when insufficient action is taken on an event in a defined time period and provide for the reassignment of escalated events to other project members and workflow states. Both DevTrack event notification and event escalation support: Customized notification triggers. The trigger defines the specificaction(event notification) orlack of action(event escalation) that prompts the delivery of the notification message. Customized conditions that limit the scope of the trigger to a subset of events based on an administrator-defined query. Customized notification messages and notification methods ( , pager,mobile phone, and personal folder) Customized subscription rules including mandatory and optional notification subscriptions Notification and escalation triggers Push and pull notification subscriptions 6.2 Administering Event Notifications The primary difference between DevTrack event notifications and event escalations is how these rules are triggered Enabling Event Notification in a DevTrack Project Defining Event Notification Rules Administering Event Notification Triggers 6.3 Administering Event Escalations TechExcel DevTrack supports bothpush notification subscriptionsandpull notification subscriptions.

149 All event notifications and escalations are defined by administrator-definedsubscription rules. Subscription rules determine whether a project team member must, can, or cannot receive a notification. Subscriptions rules may mandate that certain project members receive event notifications for certain events while others mayopt inoropt outof individual subscriptions. Project administrators may also mandate that certain project memberneverreceive event notifications based on event notification rules. Push notifications are instantly and actively transferred (pushed) to subscribers. A project member is subscribed to all events and is always notified when changes are made to events based on that rule. Pull notifications are optionally sent. A project member may choose to subscribe to a notifications on an event-by-event basis Escalation triggers Escalation conditions Escalation actions Subscribers Administering Event Escalation Rules Understanding Event Escalation Triggers Administering Event Escalation Actions Escalation schedules Notification methods Event reassignment actions Administering Event Escalation Schedules Administering Event Reassignment Actions 6.4 Administering Event Notification and Escalation Conditions In DevTrack, event notification is the process by which stakeholders are notified (by , pager, or mobile phone) whenever a specific change such as the creation or deletion is made to a development event. All event notifications are based on administrator-defined event notification rules. An event notification rule is defined by anotification trigger, one or morenotification actions, and one or moresubscribers. The scope of an event notification rule may be defined by anotification condition. Using controls in the Add Notification Rule manager and the Properties tab of the Event Notifications page, project administrators may define and update many notification rule properties. Notification Trigger:A notification trigger identifies the event management task that triggers a notification action. Notification Condition:A notification condition limits the limit the scope of the trigger to a subset of events based on an administrator-defined query. Notification Action:A notification action defines the notification message and the notification method ( , pager, mobile phone). Subscribers 6.5 Administering Event Notification and Escalation Actions Event notification is an optional DevTrack feature that must be enabled on a project-by-project basis. To enable event notification select the Enable Auto Notification check box in the Event Notifications page of the Event Notification subfolder in the Advanced Settings folder Identifying Notification Action Addresses Defining Event Notifications Defining Customer Notifications

150 6.5.4 Defining Pager and Mobile Phone Notifications 6.6 Administering Potential Recipients and Subscriptions An event notification rule identifies which project team members are notified whenever a specific change is made to a development event. An event notification rule is defined by anotification trigger, one or more notification actions, andnotification subscription rules. Optional event notification conditions limit the scope of the rule to a subset of development events Any number of notification rules may be defined in a project. To define an event notification rule: 1Select Advanced Features > Notifications/Escalations > Event Notifications. 2Click the New button. The Add Notification Rule dialog box appears. 3Provide a name and description for the event notification rule. A unique name and note that describe the logic of the event notification rule enables project administrators to save time when they review or update event notifications. Notification trigger 4Select a trigger in the Trigger dropdown list. The Trigger dropdown list displays six system triggers and all administrator-defined status change and field change triggers.every event notification rule is defined by a single notification trigger. Notification conditions 5 Optional: To limit the scope of a notification rule, select an event notification condition in the Condition dropdown list. The Condition dropdown list displays all administrator-defined conditions. Custom notification conditions may be defined in the Notification & Escalation Conditions window. For step-by-step instructions see Administering Event Notification and Escalation Conditions. Applicable event templates 6Select one or more event templates in the Applicable Regular or Co-Owner Event Template list. The scope of the event notification rule is restricted to development events based on the selected regular and co-owner event templates. 7Click the OK button. The Add Notification dialog box closes and the event notification rule is displayed in the Notification Rules list. Notification actions 8Define one or more notification actions in the Actions tab. A notification action is defined by anotification method( , pager, or mobile phone) and anotification message. To define an notification action, select the Notify By Sending option and select appropriateinternal(project team member) andexternal (customer) messages. To define a pager notification action, select the Notify By Pager option and select an appropriate message. To define a mobile phone notification action, select the Notify By Mobile Phone option and select an appropriate message. Custom notification messages may be defined in the Define window. For step-by-step instructions see Select the Yes or No option in the Option dropdown list.. Potential recipients 9Define potential recipients in the Potential Recipient tab. A potential recipient is a project team member whomay subscribeto an event notification rule. A project team member may be identified as a potential recipient based on their account type, team group, or potential recipient variable. Potential recipient subscription rules 10Define subscription rules in the Subscription Option tab. Potential recipient subscription rules define whether a potential recipient can,cannot, or must subscribe to an event notification. Subscription rules may be defined for each account type, team group, or user account and affect only those project team members that have been designated as potential recipients of event notifications. Subscribers 11Define subscriptions in the Potential Recipient tab. Event notification subscriptions define which project team members are subscribed and which project team members are not subscribed to each event notification rule.event notification rules are specifically defined for each user account and override all potential recipient subscription rules. To rename an event notification rule:

151 To rename an event notification rule, select the rule in the Notification Rules list and click the Rename button. The name of the rule may be changed in the dialog box. To delete an event notification rule: To delete an event notification rule, select the rule in the Notification Rules list and click the Delete button Identifying Potential Recipients of Notification Actions Potential recipient variables Customers as potential recipients Defining the Scope of Potential Recipient Variables Chapter 7 Beta Customer Portal Administration 7.1 Managing the DevTrack Beta Customer Portal Project administrators may use tools in the Beta Customer Portal folder of the DevTrack Tree window to associate a customer base project with a DevTrack project, customize the Customer Manager, and manage the DevTrack Beta Customer Portal. TheBeta Customer Portalenables customers and customer contacts to submit and edit DevTrack issues through the Internet. TheCustomer Managerenables DevTrack project members to create customers and customer contacts. Customer and contact information is stored in a customer base project. Each customer is assigned an administrator-defined customer type. Each contact is assigned an administrator-defined contact type. Acustomer base projectenables project teams to share a common database of customers and customer contacts. Each DevTrack project may be associated with one customer base project. Project administrators may use tools in DevSuite Admin to perform the following tasks: Identify the customer base project associated with a DevTrack project. DevTrack uses a customer base project to manage customer data. Customize the graphical user interface of the Customer Manager. Assign Customer Manager privileges to DevTrack project account types. Define customer types and contact types that Define privileges for each customer type Define page-level and field-level access controls. The ability of customers and customer contacts to access to the DevTrack project through the Beta Customer Portal is regulated by administrator-defined customer accounts and contact accounts. The Beta Customer Portal enables user-defined customers and customer contacts to submit, view, and edit DevTrack issues through the Internet. All customers and customer contacts are created and managed by DevTrack project members in the Customer Manager in a DevTrack client. Administrators may customize the graphical user interface (GUI) of the Customer Manager, define customer types and contact types, assign access privileges to those customer types and contact types, and perform other administrative tasks using tools in the Customer Web Portal folder of the Admin Tree window. Once the administrator configures and customizes the Beta Customer Portal, project members may create and manage customers and customer contacts using the Customer Manager in the DevTrack Windows client Understanding the Beta Customer Portal Understanding Beta Customer Portal Security Understanding the Customer Manager 7.2 Managing Customer Base Projects The DevTrackBeta Customer Portalis a secure, interactive Web site through which selected customer contacts may access customer-specific issues related to development processes. Customer contacts may use the Beta Customer Portal to create, edit, and delete DevTrack issues through the Internet. Typically, those contacts that are granted access to the Beta Customer Portal represent abeta groupthat is assisting the development team in the development and QA processes. Eachbeta customer(company) may access to one or more development projects, depending on their customer type. Each contact is generally an employee of a customer and may perform various issue management tasks within the Beta Customer Portal depending on their contact type Understanding Customer Base Projects

152 7.2.2 Understanding the Customer Base Settings Page Associating Custom Base Projects with DevTrack Projects Creating New Customer Base Projects Defining Beta Customer Portal Login Settings Defining Parent-Child Relationship Support Defining Default Subprojects for Customer Base Projects 7.3 Customizing the Address Page of the Customer Manager Beta Customer Portal security is managed using two administrator-definedaccounts: the customer type and the contact types. Project members may use these administrator-defined accounts to define which projects, pages, and fields customer contacts may access through the Beta Customer Portal. Using the Customer Manager in a DevTrack client, project members may create customers and customer contacts and assign each customer a customer type and each contact a contact type. Each customer (a company) created in the Customer Manager may include any number of customer contacts (employees). A customer type determines which DevTrack projects a customer may access through Beta Customer Portal. Every customer is assigned a customer type and inherits all of the privileges assigned to that customer type. Administrators define customer types in the Address page of DevTrack Admin. A contact type determines whether a customer contact may create, edit, delete DevTrack issues in the Beta Customer Portal. Every contact is assigned a contact type and inherits all of the privileges assigned to that contact type. Contact types are, therefore, similar to the account types used to manage projectlevel privileges within the internal development team. Contact types are set up with defined privileges, and contacts are assigned contact types that best represent their responsibilities in the development process. Administrators may use page-level and field-level access rules to add an additional layer of security within the Beta Customer Portal. Administrators may restrict the ability of Beta Customer Portal user to view or edit pages or fields when they create or update DevTrack issues based on their contact type or on the customer type assigned to their employer. Administrators may define page-level and field-level access in the Page and Field Access page. For more information see Managing Beta Customer Portal Page and Field Access on page 100. Project members may use the Customer Manager in the DevTrack client to define customers and customer contacts and to assign administrator-defined customer types to their customers and contact types the contacts Customizing the Address Page Defining Customer Types Defining Project Linking Options Customizing the Customer ID Control 7.4 Customizing Contact Info in the Customer Manager DevTrack project members may use the Customer Manager to manage customers and customer contacts and the links between customers and DevTrack issues. Although the administrator defines customer types and contact types in DevTrack Admin, the customers and customer contacts for each project are managed by project members in the DevTrack Windows client. The Customer Manager consists of the Customer list and four Customer Detail tabs.

153 Figure 7-1: Customer Manager in the DevTrack Windows Client TheCustomer list windowdisplays high-level information about every customer defined in the DevTrack project including their name and their customer type. Project members may filter the Customer List window based on whether a customer is linked to the current project. TheCustomer Detail windowconsists of four tabs. Each tab in the Customer Detail window enables project members to manage a customer account. TheCustomer Info pageenables project members to define basic information about a customer. Administrators may customize the Customer Info page using controls in DevTrack Admin. For more information see Customizing the Address Page of the Customer Manager. TheContact pageenables project members to view high-level information about customer contacts. Controls in this tab enable project members to create, edit, and delete customer contacts. Administrators may customize the Add a New Contact page that project members use to create new contacts. For more information see Customizing Contact Info in the Customer Manager. TheParent-Child Relation pageenables project members to define which options are displayed in a child multiple-selection list control when the parent multiple- selection list control displays customer type or customer options. For more information see Defining Parent-Child Relationship Support. TheRelated Issues pageenables project members to view issues submitted by a customer Customizing the Contact Info Page Defining Contact Access Types Defining Access Type Privileges Defining Project Access Controls 7.5 Managing DevTrack Customer Manager Privileges Administrators may use the Customer Base Settings page to associate a DevTrack project with a customer base project, create or manage customer base projects, and define general general settings that enable customer contacts to access the Beta Customer Portal. DevTrack project members may use acustomer base projectto manage all customer-related data including the names, numbers, and addresses of customer contacts. Project members may manage customer data using the Customer Manager in the DevTrack client. Customer base project management tasks include: Understanding Customer Base Projects Understanding the Customer Base Settings Page Associating Custom Base Projects with DevTrack Projects Defining Parent-Child Relationship Support Defining Default Subprojects for Customer Base Projects Creating New Customer Base Projects Understanding Customer Manager Privileges Defining Account Type Privileges Chapter 8 Interproject Actions and Linking Admini

154 8.1 Administering Interproject Actions and Linking Interproject actions and linking provide development organizations with greater flexibility and power to manage development issues across multiple projects so that they may close gap between their development processes and other business processes. An interproject action is a manual, automated, or semi-automated procedure by which a development issue is copied, cloned, or submitted to an integrated DevTrack, ServiceWise, or CustomerWise project. Optional interproject linking associates the development issues in one project with another issue (or incident) in another project. Issues may be automatically linked whenever an issue is copied in one project and submitted to another project. DevTrack enables development organizations to define and manage two levels of interproject actions: standard interproject actions and advanced interproject actions. Standard Interproject Actions:Standard interproject actions enable development organizations to submit and copy issues from one project to another project, create links between issues in different projects, and define workflow rules that tie the workflow state of linked issues in different projects. All standard interproject settings are defined in the Advanced Features folder in the DevSuite Admin client. EnterpriseEdition Actions:EnterpriseEdition interproject actions enable administrators to define system and custom interproject actions to streamline workflow and define best practices for submitting or copying issues between projects. DevTrack Enterprise Edition interproject actions build upon standard interproject action settings. Interproject actions and linking provide development organizations with the following benefits: Interproject issue submission: Project members may submit new issues to a target DevTrack, TechExcel CustomerWise, or TechExcel ServiceWise project from within a DevTrack project. Interproject issue copying: Project members may copy issues in a DevTrack project and submit those issues to a target project. Interproject linking: Project members may create referential or parent-child links between issues submitted or copied to a target project and issues in the originating DevTrack project. Tracking and editing linked issues: Interproject links may enable project members to view, edit, and manage the linked issues from with the DevTrack client. Interproject automation rules: The issue workflow state of an issue may drive changes in the issue workflow state a linked issue based on administratordefined state automation triggers. 8.2 Administering Standard Interproject Actions and Linking In DevTrack, standard interproject actions and linking enables development teams to submit, copy, and link issues across development projects. Distinct interproject integration rules may be defined for each development project in a DevSuite site. To enable standard interproject actions, an administrator must define one or more projects as applicable target projects, enable interproject actions, enable interproject linking, define applicable link types for target projects, map fields between issues in different projects, and define appropriate workflow automation rules. A target project is a DevTrack project, TechExcel ServiceWise project, or TechExcel. CustomerWise project that has been identified and enabled to receive new issue submissions through interproject actions. All interproject action settings are defined at the project-level and apply to all enabled interproject actions Enabling Project-to-Project Integration Enabling Standard Interproject Action Support Enabling Interproject Link Support Defining Interproject Standard Action Settings Defining Interproject Editing Rules Defining Interproject Field and Field Value Mapping Defining Issue History for Linked Issues Defining Standard Interproject State Automation Rules Defining Interproject State Automation Rule Conditions 8.3 Administering System Interproject Actions In DevTrack, a DevTrack development project may be integrated with multiple TechExcel DevTrack, ServiceWise, and CustomerWise projects. All standard interproject integration rules (actions and linking) between the current DevTrack project and another defined on a project-by-project basis. Distinct interproject workflow rules may be defined for each integration. Enabling project-to-project integration merely allows the administrator to enable support for standard actions and linking. All standard interproject settings must be enabled and defined on a project-by-project basis.

155 Using controls in the Interproject Setting page, project administrators may enable the current DevTrack project to be enabled by one or more DevTrack, ServiceWise, or CustomerWise projects. To enable integration with another project: 1Select Advanced Features > Interproject Setting. 2Select a target project in the Project List. Standard interproject integration settings may be defined for a project if a red check mark is displayed next to a project Defining Clone System Interproject Actions Defining Submit System Interproject Actions Defining Copy System Interproject Actions 8.4 Administering Custom Interproject Actions All standard interproject integration rules (actions and linking) between the current DevTrack project and another defined on a project-by-project basis. Distinct interproject workflow rules may be defined for each integration. The Submit/Copy check box must be selected for project members to submit or copy issues from the DevTrack project to the target project. To enable interproject actions between two projects: 1Select Advanced Features > Interproject Settings of the tree panel. 2Select an enabled target project in the Project list. 3Select the Interproject Submit/Copy check box Adding, Editing, and Deleting Custom Interproject Actions Defining Custom Interproject Actions Defining Custom Interproject Action Access Controls Defining Custom Interproject Action Applicable States 8.5 Administering Custom Interproject Action Automations All standard interproject integration rules (actions and linking) between the current DevTrack project and another defined on a project-by-project basis. Distinct interproject workflow rules may be defined for each integration. The Link check box must be selected for project members to submit or copy issues from the DevTrack project to the target project. To enable interproject linking between two projects: 1Select Advanced Features > Interproject Settings of the tree panel. 2Select an enabled target project in the Project list. 3Select the Interproject Link check box Enabling Interproject Action Automation in Transition-Based Projects Enabling Interproject Action Automation in State-Based Projects Defining State-Dependent Interproject Automation Rules Defining Transition-Dependent Interproject Automation Rules Defining Interproject Action Automation Rule Conditions Chapter 9 Product, Version, and Build Administrat 9.1 Understanding Product Version Tree Administration

156 In DevSuite, the product tree is a hierarchical structure that provides a business with a framework for organizing the products, versions, and builds under development in every project within the DevSuite site. The product tree organizes products, versions, and builds into a hierarchical tree structure composed of multiple folders and subfolders. In a DevTrack development project, the product tree defines the framework in which development issues and branch issues are managed in the project. Each subproject in a DevTrack project is defined as a release folder and linked to a specific product, version, or build. To use the product, version, and build structures, the project administrator must identify which products, versions, and builds in the product tree are applicable to their DevTrack project. Only those release folders that have been defined as applicable may be utilized in the DevTrack project. Once a product, version, or build has been defined as applicable to a DevTrack project, project members may create subproject folders in the DevTrack client to represent each of those releases. 9.2 Administering Milestone Date Types A milestone is a point in time that represents an important intermediate event in a project. Milestones commonly represent the completion of key components, reporting requirements, and the beginning or end of project phases. All version releases may represent one or more milestones. Typical milestones that a product administrator may want to create include: Alpha date Beta date Release date Code Freeze date Preproduction date Feature Freeze date In DevTrack, every milestone is based on a milestone date type. A milestone date type is an administrator-defined template for creating appropriate milestones in a DevTrack site. All milestone date types are defined and managed in the product tree. Note:The creation and management of milestones is particularly important to organizations that are using DevPlan to manage development planning. System administrators may create, edit, and delete milestone date types in Milestone Date Type manager. Figure 9-1: Milestone Date Type Manager Adding Milestone Date Types Editing Milestone Date Types Deleting Milestone Date Types 9.3 Administering the Product Tree To add milestone date types: 1Select the Define Milestone Date Type command in the Tool menu of the DevSuite Admin client. The Milestone Date Type manager appears.

157 2Click the Add button. The Add Milestone Date Type dialog box appears. 3Define a unique name for the milestone date type in the Milestone Date Type Name control. 4Click the OK button Administering Product, Version, and Build Release Cycles Release status 9.4 Administering Applicable Products, Versions, and Builds To edit milestone date types: 1Select the Define Milestone Date Type command in the Tool menu of the DevSuite Admin client. The Milestone Date Type manager appears. 2Select a milestone date type in the Milestone list. 3Click the Edit button. The Edit Milestone Date Type dialog box appears. 4Update the name of the milestone date type in the Milestone Date Type Name control. 5Click the OK button. 9.5 Administering Product Categories To edit milestone date types: 1Select the Define Milestone Date Type command in the Tool menu of the DevSuite Admin client. The Milestone Date Type manager appears. 2Select a milestone date type in the Milestone list. 3Click the Delete button. A DevSuite Admin dialog box appears. 4Click the Yes button. 9.6 Administering Products The product tree is a hierarchical tree structure that represents the product categories, products, versions, and builds under development in a DevSuite site. The product tree is sometimes referred to as the global product tree because the products, versions, and builds defined and managed in it are available to every KnowledgeWise, DevSpec, and DevTrack project in the site. Product tree administration is a system-level administrative task that is generally defined by a system administrator in the system settings project. Once defined, the product tree may be used by every TechExcel KnowledgeWise, DevSpec, and DevTrack project in a DevSuite site. System administrators must define a product, version, or build in the product tree before the product, version, or build represented by that release can be managed in a DevTrack project. Product Category:A product category is any grouping of products, such as a product line, that a business uses to organize its products. Product:A product represents a product in development in DevTrack. Each product may be the parent of many different versions. Version:A version represents a version of a product. Each version is the child of a product and may be the parent to one or more builds. Build:A build represents a specific build of a product version. Each build is the child of a single version. Project administrators may create, edit, and delete product categories, products, versions, and builds in the Define Product/Version/Build Tree manager.

158 Figure 9-2: Define Product/Version/Build Tree Manager To define products, versions, and builds in the product tree, a system administrator must first define appropriate product release statuses, version release statuses, and build release statuses. To define versions in the product tree, a system administrator must first define appropriate milestone date types that may be used to define versions Defining Products Defining the Product Release Lifecycle 9.7 Administering Versions In DevSuite, the development of products, versions, and builds are defined by a unique lifecycle consisting of multiplerelease states.a release state is an administrator-defined workflow state that identifies the progress of that release within its development life cycle. Administrator-defined workflow rules determine how a release item (product, version, or build) may be managed within each release state in its lifecycle. The privileges available to project administrators and project members in each release depend on the release type. Table 9-1: Definable Open Release Statuses Managing Version Milestones Deleting Versions Managing the Version Release Lifecycle 9.8 Administering Builds Every release state is defined by its release status open or closed. Products, versions, and builds in open states (that is, release states with an open release status) are managed in workflow based on administrator-defined rules. Records in closed states must be reopened to be managed in release management workflow. Open Release Status:An open release status indicates that the product, version, or build is currently under development. Changes may be made to releases with an open release status. Closed Release Status:An closed release status indicates that the product, version, or build is currently not under development. The product, version, or build may be completed or may still be in the future. Changes may not be made to releases with a closed release status. Open project are definable, and the system administrator may enable certain privileges (at either administrative or client level) and restrict others. Closed releases cannot be changed at either level Defining Builds Managing Build Release Lifecycle 9.9 Administering Product Implementation Modules

159 In DevSuite, the product tree identifies the products, product versions, and builds under development site and provides a common framework for organizing and managing the development of products, versions, and builds. Product tree structures define the framework for DevSuite knowledge management structures, DevTrack/DevPlan subprojects, and DevTrack branch management. To use the product, version, and build structures, the project administrator must identify which products, versions, and builds in the product tree are applicable to their DevTrack project. Only those release folders that have been defined as applicable may be utilized in the DevTrack project. To select applicable products, versions, and builds: 1Select Product Settings > Applicable Product/Version in the tree panel. 2Click the Select button. The Select Product dialog box appears. The Product Tree displays the product categories, products, versions, and builds that have been defined in site. 3Select all applicable products, versions, and builds. The products, versions, and builds selected in the product tree may define DevTrack subproject structures. 4Click the OK button. Chapter 10 Subproject Administration 10.1 Understanding DevSuite Subprojects In DevSuite, a subproject is a tool for organizing development issues into smaller, more manageable groupings of issues. Development teams may create subproject folders with subproject folders to organize their work and define subproject statuses, prioritize subprojects, and set due dates for all subprojects. Each subproject has its own description, priority, status, and start and end dates. Every work project represents a distinct area of work and is defined by unique team structures (account types, team groups, and group folders) and workflow rules. Subprojects provide developers the means to organize, schedule, prioritize, and track groups of issues and to implement an additional layer of security within the project. Subprojects are ideal for development organizations that wish to develop multiple products within a single DevTrack project. Subprojects are also useful to organizations developing products made up of multiple components or modules, or who wish to track many different types of issues in a single DevTrack project Understanding the Subproject Tree Structure Understanding Subprojects and the Beta Customer Portal 10.2 Administering Subproject Settings The subproject hierarchy is displayed in both the DevTrack Windows and Web client and the DevPlan smart client providing development organizations with a common framework for managing, tracking, and scheduling tasks. In DevTrack, the subproject hierarchy is displayed in the issue tree panel and organizes development issues by product, version, and build. Figure 10-1: Subproject Enabled Client GUI In DevPlan, the subproject hierarchy is displayed in the issue tree panel and organizes development issues by product, version, and build.

160 Figure 10-2: Subproject Enabled Client GUI Subprojects serve three primary purposes in DevTrack projects: Subprojects facilitate the management of multiple development projects within a single DevTrack project. Subprojects enable development teams to define rules for managing issues within a subproject. Subprojects enable development teams to use multiple workflow to manage project issues. Note:If TechExcel DevPlan integration is enabled for a DevTrack project, all subproject management tasks are performed in the DevPlan smart client. Project team members may create and manage subprojects in the DevTrack client only if DevPlan integration is not enabled. In DevTrack Admin, project administrators may define rules for defining the status and priority of subprojects, and account type access privileges, which determine which project members may create, edit, and delete subprojects within the DevTrack project. The status of a subproject enables project members to indicate the current progress state of a subproject. The status of a subproject may be defined independently or be linked to the progress state of the issues in the subproject. The priority of a subproject enables project members to indicate the current priority of a subproject relative to other subprojects. All subproject properties may be defined in the Subproject manager within the DevTrack client. Administrators may use tools in the Subprojects subfolder to enable subprojects, define subproject statuses, subproject priorities, and subproject access privileges Enabling Subproject Support Defining Subproject Terminology Defining Default Subprojects Defining Applicable Issue Types 10.3 Administering Subproject Statuses Projects that are using the Beta Customer Portal may wish to route all issues submitted from beta customers through the Beta Customer Portal to a subproject. Project administrators may define a default subproject for every customer created in a customer base project. All issues submitted by that customer are submitted to a DevTrack project would by default be created in the selected subproject Defining Independent Subproject Statuses Defining Subproject Status Based on Highest Ranking Defining Subproject Status Based on Lowest Ranking Defining Subproject Status Based on Issue Status 10.4 Administering Subproject Priorities In DevSuite, a subproject is a discreet area of work that corresponds to a specific product, feature, version, or build. Using subprojects, development teams may divide a DevTrack project into smaller, more manageable groupings of issues. Project members may schedule, prioritize, and track those issues using subproject properties and, optionally, subproject workflow. Using controls in the General Settings page, project administrators may enable subproject support in a DevTrack project and to enable team member access controls, applicable issue owners, and applicable issue statuses in subprojects. Project administrators must enable support for subprojects in each DevTrack project. If subproject support is not enabled no subproject settings can be

161 implemented within the project and the issue tree panel does not appear in the DevTrack Windows client Creating Independent Subproject Priorities Defining Highest Subproject Priorities Defining Lowest Subproject Priorities Defining Linked to Issue Subproject Priorities Chapter 11 Branch Management Administration 11.1 Understanding Multiple Branch Management DevTrack multiple branch management enables development organizations to ensure that features and bug fixes managed and tracked as development issues are correctly implemented across product versions and builds. Branch issues are the means by which developers may confirm that development tasks are completed in all multiple branches of development. A branch issue is a copy of a development issue that has been copied to a different branch version or build of development. Although branch issues inherit basic issue properties from its parent issue, it may be managed within a distinct workflow. Figure 11-1: Development Issues and Branch Issues Using branch issues, development teams to create multiple issues and may independently manage and track those issues in different versions and builds of a product in development. Every branch issue may, in turn, be the parent of multiple branch events. Branch issues are automatically linked to their parent development issue is based on an administrator-definedbranch link types.a branch link type defines the relationship between the parent development issue and its children and controls the issue lifecycle by means of closetime enforcement rules. DevTrack multiple branch management is build upon subproject hierarchy of products, versions, and builds that organize and schedule development tasks within a project. Every release of a product, version, or build that is managed in a DevTrack project may be associated with a subproject folder in the DevTrack client. The subproject folder represents that release and is used to organize and manage the development issues and branch issues related to that release. Branch issues enable development teams to create multiple identical issues that may be tested against many different versions or builds of a product Administering Branch Issues In DevTrack, development organizations may manage and track development tasks across multiple releases asbranch issues. A branch issue is a copy of a development issue that has been submitted to a different branch version or build of development. Although branch issues inherit basic issue properties from its parent issue, it may be managed within a distinct workflow. Each branch issue is linked to its parent development issue by abranch linkenabling developers to manage and track the issues together so that they may ensure that changes to code are properly implemented across all branches of development.

162 Figure 11-2: Development Issues and Branch Issues Branch issue administration is the process of enabling multiple branch management support in a DevTrack development project and creating one or more branch issue types. An issue type is a blueprint for creating issues that are governed within a distinct workflow. The branch issue type does not define issue property values, rather it defines how that issue is managed and tracked in the project. Every branch issue type is defined by its lifecycle (a subworkflow) and a set of read-only fields Enabling Branch Management Defining Branch Issue Types Adding, Editing, and Deleting Branch Issue Types Defining Default Branch Issue Types 11.3 Administering Branch Link Types Multiple branch management is an optional DevTrack Enterprise Edition feature that must be enabled in each DevTrack project. To enable branch management: 1Select Enterprise Edition Features > Multi-Branch Development > General Settings in the tree panel. 2Select the Enable Multi-Branch Development check box Adding, Editing, and Deleting Branch Link Types Defining Branch Link Type Properties 11.4 Administering Branch Actions In DevTrack, every branch issue is based on a branch issue type. The branch issue type defines the workflow rules by which the branch issues based on the branch issue type are managed in the project. Branch issues in themselves are not defined by any properties, but inherit issue property definitions from a parent development issue. To define a branch issue type: 1Select Enterprise Edition Features > Issue Type in the tree panel. 2Select a branch issue type in the Issue Types list. The Issue Types list displays the all of the administrator-defined development and branch issue types available in the project. 3Select workflow in the Assigned Workflow dropdown list. The Assigned Workflow dropdown list displays the system-defined {Master Workflow} and all administrator-defined subworkflows available in the project. 4 Optional: To define an issue property field as read-only in child issues based on this issue type, select the issue property field in the Edit Fields list and press the Right Arrow button Adding, Editing, and Deleting Branch Actions Defining Branch Actions

163 Defining Branch Action Privileges Defining Branch Applicable States Chapter 12 Branch Event Administration 12.1 Understanding Branch Events In DevTrack, a branch event is a subtask of a branch issue. Branch events enable organizations to divide a development task into many different subtasks, assign each of those subtasks to a different project member, define separate start and due dates for each subtask, and manage and track each of those tasks independently in its own workflow. Every branch issues the child of a parent development issue. Branch issues may, turn be the parent to multiple branch events. Figure 12-1: Development Issues and Branch Issues Using branch events, development teams may quickly create multiple events that are identical with one another except for one or two event properties: the event owner. All development events are based on administrator-defined branch event templates. A branch event template is a set of rules for managing events in project workflow. The life cycle of a branch event and the rules that determine how that event is managed in workflow are defined by the event template that was used to create it. branch event administration, therefore, is the largely a matter of creating branch event templates, defining the rules that manage events based on that template, and determining when events based on that event template may be created in the project. Using controls in the Branch Events folder, project administrators may define branch event templates, branch event workflow and workflow rules, advanced branch event workflow rules, branch event notification rules, and branch event escalation rules Enabling Branch Events Enabling In-frame Editing of Branch Events Defining Branch Event Templates Adding, Editing, and Deleting Branch Event Templates Defining Branch Event Template Attachment Rules Defining Branch Event Workflow States Managing Branch Event Access Rules Administering Branch Event Workflow Defining Branch Event Automatic Close Workflow Rules

164 12.2 Administering Advanced Branch Event Workflow To enable branch event support: 1Select Enterprise Edition Features > Multi Branch Development Management > Branch Events > General Settings in the tree panel. 2Select the Branch Event Support check box Disabling In-frame Editing Defining branch event Advanced Workflow Rules DevTest Projects Administration Chapter 1 DevTest Concepts 1.1 Understanding DevTest Test Management Product testing is more complicated, labor-intensive, and time-consuming than ever before. Businesses are demanding greater openness, transparency, and scalability from their software investments?hey looking for versatile solutions that enable them connect users and resources worldwide while leveraging their existing investments. As a result, contemporary business applications run on many different platforms and in many different environments, support integration with emerging technologies and legacy systems, and feature add-on modules that support every imaginable business process. All this versatility has multiplied the number of variables that may affect the performance application making the task of testing software more complicated and time-consuming than over before. But the same forces that drive the demand for these applications also require that these products be delivered to market as quickly as possible?i>if not sooner. QA organizations are under increasing pressure to complete their testing in ever-shorter time frames. And, as if this were not enough, these challenges are compounded by hectic development schedules that introduce problems all their own?ew features may suddenly appear or disappear, the design and functionality of product features often change to meet the demands of the marketplace or to accommodate tight schedules. To meet these challenges, QA organizations are pursuing several different strategies?eginning their test planning earlier in the development life cycle, leveraging the results of previous test efforts, improving the management of testing data, and reusing existing test coverage. And increasingly, many testing organizations are abandoning outmoded paper-based systems and turning to software test management solutions to organize, plan, and analyze their testing efforts. 1.2 Understanding Test Management In the past, testing organizations could rely onpaper-based solutionsto plan, design, manage, and track their testing projects. Older technologies did not require the same degree of planning and organization as do contemporary software suites?hey lacked the portability, the versatility, and extensibility. But even with simple applications, paper-based systems aremerely adequate. The lack of organization, poor planning, and inefficient communication that are inherit in paperbased systems regularly jeopardize delivery schedules and, ultimately, jeopardize the quality of the product itself. In a paper-based system all testing activities are recorded and tracked in static lists, tables, outlines, and matrices created in word processing documents or spreadsheets. Paper-based solutions are difficult to maintain, update, and track. As a result, testing strategies are necessarily straight forward and limited, because testing teams are straitjacketed from the very start of the process. Poor or inaccessible documentation and inadequate channels for communication make it difficult for QA organizations to adjust to sudden changes in product design. Test plans are frequently based on out-dated requirements documents, and this can lead to test cases that do not adequately test product features and functionality. Understandably, test planning is frequently left to late in the development life cycle when the product approaches some kind of stasis. But delaying test planning creates a whole new set of hurdles. Time pressures mean that QA organizations must focus on testing the application at hand and have little time to plan ahead for future release cycles. Hastily created test cases are generally not reusable. Test planning efficiency can be improved when the test planners can base future test assignments on previous results and an analysis or test or defect data. But tight schedules mean their is little time for reflection or future planning. And even if there were time, traditional models make it difficult to review previous test data or defect data because it is often inaccessible?ost or misplaced in a stack of paper, buried in someone? inbox, or stored away somewhere in different files or applications. Why test management? Because test management solutions enable businesses to work more intelligently and efficiently. Test management solutions provide following benefits: Manage knowledge and facilitate communication:a test management solution provides testers with a centralized and secure tool through which they may review control documents and research previously reported bugs. Knowledge collected by the testing group is accessible to all project members at all times. Enforce the standardization of test cases: A test management solution enables the testing group to define the data they wish to track and to design a standard interface for collecting and tracking that data. Standards increase efficiency. Promote the creation of reusable test cases: A test management solution makes it easy for testing groups to save, manage, and reuse their most effective test cases. Leverage previous results in test planning: A test management solution enables testing groups to plan future test assignments based on the analysis previous test results. Instant access to summary reports enables test planner to improve test efficiency. Respond to issues quicker:a test management solution provides real-time access to all testing data so that testing groups can immediately respond to critical test blockers or and other issues. The faster the team is able to address the critical issues the sooner the test team may resume their testing. Make information accessible: A test management solution provides a test planners with a complete picture of their testing project so that they better manage their project and

165 they can make the necessary adjustments to meet testing objectives and deadlines. 1.3 Knowledge Management One key factor to meeting the demands of contemporary software development is to ensure that all project stakeholders, management, developers, and testers have access to the most up-to-date control documents and may effectively communicate with others both within and outside their organizations and teams.in short, everyone must beon the same pageat all times. To address this issue, TechExcel DevTest takes a knowledge-centric approach to test management that places the collection, management, and distribution of information at the core of all development and quality assurance processes. Knowledge management enables all stakeholders to access, manage, and share information so that QA may make informed decisions throughout the testing process, leverage the information collected and generated by development, and learn from their past successes and failures so that they may implement more efficient and intelligent processes. Key components of the DevTest approach to knowledge management include a centralized knowledge base, instant access to quality reports, and tools for communicating information relevant to individual test cases and the project as a whole. Managing Project Knowledge In DevTest, all testers may access a centralized repository of information from within the DevTest client. The DevTest knowledge view, powered by TechExcel KnowledgeWise, provides development and QA organizations with a tool for collecting and organizing the ideas that drive product development and testing. All ideas, both formal and informal are collected and managed in the same, centralized knowledge base. TechExcel KnowledgeWise is a key component in the TechExcel DevSuite of application life cycle management products. KnowledgeWise provides project managers, designers, developers, testing groups, and sales and marketing departments with a secure repository for all project documents?he project plan, business requirements, functional and technical specifications, risk management documents, and corporate standards and guidelines may be managed in one knowledge base that is shared by the entire business. - A centralized knowledge base increases efficiency, prevents the loss of information, helps to reduce system and maintenance costs, and facilitates collaboration by distributed teams. - Access to knowledge items is protected by privilege-based access controls. The ability of project members to view, edit, lock, check out, and check in protected files is defined by their role in the project. - Built-in version control tools ensure that all project development and testing teams (no matter where they are in world) always have access to the most up-to-date documents. Leveraging Control Documents A common knowledge base ensures that the QA organization always has access to the latest project control documents?usiness requirements, functional and technical specifications?and enables them to leverage this information to plan and organize their test plans early in the development processes. In DevTest, QA organizations may access project control documents as soon as those documents are uploaded to the knowledge base?t the same time they are available to the developers themselves. Access enables the QA organization to jump-start test planning and develop testing strategies and test cases in parallel with the implementation of the designs. Using these control documents, testing groups may estimate the scope of the project, allocate resources, and plan appropriate strategies for testing the functionality and performance of those features. Testing groups need not wait forallof the control documents to be approved before they begin their test planning. They can create test cases and build test planning structures in a piecemeal fashion as thedesigned productis realized in the knowledge base. With each new control document that is added to the knowledge base they can create appropriate test cases. Ideally, project control documents are complete and approved at the beginning of the test planning stage. However, the specifications and designs that are approved at the beginning of the development process may be sketchy, inadequate, or change significantly over time due to changes in the marketplace, technical problems, or time constraints. DevTest provides testing groups with the flexibility they need to adjust to changes in design or schedule. QA organizations may take anevolutionaryapproach to test planning. By organizing their test cases by product features, they can readily adjust to changes in product design or changes to the schedule. They may create appropriate structures and test cases as the requirements and specifications are completed and update the list to accommodate changes to the application. DevTest planning structures and test cases may be easily edited and updated so that QA organizations need not pay the penalty for changes in design. Facilitating Task-level Communication By placing knowledge management at the core of all development processes, DevTest facilitates all project-level and task-level communication. Just as the centralized knowledge base ensures that all stakeholders have access to project information, the complete history of every test case and all background information is always right at hand. All communication is recorded and tracked with the test case so that test task itself is the vehicle for communication. Key information cannot be lost in exchanges or buried in user inboxes. Good notes from the prior testing enables test team members to pick up testing where others have left off. Any testing team member may pick up the work of another tester, and with a little research understand the test in its entirety. Every test case may be directly linked to supporting materials?est plans, business requirements, schedules, and so on?that enable testers to run successful tests. Testers may read all business requirements and specifications and compare product functionality against those control documents. 1.4 Test Planning and Organization Test planning begins with the identification and definition of product features in a feature list: a simple list of the visible functions, subfunctions, commands, menu choices, reports, and so on that need to be tested. Whereas a feature list begins as simple list of all of the product features that need to be tested, it is ultimately an outline of the testing project in which product features categorized and prioritized. In DevTest, the feature list is articulated as a hierarchical tree structure that both organizes test cases and represents the product to be tested. DevTest transforms the information that previously captured in static lists into a dynamic structure called atest librarythat helps testing groups to manage their testing project, improve team efficiency, and find bugs. Test Case Organization The TechExcel DevSuite of applications conceptualizes the product under development as afully designed product that is articulated, managed,and communicated in DevTest project structuresprior toits actual implementation?product features define the structure that is used to organize and manage the implementation and testing of those features. The DevTest test library is sometimes called the?unctional tree?because it organizes test cases by product functions. The tree structure enables the testing group to visualize the entire application and understand the relationship between every area under development. Every product feature may be represented by a unique branch and contain multiple subfolders representing feature subfunctions. Every dialog box, command, report, error message, menu option, and so on may be represented by a subfolder in the test library. The test library defines the scope of the project, shows the relationship between product features, and manages the test templates that will be used to test those features. The test template tree manages the test library: The template tree structure enables testing groups to manage test templates in a hierarchical tree structure. Test templates may be organized by product, functional area, test type, or any other categories that is useful to their business. The template tree defines project scope: The test template tree may represent the product being tested organized into functional areas and enables testing groups to better provide full test coverage of all product features. Organizing the test library by product, feature, and function shows every area under development. Project managers may use the test template tree to estimate the resources needed for the testing project. The test template tree helps test designers to create better tests:representing the product enables testing groups to visualize?he designed product?described in the control documents, analyze its design, and identify good tests for its feature. Understanding how the program features work together enables testers to develop test cases that are

166 more likely to find bugs and combine or eliminate redundant tests. The test template tree makes test templates accessible: A library of tests is only useful if the test cases are accessible. The template structure enables project teams to define hierarchical structures for organizing templates and making them accessible to users. The test template tree shows all areas of development.testing groups may ensure that every feature is properly tested and prioritize test coverage by module, component, or feature. The test template tree shows which functional areas have been tested and which areas have not so that testing groups can make sure that they don't do duplicate work. Test Case Definition and Standardization DevTest enables organizations to define custom test cases and enforce standardization throughtest templates. A test template is a blueprint for creating test cases that may be used to test product features and performance across multiple builds, platforms, and environments. Test templates are easily edited, copied, and duplicated. Changes in the design or functionality of a product feature can be easily accomodated. In DevTest, each test case is displayed in the client as a form through which testers may track and record test results. Test cases typically consist of a test procedure, the expected outcome of that procedure, the prerequisite state or steps for the test, and other information that the QA team may wish to track. DevTest features a fully customizable graphical user interface (GUI) that enables QA organizations to identify the data they wish to track and to standardize thelook-and-feelof test cases. QA organizations may add any number of custom fields to record and track testing data. Test templates enable testing organizations to control the distribution of test cases and to implement a standardizedlook-and-feelfor all test cases. Testing organizations may define their own approval process for all test templates that ensure that only those test template that have been approved may be used in test cycles. Test case standardization ensures that test results are consistent from one group or test cycle to the next and that the data collected from different tests may be compiled and compared. The format of test procedures, expected results, and data-entry controls is consistent across all test cases enabling testers of work more intuitively and efficiently. Test templates enable testing groups to preserve and recycle their most creative and successful tests?t makes no sense for these tests to be recreated from scratch with each new test cycle, or change in platform. Test Templates and Test Tasks As we have seen, the test template tree structure?hetest library?oth organizes test cases and articulates the product under development?hedesigned product?nd all its features. Once the QA organization has created a library of test cases for a specific product, both the tests and the structure used to manage those tests may be used and reused with each new release cycle. In DevTest, all test cases are represented astest templatesandtest tasks. The test library is a tool for organizing and managing reusabletest templatesthat may be used to create test cases that are applicable to many different platforms and environments. Using test templates and test tasks enables testing teams to define and manage standardized and reusable test cases (test templates)andto track the performance of program features against that test (test tasks) in many different environments.?a test template is a blueprint for creating test cases that may be used to test product features and performance across multiple builds, platforms, and environments.?test tasks, on the other hand, are theinstancesof a test template that are actually used to test a feature in a test cycle. Every test task inherits its properties from the test template that was used to create it. What makes this all possible areenvironmental variables. Test templates do not merely define test procedures and expected results, they also define the environments in which an application may be tested. An environmental variable represents the various environmental factors that may affect the performance of an application during a test cycle. Environmental factors include things like system platforms, hardware, network infrastructure, browsers types, and other factors. A single test template that includes one environmental variable may be used to generate multiple test tasks?one for each environmental variable value?or, if it includes many environmental variables?one test task for each permutation of environmental variable values. For example, the web browser environmental variable may represent three environmental variable values:internet Explorer,Firefox, andsafari. A test template that includes the web browser environmental variable may be used to generate three test tasks: ainternet Explorertest task, afirefoxtest task, and asafaritest task. 1.5 Scheduling and Assigning Testing DevTest simplifies the management, assignment, and scheduling of test cycles by organizing testing in distinctrelease cyclesandtest cycles. This two-tiered approach simplifies test management by leveraging the power of test templates and environmental variables to create test cycles for different environments and to provide instant access to summary statistics. In DevTest, all test planning?the definition of the scope and objectives?s managed in release cycles. A release cycle defines the scope and objectives of a group of test cycles? he test schedules, test templates, environments, and testing teams that are applicable to the test cycles within that release cycle. DevTest test planning is managed in theplanning tree, a hierarchical tree structure that represents products, releases, and test cycles as a series of folders and subfolders. Just as the test template tree organizes the test library (test templates) by functional areas of development, the planning tree organizes the test tasks based on those templates into products, releases, and test cycles. The DevTest two-tiered approach to test planning provides the following benefits: View the test plan:the planning tree structure defines and shows the relationships between products, releases, and test cycles. View test depth: The planning tree structure shows which functional areas have been tested and which areas have not so that testing groups may see which features have been tested and which areas have not been tested so that they can avoid unnecessary duplication of effort. Reports by release cycle: Testing groups may define and run reports that enable them to view the effectiveness of tests for every test cycle in a release cycle. Reports by test cycle: Testing groups may define and run reports that enable them to view the effectiveness of individual test cycles so that they may make adjustments to subsequent test cycles within a release cycle. The scope and depth of each test cycle is determined by the applicable test templates, environments, and project members that are defined at the release cycle level. Every test cycle is the child of a release cycle and test cycle options are limited to those options defined as applicable to that release. Planning Test Cycles Test cycle planning is the act of choosing appropriate test cases based on the results of previous test cycles within a release cycle. Test cycle planning is an iterative process that relies heavily on the results of previous test cycles within the current release cycle. After the completion of each test cycle, test planners may view summary reports and make adjustments based on the results of those tests. Subsequent test cycles may target features or environments that are buggy or stress tests that successfully discover bugs. Selecting appropriate test cases can be based on many different factors including the stability of the program, the results of previous test cycles, the availability of testing groups, or the testing objectives defined in the parent release cycle. Smoke tests: The first test cycle in a release cycle is frequently an automated smoke test of basic product functionality. If the product cannot pass a smoke test there is no need to assign more complex test tasks to the testing group until the basic bugs are fixed. Assign tasks for multiple environments: In each test cycle testing groups may determine which environments are tested in that cycle of testing. The applicable test template is used to generate test tasks specifically targeted at a selected group of environments and are assigned to a specific tester or testing group. Testing and retesting environments: Testing teams may generate and regenerate test tasks for specific environments in multiple test cycles. In each test cycle the test tasks may be assigned to the same applicable owners or to any other applicable owner or applicable testing group. Advance coverage selection by query: At the beginning of each test cycle the testing group may run a query to see which tests passed and which tests failed in previous test cycles. They may generate new test tasks based on the same test template to retest the feature. Meeting testing objectives: Testing groups may define targets for each release cycle of testing including targets for the number of tasks performed, the number of product defects found, the effective time, the ineffective time, and the total time spend testing. 1.6 Running Tests and Tracking Results Test tasks give testers the information that they need to set up and execute a test (the environment, test procedure, and expected result), they enable the testing team to track and analyze the results of the test, and they are foundation for any bug reports based on that test. DevTest reports enable testing teams to measure the performance and efficiency of their testing teams, identify their successes and failures, and to adjust test plans, test cases, schedules, or test assignment accordingly.

167 DevTest summary reports show the number of test tasks assigned, the number run, the percentage of the test tasks that passed or failed, the time required to execute the tests compared to the time estimated in the test plan. Summary reports may be grouped by release or test cycle or by tester within each test cycle. Submitting Bug Reports DevTest-DevTrack integration enables organizations define processes for testing, fixing, and retesting product defects, streamlines the submission of bug reports, and facilitates the sharing of information between the development and testing groups. Bugs discovered in DevTest may be submitted to DevTrack development projects for resolution, and the fixes may be retested in subsequent DevTest regression testing. The TechExcel DevTest-DevTrack solution enables testers to submit bug reports to an integrated DevTrack project fromwithin the DevTest client. Testers do not need to switch back and forth from DevTest and DevTrack to test and report product defects and so can report bugs immediately while they are still fresh in their minds. The quicker the tester creates the bug report the less likely the tester is to forget key details that will enable developers to reproduce the bug. Organizations may streamline the bug reporting process even further by mapping DevTest test task fields to DevTrack development issue fields. Key information such as the test procedure, the version of the software, and the environment tested may beautomaticallycopied from the test task to the newly created development issue. Test case-bug report field mapping reduces the amount of time that testers need to spend typing, and enables them to get back to their primary business of testing. Linking Test Cases to Bug Reports During the course of product testing, QA engineers may encounter bugs that are responsible for malfunctions in many different product features. Without the means to effectively communicate with one another, QA engineers may submit multiple identical bug reports to developers. The submission and re-submission of what are essentially identical bug reports only creates more work for the developers. In an integrated DevTest-DevTrack system, every DevTrack development issue may be linked to one or more test tasks usingdefect links. Defect links enable QA engineers to associate development issues with the test tasks that exposed them and enables testers and developers to share information and work more effectively. Moreover, every test task that is linked to a DevTrack development issue provides testers with the opportunity to draw from and add to the collected knowledge of the entire testing team. Each tester may add key details to the DevTrack issue enabling developers to understand the scope of a bug and how that bug affects other product features. Researching Existing Bug Reports DevTest encourages QA engineers to identify and research existing development issues before they submit new bug reports to the DevTrack project. Researching existing product defects provides the following benefits: Enables testers to familiarize themselves with development issues and draw on the experience of other QA engineers.?enables testers to fully understand product features and expected behavior. Access to DevTrack development issues enables QA engineers to read all linked control documents, business requirements, functional specifications, and technical specifications. Reduces the number of duplicate bugs reported to the development team and enables them to work more effectively. The submission and re-submission of what are essentially identical bug reports only creates more work for the developers. In fact, DevTest enables administrators may define workflow rules thatrequiretesters to search the knowledge base for existing issues before they can submit a new bug report. Sharing Experiences and Information The DevTest knowledge-centric approach facilitates communication between testing teams and developers so that all project members may work together more efficiently and effectively. As noted previously, submitting a bug report from within a DevTest project automatically creates a link between the DevTrack development issue and the originating test task. All test tasks notes are automatically copied over to the development issue providing the developers with key information that may enable them to identify the source of the bug. DevTest provides testing groups within many other tools for communicating key information to developers. DevTest HTML memo field controls enable testers to format the text of bug reports so that they can describe the steps required to reproduce the bug more effectively. Text formatting tools enable testers to create bulleted and numbered lists, tables, headers, and other formats that highlight key information. DevTest enables testers to attach files to bug reports such as screen captures of error messages and typos, keystroke captures, macros that generate the test case, printouts, memory dumps, and documents that define steps required to reproduce the bug in greater detail than that found in the test case. The mapping of DevTest test task fields to DevTrack development issue fields ensures that all key information is copied into the bug report. Developers need not question in which version or environment the bug was discovered. Conclusion TechExcel DevTest is a test management solution that enables test organizations to manage every stage of testing life cycle?rom test case design, to test execution, to test analysis. DevTest provides testing groups with the tools they need work more effectively and efficiently, hold down costs, and to deliver higher quality products. Chapter 2 DevTest Admin Basics 2.1 Understanding the DevTest Administration In DevTest, all system-level and project-level administrative tasks are managed in the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system and project administrators to define, configure, and administer TechExcel sites and projects. DevTest system administration is the process of configuring, administering, and maintaining adevtest site. A site consists of a knowledge base project and multiple template basework projects.every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client. Comparing System and Project Administration All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator? user account granted administrative privileges must open the appropriate project in the client. DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts: system administrator, division administrator, and project administrator account types. System- A system administrator is responsible for configuring, customizing, and managing the DevTest site and all system-level settings. Project- A project administrator is responsible for configuring, customizing, and managing knowledge, template, and work projects. Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own unique team structure and workflow. Understanding DevTest System Administration System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation, creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server. In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site. DevTest system administration tasks fall into seven general areas:

168 ?SPAN style="font: 7pt 'Times New Roman'"> DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server, DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.?span style="font: 7pt 'Times New Roman'"> User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.?span style="font: 7pt 'Times New Roman'"> for all member sites.?span style="font: 7pt 'Times New Roman'">?SPAN style="font: 7pt 'Times New Roman'"> the site.?span style="font: 7pt 'Times New Roman'"> Multiple Site Administration - Includes the definition and management of a site family and management of user licenses License Management System-level tasks include license management and allocation. Web Administration Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in Integration - Foundation of DevTest notification and escalation. All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client. 2.2 Understanding the DevTest Admin Workspace In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client. When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site. Figure 2-1: DevTest Admin Client The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-level features. The DevTest Admin client is organized into four sections:?span style="font: 7pt 'Times New Roman'"> Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, View, System, and Help menus.?span style="font: 7pt 'Times New Roman'"> Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.?span style="font: 7pt 'Times New Roman'"> Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed in the tree panel depending on the project type opened: knowledge, template, or work. Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-?span style="font: 7pt 'Times New Roman'"> level settings. Understanding Menu Bar Commands The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help menus. The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands displayed in the Tool menu.?span style="font: 7pt 'Times New Roman'">?SPAN style="font: 7pt 'Times New Roman'"> the Admin client.?span style="font: 7pt 'Times New Roman'"> File - Displays commands that enable the administrator to create, open, back up, restore work projects. View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in System - Displays commands that enable the administrator to perform a range of system-level administrative tasks

169 ?SPAN style="font: 7pt 'Times New Roman'"> System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user, login, and license administration.?span style="font: 7pt 'Times New Roman'"> current build. Help - Displays commands that enable the administrator to access online help systems and information about the Understanding the Tool Bar Commands The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings buttons. New Project button - Enables the administrator to create a new work project. Open Project button - Enables the administrator to open an existing work project. Close Project button - Enables the administrator to close a work project. Back Up Project button - Enables the administrator to back up an existing work project. Restore Project button - Enables the administrator to restore a closed work project. Delete Project button - Enables the administrator to delete a work project. User Manager button - Enables the administrator to open the User Manager. Login Manager button - Enables the administrator to open the Login Manager. Understanding the Tree Panel The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific. Knowledge Project In a knowledge base project the tree panel displays three folders:?span style="font: 7pt 'Times New Roman'"> Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and define knowledge versioning controls.?span style="font: 7pt 'Times New Roman'"> Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child template base and work projects.?span style="font: 7pt 'Times New Roman'"> Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI. To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator. Test Template Project In a test template project the tree panel displays five folders:?span style="font: 7pt 'Times New Roman'"> Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.?span style="font: 7pt 'Times New Roman'"> State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state statuses and state-based workflow rules.?span style="font: 7pt 'Times New Roman'"> Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures, administer system and custom fields, and customize template folder system, function, and custom pages.?span style="font: 7pt 'Times New Roman'"> Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields, and customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test template project features including template status groups, TestLink automated testing integration, and notification. To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator. Test Task Project In a work project the tree panel displays five folders:?span style="font: 7pt 'Times New Roman'"> Project Settings - The folder contains tools that enable the administrator to

170 ?SPAN style="font: 7pt 'Times New Roman'"> State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state statuses and state-based workflow rules.?span style="font: 7pt 'Times New Roman'"> Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.?span style="font: 7pt 'Times New Roman'"> Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test task project features including test task status groups, DevTrack bug tracking integration, notification, and test time tracking. To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator. 2.3 Accessing DevTest Projects Logging into DevTest Projects To access, configure and administer site, system, or project settings the administrator (user account granted administrative privileges) just opens the appropriate project in the client. To log into a DevTest project: 1.Select the DevTest Admin command in the Windows Start menu. By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder. The DevTest Admin Login dialog box appears. 2.Enter a user name and password. Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible. 3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service. Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site. 4Click the OK button. The DevTest Admin client opens. 5Select File > Open Project in the File menu. The Open Project window appears. 6Select a project in the project list. 7Click the OK button. The project opens. Switching Projects To switch to another project: 1Select File > Open Project in the File menu. The Open Project window appears. 2Select a project in the project list. 3Click the OK button. The project opens. Closing DevTest Projects Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:?select File > Close Project in the menu bar.?press CTRL + S. 2.4 Understanding the DevTest Administration In DevTest, all system-level and project-level administrative tasks are managed inn the DevTest Admin client. The DevTest Admin client is a web service-enabled client that enables system and project administrators to define, configure, and administer TechExcel sites and projects. DevTest system administration is the process of configuring, administering, and maintaining adevtest site. A site consists of a knowledge base project and multiple template basework projects.every project in a DevTest site shares a common database, knowledge base, and other system-level configurations that are defined in the DevTest Admin client. Comparing System and Project Administration All DevTest site, system, and project administrative tasks are performed in the DevTest Admin client. To access, configure and administer site, system, or project settings the administrator? user account granted administrative privileges?ust open the appropriate?roject?in the client. DevTest utilizes account type-based privileges to control access to administrative tools. A project member may be assigned three types of administrative accounts?system administrator, division administrator, and project administrator account types.?span style="font: 7pt 'Times New Roman'"> system-level settings.?span style="font: 7pt 'Times New Roman'"> work projects. System - A system administrator is responsible for configuring, customizing, and managing the DevTest site and all Project - A project administrator is responsible for configuring, customizing, and managing knowledge, template, and

171 Configurations defined in a work project apply to that work project alone. A company may have several active development projects running concurrently and each project may have its own unique team structure and workflow. Understanding DevTest System Administration System-level configurations define the DevTest site and the integration of every project within that site. System-level administration activities include maintaining the implementation, creating and defining new projects, managing users, managing licenses, and configuring the DevTest Document Server and the DevTest Web Server. In DevTest, system administration is the process of defining system, user, and project settings that define work in a DevTest site. DevTest system administration tasks fall into seven general areas:?span style="font: 7pt 'Times New Roman'"> DevTest Server Administration - Tasks include the installation and configuration of the DevTest Server (DevTest Database Server, DevTest Application Server, DevTest Document Server, DevTest Web Server) and the web services that are shared by all projects in the site.?span style="font: 7pt 'Times New Roman'"> User Administration - Tasks include the definition and management of user accounts and project administrators. Optional system-level administrative tasks include multiple site management, division management, and LDAP directory server integration and administration.?span style="font: 7pt 'Times New Roman'"> for all member sites.?span style="font: 7pt 'Times New Roman'">?SPAN style="font: 7pt 'Times New Roman'"> the site.?span style="font: 7pt 'Times New Roman'"> Multiple Site Administration - Includes the definition and management of a site family and management of user licenses License Management System-level tasks include license management and allocation. Web Administration Web administration - Includes the definition and configuration of DevTest Web Server settings for every work project in Integration - Foundation of DevTest notification and escalation. All system-level administrative tasks may be configured using controls in the System menu in the DevTest Admin client. 2.5 Understanding the DevTest Admin Workspace In DevTest, all DevTest Server, site, and system-level administrative tasks are performed in the DevTest System Settings project using controls in the DevTest Admin client. When the System Settings project is opened, the DevTest Admin client displays tools for configuring and administering an entire DevTest site. Figure 2-1: DevTest Admin Client The DevTest Admin client organizes the work area into two bars and two panels. Each page is designed to enable an administrator to configure and administer system-level and project-level features. The DevTest Admin client is organized into four sections:?span style="font: 7pt 'Times New Roman'"> Menu Bar - Displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, View, System, and Help menus.?span style="font: 7pt 'Times New Roman'"> Tool Bar - Displays controls that enable administrators to.perform system-level and project-level administrative tasks.?span style="font: 7pt 'Times New Roman'"> Tree Panel - Organizes administration tools into a hierarchical structure consisting of folders and folders. Distinct folders are displayed in the tree panel depending on the project type opened: knowledge, template, or work. Page Panel - Displays form-based administrative tools that enable the administrator to configure and maintain system-?span style="font: 7pt 'Times New Roman'"> level settings. Understanding Menu Bar Commands

172 The menu bar displays control buttons that enable the administrator to perform system-level and project-level administrative tasks. Menus include the File, Edit, View, Tool, and Help menus. The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the commands displayed in the Tool menu.?span style="font: 7pt 'Times New Roman'">?SPAN style="font: 7pt 'Times New Roman'"> the Admin client. File - Displays commands that enable the administrator to create, open, back up, restore work projects. View - Displays commands that enable the administrator to display or hide the tool bar, status bar, and alignment bar in?span style="font: 7pt 'Times New Roman'"> System - Displays commands that enable the administrator to perform a range of system-level administrative tasks including user, login, and license administration.?span style="font: 7pt 'Times New Roman'"> current build. Help - Displays commands that enable the administrator to access online help systems and information about the Understanding the Tool Bar Commands The tool bar displays controls that enable administrators to.perform system-level and project-level administrative tasks. The majority of the command buttons displayed in the DevTest Admin tool bar are project-specific commands. Of particular importance to system administrators are the User Manager button, License Manager button, and the Reload Web Settings buttons. New Project button - Enables the administrator to create a new work project. Open Project button - Enables the administrator to open an existing work project. Close Project button - Enables the administrator to close a work project. Back Up Project button - Enables the administrator to back up an existing work project. Restore Project button - Enables the administrator to restore a closed work project. Delete Project button - Enables the administrator to delete a work project. User Manager button - Enables the administrator to open the User Manager. Login Manager button - Enables the administrator to open the Login Manager. Understanding the Tree Panel The tree panel organizes administration tools into a hierarchical structure consisting of folders and subfolders. The folders and controls displayed in the tree panel depend on the project opened in the DevTest Admin client The folders displayed in the tree panel are project-specific. Knowledge Project In a knowledge base project the tree panel displays three folders:?span style="font: 7pt 'Times New Roman'"> Knowledge Base - The folder contains tools that enable the administrator to update project settings, identify project administrators, and define knowledge versioning controls.?span style="font: 7pt 'Times New Roman'"> Knowledge Access Control - The folder contains tools that enable the administrator to grant read and build access rights to child template base and work projects.?span style="font: 7pt 'Times New Roman'"> Knowledge GUI - The folder contains tools that enable the administrator to customize the knowledge project GUI. To access and administer the tools contained in the knowledge base project folders, the user must be designated as a knowledge project administrator. Test Template Project In a test template project the tree panel displays five folders:?span style="font: 7pt 'Times New Roman'"> Project Settings - The folder contains tools that enable the administrator to update project settings, enable optional features (including environmental variables, verification points, and template feedback notes), identify project administrators, and administer project team members.?span style="font: 7pt 'Times New Roman'"> State Definition - The folder contains tools that enable the administrator to define the test template lifecycle including workflow state statuses and state-based workflow rules.?span style="font: 7pt 'Times New Roman'"> Template Folder GUI - The folder contains tools that enable the administrator to define test template management structures, administer system and custom fields, and customize template folder system, function, and custom pages.?span style="font: 7pt 'Times New Roman'"> Template GUI - The folder contains tools that enable the administrator to define test templates, administer system and custom fields, and customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to

173 administer optional test template project features including template status groups, TestLink automated testing integration, and notification. To access and administer the tools contained in the template base project folders, the user must be designated as a template project administrator. Test Task Project In a work project the tree panel displays five folders:?span style="font: 7pt 'Times New Roman'"> Project Settings - The folder contains tools that enable the administrator to?span style="font: 7pt 'Times New Roman'"> State & Workflow - The folder contains tools that enable the administrator to define the test task lifecycle including workflow state statuses and state-based workflow rules.?span style="font: 7pt 'Times New Roman'"> Planning View GUI - The folder contains tools that enable the administrator to define test planning management structures, administer system and custom fields, customize test planning wizard system and custom pages, and administer planning summary reports.?span style="font: 7pt 'Times New Roman'"> Test Task GUI - The folder contains tools that enable the administrator to define test tasks, administer system and custom fields, and customize template folder system, function, and custom pages. Advanced Features The folder contains tools that enable the administrator to administer optional test task project features including test task status groups, DevTrack bug tracking integration, notification, and test time tracking. To access and administer the tools contained in the work project folders, the user must be designated as a work project administrator. 2.6 Accessing DevTest Projects Logging into DevTest Projects To access, configure and administer site, system, or project settings the administrator? user account granted administrative privileges?ust open the appropriate?roject?in the client. To log into a DevTest project: 1.Select the DevTest Admin command in the Windows Start menu. By default, the DevTest Admin icon is added to the DevTest Admin subfolder within the TechExcel DevTest folder. The DevTest Admin Login dialog box appears. 2.Enter a user name and password. Note:DevTest Admin is delivered with a default system administrator defined (User Name: Admin, Password: (blank). The password is case-sensitive, however the user name is not case-sensitive. For security reasons TechExcel recommends changing the default login setting as soon as possible. 3.To change web services, select an option from the Web Service dropdown list. The DevTest Admin client connects to the DevTest Application Server through the DevTest Web Service. Changing the web service enables the client to connect to a different DevTest Application Server and manage a different DevTest site. 4Click the OK button. The DevTest Admin client opens. 5Select File > Open Project in the File menu. The Open Project window appears. 6Select a project in the project list. 7Click the OK button. The project opens. Switching Projects To switch to another project: 1Select File > Open Project in the File menu. The Open Project window appears. 2Select a project in the project list. 3Click the OK button. The project opens. Closing DevTest Projects Administrators may use the Close Project command to close DevTest projects. The Close Project command may be invoked by two methods:?select File > Close Project in the menu bar.?press CTRL + S. Chapter 3 Project Administration 3.1 Administering DevTest Projects In DevTest, a project is a tool for storing, organizing, and managing testing and QA processes. Every DevTest implementation, called adevtest site, consists of a knowledge base project, a test template project, and a work project. DevTest enables project teams to create three different types of projects. Each project type provides users with the views and tools that a project team may use to manage an aspect of the testing process. Knowledge Project Knowledge projects enable project teams to collect and manage information gathered across multiple template projects and work projects. Knowledge project members may manage knowledge items in the knowledge project. When integrating DevTest with a DevSuite master site administrators can link the DevTest Knowledge Project to the appropriate KnowledgeWise project in the DevSuite system.

174 Template Project Work Project Template projects enable project teams to create and manage test templates that may used to create test tasks in multiple work projects. Template project members may manage test templates in a template project. Work projects enable project teams to plan and execute test cycles using test tasks that have been generated from test templates created in a parent test template project. Work project members may manage test tasks in the work project. Every DevTest implementationmustconsist of at least three projects: a knowledge project, a template project, and a work project. The relationship between each of the three project types is hierarchical. A knowledge project is the parent of one or more child template projects. Each template project is the parent to one or more child work projects. Every work project is the child of one template project. The project hierarchy represents the organization of projects within the DevTest system and defines how project customizations and project access are shared across different projects. Creating DevTest Projects The New Project dialog box enables administrators to define the project title, the project type, and to import project settings from previously-defined projects. Using controls in the New Project window, system administrators may create new live and sample projects. Most system-level project settings cannot be edited once defined. The project type, project base, and knowledge base of a project cannot be altered. Administrators may edit the project name, project identifier, and the project description settings. For more information see See editing DevTest Project Settings. Project definition settings define the project type and the parent project in the DevTest system. These settings enable the DevTest system to integrate records created in the new project with other DevTest projects. Most system-level project properties are permanent. Once an administrator has created a project the project type, project base, and knowledge base definitions for that project cannot be changed. Administrators may edit the project name, project identifier, and the project description settings. Project-definition settings are defined by system administrators when they create a project in DevTest. Those project-definition settings that are editable can be changed by project administrators in the Project Settings Overview page. Project Name Project Identifier Project Type Template Base Knowledge Base Description ID Prefix ID Starting No. Active Project The Project Name property enables administrators to define the name of the project. The Project Identifier property enables administrators to define a prefix that is added to each issue created in the project. This identifier may be used to identify issues associated with a particular project.the project identifier prefix may include alphabetical or numeric characters. The Project Type property enables administrators to define the project type. Once set this propertycannotbe changed. Every DevTest project is one of three types of projects: template base, work, or knowledge base. The Template Base property enables administrators to define the project template base. Once set this propertycannotbe changed. Every project belongs to a template base. The Knowledge Base property enables administrators to define the project knowledge base. Once set this propertycannotbe changed. The Description property enables administrators to define a general description of the current project. The ID Prefix property enables administrators to define a numerical or character prefix to each issue ID. This feature may be used so that issues associated with a particular project are easier to identify. The ID Starting No. property enables administrators to define the initial issue ID number. For example, if an administrators enters 100 in this field, the first issue created will be issue 100. The Active Project property enables administrators to define the status of the project: a project must be active before users may access it. A project must be inactive before the system administrator can delete it.

175 Name Display Format The Name Display Format property enables administrators to define how the project displays the names of project members. Names are displayed either first name, last name or last name, first name. Date/Time Format The Date/Time Format property enables administrators to define the project? time zone and date settings. If the system-level time zone definition is selected, the Date/Time Format dialog box is disabled. For more information, see?dministering System Date and Time Settings? System administrators need not define every project from scratch. Administrators may import system-level project settings from previously created projects whenever they create a new DevTest project. For more information see See?mporting Project Definition Properties? When creating DevTest projects administrators may create projects from scratch or they may import project properties from existing projects, sample projects, or project templates. Creating Knowledge Projects To create a new knowledge project: 1Select File > New Project. The New Project manager appears. 2Enter a project title in the Project Name text box. Avoid using the following characters when naming the project: / \ :??< >. 3Define the project as a live project or sample project.?to define the project as a sample project, select the Sample Project option button.?to define the project as a live project, select the Live Project option button. 4Enter a project identifier in the Project Identifier field. The project identifier property creates a prefix that is added to each issue created in the project. Administrators may the project identifier to track all records associated with this project. 5Select the Knowledgebase Base Project option Project Type dropdown list. The Project Type dropdown list displays three options: knowledge, template, and work. 6 Optional: To copy project settings from an existing knowledge project, select that project in the list. 7Click the Next button. The Available Project Settings page appears. 8Select one or more of the project-level settings defined in the selected knowledge project. The following knowledge project settings may be copied from existing knowledge projects. Project Administrators Knowledge Folder Access Knowledge Folder Information Knowledge GUI Fields 9Click the Finish button. Creating Template Projects To create a new template project: 1Select File > New Project. The New Project manager appears. 2Enter a project title in the Project Name text box. Avoid using the following characters when naming the project: / \ :??< >. 3Define the project as a live project or sample project.?to define the project as a sample project, select the Sample Project option button.?to define the project as a live project, select the Live Project option button. 4Enter a project identifier in the Project Identifier field. The project identifier property creates a prefix that is added to each issue created in the project. Administrators may the project identifier to track all records associated with this project. 5Select the Template Base Project option Project Type dropdown list. The Project Type dropdown list displays three options: knowledge, template, and work. 6Select a knowledge project in the Knowledge Base dropdown list. Every DevTest template project is the child of a single knowledge base project. 7 Optional: To copy project settings from an existing template project, select that project in the list. 8Click the Next button.

176 The Available Project Settings page appears. 9Select one or more of the project-level settings defined in the selected knowledge project. The following knowledge project settings may be copied from existing template projects. Account Types and Privileges Project Environment Variables State and Workflow Settings Template GUI Settings Status Group Settings Template Folder Project Members, Groups and Group Folders Verification Point Settings Template Folder GUI Settings Notification Settings TestLink Settings Template 10Click the Next button. The New Project Confirmation page appears. 11Click the Finish button. Creating Work Projects To create a new work project: 1Select File > New Project. The New Project manager appears. 2Enter a project title in the Project Name text box. Avoid using the following characters when naming the project: / \ :??< >. 3Define the project as a live project or sample project.?to define the project as a sample project, select the Sample Project option button.?to define the project as a live project, select the Live Project option button. 4Enter a project identifier in the Project Identifier field. The project identifier property creates a prefix that is added to each issue created in the project. Administrators may the project identifier to track all records associated with this project. 5Select the Work Project option Project Type dropdown list. The Project Type dropdown list displays three options: knowledge, template, and work. 6Select a template project in the Template Base dropdown list. Every DevTest work project is the child of a single template base project. 7 Optional: To copy project settings from an existing knowledge project, select that project in the list. 8Click the Next button. The Available Project Settings page appears. 9Select one or more of the project-level settings defined in the selected knowledge project. The following knowledge project settings may be copied from existing knowledge projects. Account Types and Privileges State and Workflow Settings Test Task View GUI Settings Status Group Settings Project Members, Groups and Group Folders Planning View GUI Settings Notification Settings DevTrack Integration 10Click the Finish button. Administering Sample Projects In DevTest, a sample project is a project that provides the development organization with a sandbox for configuring and evaluating features and integrations in a risk free environment. Using tools in DevTest Admin, administrators may create sample projects or live projects based on sample projects. Project administrators may freely configure sample projects to represent their development processes.?project configurations and settings tried and tested in sample projects may be imported into newly created?ive projects??sample projects provide development organizations with a tool for training new users or to introduce existing users to new features or changes in businesses processes.

177 Using controls in the DevTest Admin client, administrators may create additional sample or live knowledge base, template, and work projects based on existing projects. Backing Up DevTest ProjectsDevTest stores backups of DevTrack projects in a proprietary DTT file format. Once the administrator define the project information, the administrator may back up either the entire database or only selected projects. DevTest Admin creates the backup file with the selected project data. DevTest Admin stores backed up projects in a proprietary DTT file format. Note:DevTest backups are a good way to save project properties, but cannot be considered a substitute for regular database server backups. To backup DevTest projects: 1Invoke the Back Up Project command.?select File > Back Up Project in the menu bar.?press CTRL + B. The Back Up Project dialog box appears. 2Click the Ellipsis button to navigate to the location of the backup file. The Backup dialog box opens. 3Navigate to the location of the backup files. 4Enter a name for the DTT file in the File Name field. 5Select the DevTrack Backup File (DTT) option in the Save as Type dropdown list. 6Click the Save button. The Backup dialog box closes. 7Select a back up option:?click the Whole Database radio button to backup all projects in a DevTrack implementation.?click the Selected Projects radio button to backup some, but not all projects in a DevTrack implementation. Highlight the projects to be backed up. 8 Optional: To identify the project to be backed up, select a project in the project list. 9Projects may be selected only if the Selected Projects option is selected. 10Click the OK button. The site or project is backed up. Restoring DevTest Projects DevTest stores backups of DevTest projects in a proprietary DTT file format. Administrators may choose to back up selected projects or the entire database. When restoring backed up DevTest projects administrators may overwrite existing projects or create new projects based on the backed up projects. To restore DevTest projects: 1Invoke the Restore command.?elect File > Restore in the menu bar.?ress CTRL + R. The Restore Project dialog box appears. 2Locate the backed up project. DevTest stores backups of DevTest projects in a proprietary DTT file format. 3Click the Open button. The DevTest Restore II dialog box appears. The dialog box displays the Project ID number of the project to be restored. 4Select the Overwrite radio button in the Options area. 5Click the OK button. The project is restored. If the DTK file selected contains multiple backed up, the DevTest Restore II dialog box appears for each backed up project. Creating Projects Based from Backed Up Projects Whenever an administrator backs up a DevTest project, DevTest saves a copy of that project in a proprietary DTT file format. Administrators may create a new DevTest project from DTK files.

178 To create a new project from a backed up project: 1Invoke the Restore command.?elect File > Restore in the menu bar.?ress CTRL + R. The Restore Project dialog box appears. 2Locate the backed up project. DevTest stores backups of DevTest projects in a proprietary DTT file format. 3Click the Open button. The DevTest Restore II dialog box appears. 4Select the Create New project radio button in the Options area. 5Enter a title in the New Project Name field. 6Click the OK button. The new project is created and the Open Project dialog box appears. Understanding Active and Inactive Projects Every DevTest project has either an active or inactive status. The status of a project determines the tasks that an administrator may perform on that project. Administrators define the status of a project by selecting the Active Project check box in the Overview page. Active Projects Administrators may perform the following tasks using active DevTest projects:?administrators may open active projects in DevTest Admin and configure project settings.?administrators may use the User Manager to add user accounts as project members to active projects.?administrators may import project properties from Active projects. Inactive Projects Administrators may perform the following tasks using inactive DevTest projects:?inactive DevTest projects may be deleted using the Delete Project command. Active projects cannot be deleted. Deleting DevTest Projects System administrators may use the Delete command to delete inactive DevTest projects. Administrators may only delete projects that have an inactive status. For instructions on making a project inactive see?nderstanding Active and Inactive Projects? Note:Deleting a project from the system is permanent. Administrators must perform all appropriate back ups before deleting a project. To delete a project: 1Select File > Delete. 2The Delete Project dialog box appears. The Delete Project dialog box displays all of the projects that may be deleted. Only those projects that have an inactive status may be deleted. 3Select a project. 4Click the Delete button. Understanding Keyboard Shortcuts Keyboard shortcuts are combinations of keystrokes that perform predefined functions. Keyboard shortcuts consist of a modifier key and a hot key: CTRL + X CTRL + C CTRL + V CTRL + N Cut Copy Paste New Project

179 CTRL + O CTRL + S CTRL + B CTRL + R Open Project Close Project Backup Project Restore Project CTRL + D Delete Project All projects in a DevTest site are organized into a hierarchical structure that defines the relationships between the projects in a DevTest site. 3.2 Administering General Project Settings Editing DevTest Project Settings System administrators may use the Project Settings page to update a limited number of project properties. Most system-level project settings cannot be edited once defined. The project project type, project base, and knowledge base of a project cannot be altered. Administrators may edit the project name, project identifier, and the project description settings. To edit DevTest project settings: 1Select Project Settings > Overview. The Project Settings page appears. 2Enter a name in the Name field 3Enter an identifier in the Project Identifier field. 4Enter a brief description in the Description text field. Administering Project Login TipsIn DevTest, the project tip window is an administrator-defined message that is displayed in the client workspace when a user logs into a DevTest project. The window is designed to enable project administrators to provide project team members with information or links to information that will enable them to begin working in a project. The project tips window is fully customizable on a project-by-project basis. Using controls in the Admin client, project administrators may define both the content and format of the project tip. To define a project login tip: 1Select Project Settings > Project Login Tip in the tree panel. 2Input the title of the project login tip in the Title text box. 3Define and format the project login tip.?to define or edit the project login tip using a wysiwyg editor, click the Edit button.?to define or edit the project login tip using HTML markup tags, click the Edit Source button. To enable project login tip preferences: To enable project team members to define their own project login tip preferences, select the Allow Users To Skip Project Tip Screen check box. To override project login tip preferences: To override project team member project login tip preferences, clcik the Reset User Project Tip Preferences button. If this button is clicked, the project login tip window is displayed in the workspace of every DevTest user the next time they log into the project. 3.3 Administering DevTest Projects In DevTest, a project is a tool for storing, organizing, and managing testing and QA processes. Every DevTest implementation?alled adevtest site?onsists of a knowledge base project, a test template project, and a work project. DevTest enables project teams to create three different types of projects. Each project type provides users with the views and tools that a project team may use to manage an aspect of the testing process. Knowledge Project Knowledge projects enable project teams to collect and manage information gathered across multiple template projects and work projects. Knowledge project members may manage knowledge items in the knowledge project.

180 Template Project Work Project Template projects enable project teams to create and manage test templates that may used to create test tasks in multiple work projects. Template project members may manage test templates in a template project. Work projects enable project teams to plan and execute test cycles using test tasks that have been generated from test templates created in a parent test template project. Work project members may manage test tasks in the work project. Every DevTest implementationmustconsist of at least three projects: a knowledge project, a template project, and a work project. The relationship between each of the three project types is hierarchical. A knowledge project is the parent of one or more child template projects. Each template project is the parent to one or more child work projects. Every work project is the child of one template project. The project hierarchy represents the organization of projects within the DevTest system and defines how project customizations and project access are shared across different projects. In DevTest, a project is a tool for storing, organizing, and managing work items, project knowledge, and testing teams. A project is a tool for storing, organizing, and managing testing and QA processes. Every DevTest implementation?alled adevtest site?onsists of a knowledge base project, a test template project, and a work project. Creating DevTest Projects The New Project dialog box enables administrators to define the project title, the project type, and to import project settings from previously-defined projects. Using controls in the New Project window, system administrators may create new live and sample projects. Most system-level project settings cannot be edited once defined. The project type, project base, and knowledge base of a project cannot be altered. Administrators may edit the project name, project identifier, and the project description settings. For more information see See?diting DevTest Project Settings? Project definition settings define the project type and the parent project in the DevTest system. These settings enable the DevTest system to integrate records created in the new project with other DevTest projects. Most system-level project properties are permanent. Once an administrator has created a project the project type, project base, and knowledge base definitions for that project cannot be changed. Administrators may edit the project name, project identifier, and the project description settings. Project-definition settings are defined by system administrators when they create a project in DevTest. Those project-definition settings that are editable can be changed by project administrators in the Project Settings Overview page. Project Name Project Identifier Project Type Template Base Knowledge Base Description ID Prefix ID Starting No. The Project Name property enables administrators to define the name of the project. The Project Identifier property enables administrators to define a prefix that is added to each issue created in the project. This identifier may be used to identify issues associated with a particular project.the project identifier prefix may include alphabetical or numeric characters. The Project Type property enables administrators to define the project type. Once set this propertycannotbe changed. Every DevTest project is one of three types of projects: template base, work, or knowledge base. The Template Base property enables administrators to define the project template base. Once set this propertycannotbe changed. Every project belongs to a template base. The Knowledge Base property enables administrators to define the project knowledge base. Once set this propertycannotbe changed. The Description property enables administrators to define a general description of the current project. The ID Prefix property enables administrators to define a numerical or character prefix to each issue ID. This feature may be used so that issues associated with a particular project are easier to identify. The ID Starting No. property enables administrators to define the initial issue ID number. For example, if an administrators enters 100 in this field, the first issue created will be issue 100.

181 Active Project The Active Project property enables administrators to define the status of the project: a project must be active before users may access it. A project must be inactive before the system administrator can delete it. Name Display Format The Name Display Format property enables administrators to define how the project displays the names of project members. Names are displayed either first name, last name or last name, first name. Date/Time Format The Date/Time Format property enables administrators to define the project? time zone and date settings. If the system-level time zone definition is selected, the Date/Time Format dialog box is disabled. For more information, see?dministering System Date and Time Settings? System administrators need not define every project from scratch. Administrators may import system-level project settings from previously created projects whenever they create a new DevTest project. For more information see See?mporting Project Definition Properties? When creating DevTest projects administrators may create projects from scratch or they may import project properties from existing projects, sample projects, or project templates. Creating Knowledge Projects To create a new knowledge project: 1Select File > New Project. The New Project manager appears. 2Enter a project title in the Project Name text box. Avoid using the following characters when naming the project: / \ :??. 3Define the project as a live project or sample project.?to define the project as a sample project, select the Sample Project option button.?to define the project as a live project, select the Live Project option button. 4Enter a project identifier in the Project Identifier field. The project identifier property creates a prefix that is added to each issue created in the project. Administrators may the project identifier to track all records associated with this project. 5Select the Knowledgebase Base Project option Project Type dropdown list. The Project Type dropdown list displays three options: knowledge, template, and work. 6 Optional: To copy project settings from an existing knowledge project, select that project in the list. 7Click the Next button. The Available Project Settings page appears. 8Select one or more of the project-level settings defined in the selected knowledge project. The following knowledge project settings may be copied from existing knowledge projects. Project Administrators Knowledge Folder Access Knowledge Folder Information Knowledge GUI Fields 9Click the Finish button. Creating Template Projects To create a new template project: 1Select File > New Project. The New Project manager appears. 2Enter a project title in the Project Name text box. Avoid using the following characters when naming the project: / \ :??. 3Define the project as a live project or sample project.?to define the project as a sample project, select the Sample Project option button.?to define the project as a live project, select the Live Project option button. 4Enter a project identifier in the Project Identifier field. The project identifier property creates a prefix that is added to each issue created in the project. Administrators may the project identifier to track all records associated with this project. 5Select the Template Base Project option Project Type dropdown list. The Project Type dropdown list displays three options: knowledge, template, and work. 6Select a knowledge project in the Knowledge Base dropdown list. Every DevTest template project is the child of a single knowledge base project.

182 7 Optional: To copy project settings from an existing template project, select that project in the list. 8Click the Next button. The Available Project Settings page appears. 9Select one or more of the project-level settings defined in the selected knowledge project. The following knowledge project settings may be copied from existing template projects. Account Types and Privileges Project Environment Variables State and Workflow Settings Template GUI Settings Status Group Settings Template Folder Project Members, Groups and Group Folders Verification Point Settings Template Folder GUI Settings Notification Settings TestLink Settings Template 10Click the Next button. The New Project Confirmation page appears. 11Click the Finish button. Creating Work Projects To create a new work project: 1Select File > New Project. The New Project manager appears. 2Enter a project title in the Project Name text box. Avoid using the following characters when naming the project: / \ :??. 3Define the project as a live project or sample project.?to define the project as a sample project, select the Sample Project option button.?to define the project as a live project, select the Live Project option button. 4Enter a project identifier in the Project Identifier field. The project identifier property creates a prefix that is added to each issue created in the project. Administrators may the project identifier to track all records associated with this project. 5Select the Work Project option Project Type dropdown list. The Project Type dropdown list displays three options: knowledge, template, and work. 6Select a template project in the Template Base dropdown list. Every DevTest work project is the child of a single template base project. 7 Optional: To copy project settings from an existing knowledge project, select that project in the list. 8Click the Next button. The Available Project Settings page appears. 9Select one or more of the project-level settings defined in the selected knowledge project. The following knowledge project settings may be copied from existing knowledge projects. Account Types and Privileges State and Workflow Settings Test Task View GUI Settings Status Group Settings Project Members, Groups and Group Folders Planning View GUI Settings Notification Settings DevTrack Integration 10Click the Finish button. Administering Sample Projects In DevTest, a sample project is a project that provides the development organization with a sandbox for configuring and evaluating features and integrations in a risk free environment. Using tools in DevTest Admin, administrators may create sample projects or live projects based on sample projects. Project administrators may freely configure sample projects to represent their development processes.

183 ?Project configurations and settings tried and tested in sample projects may be imported into newly created?ive projects??sample projects provide development organizations with a tool for training new users or to introduce existing users to new features or changes in businesses processes. Using controls in the DevTest Admin client, administrators may create additional sample or live knowledge base, template, and work projects based on existing projects. Backing Up DevTest ProjectsDevTest stores backups of DevTrack projects in a proprietary DTT file format. Once the administrator define the project information, the administrator may back up either the entire database or only selected projects. DevTest Admin creates the backup file with the selected project data. DevTest Admin stores backed up projects in a proprietary DTT file format. Note:DevTest backups are a good way to save project properties, but cannot be considered a substitute for regular database server backups. To backup DevTest projects: 1Invoke the Back Up Project command.?select File > Back Up Project in the menu bar.?press CTRL + B. The Back Up Project dialog box appears. 2Click the Ellipsis button to navigate to the location of the backup file. The Backup dialog box opens. 3Navigate to the location of the backup files. 4Enter a name for the DTT file in the File Name field. 5Select the DevTrack Backup File (DTT) option in the Save as Type dropdown list. 6Click the Save button. The Backup dialog box closes. 7Select a back up option:?click the Whole Database radio button to backup all projects in a DevTrack implementation.?click the Selected Projects radio button to backup some, but not all projects in a DevTrack implementation. Highlight the projects to be backed up. 8 Optional: To identify the project to be backed up, select a project in the project list. 9Projects may be selected only if the Selected Projects option is selected. 10Click the OK button. The site or project is backed up. Restoring DevTest Projects DevTest stores backups of DevTest projects in a proprietary DTT file format. Administrators may choose to back up selected projects or the entire database. When restoring backed up DevTest projects administrators may overwrite existing projects or create new projects based on the backed up projects. To restore DevTest projects: 1Invoke the Restore command.?elect File > Restore in the menu bar.?ress CTRL + R. The Restore Project dialog box appears. 2Locate the backed up project. DevTest stores backups of DevTest projects in a proprietary DTT file format. 3Click the Open button. The DevTest Restore II dialog box appears. The dialog box displays the Project ID number of the project to be restored. 4Select the Overwrite radio button in the Options area. 5Click the OK button. The project is restored. If the DTK file selected contains multiple backed up, the DevTest Restore II dialog box appears for each backed up project. Creating Projects Based from Backed Up Projects

184 Whenever an administrator backs up a DevTest project, DevTest saves a copy of that project in a proprietary DTT file format. Administrators may create a new DevTest project from DTK files. To create a new project from a backed up project: 1Invoke the Restore command.?elect File > Restore in the menu bar.?ress CTRL + R. The Restore Project dialog box appears. 2Locate the backed up project. DevTest stores backups of DevTest projects in a proprietary DTT file format. 3Click the Open button. The DevTest Restore II dialog box appears. 4Select the Create New project radio button in the Options area. 5Enter a title in the New Project Name field. 6Click the OK button. The new project is created and the Open Project dialog box appears. Understanding Active and Inactive Projects Every DevTest project has either an active or inactive status. The status of a project determines the tasks that an administrator may perform on that project. Administrators define the status of a project by selecting the Active Project check box in the Overview page. Active Projects Administrators may perform the following tasks using active DevTest projects:?administrators may open active projects in DevTest Admin and configure project settings.?administrators may use the User Manager to add user accounts as project members to active projects.?administrators may import project properties from Active projects. Inactive Projects Administrators may perform the following tasks using inactive DevTest projects:?inactive DevTest projects may be deleted using the Delete Project command. Active projects cannot be deleted. Deleting DevTest Projects System administrators may use the Delete command to delete inactive DevTest projects. Administrators may only delete projects that have an inactive status. For instructions on making a project inactive see?nderstanding Active and Inactive Projects? Note:Deleting a project from the system is permanent. Administrators must perform all appropriate back ups before deleting a project. To delete a project: 1Select File > Delete. 2The Delete Project dialog box appears. The Delete Project dialog box displays all of the projects that may be deleted. Only those projects that have an inactive status may be deleted. 3Select a project. 4Click the Delete button. Understanding Keyboard Shortcuts Keyboard shortcuts are combinations of keystrokes that perform predefined functions. Keyboard shortcuts consist of a modifier key and a hot key: CTRL + X CTRL + C Cut Copy

185 CTRL + V CTRL + N CTRL + O CTRL + S CTRL + B CTRL + R Paste New Project Open Project Close Project Backup Project Restore Project CTRL + D Delete Project All projects in a DevTest site are organized into a hierarchical structure that defines the relationships between the projects in a DevTest site. 3.4 Administering General Project Settings Editing DevTest Project Settings System administrators may use the Project Settings page to update a limited number of project properties. Most system-level project settings cannot be edited once defined. The project project type, project base, and knowledge base of a project cannot be altered. Administrators may edit the project name, project identifier, and the project description settings. To edit DevTest project settings: 1Select Project Settings > Overview. The Project Settings page appears. 2Enter a name in the Name field 3Enter an identifier in the Project Identifier field. 4Enter a brief description in the Description text field. Administering Project Login TipsIn DevTest, the project tip window is an administrator-defined message that is displayed in the client workspace when a user logs into a DevTest project. The window is designed to enable project administrators to provide project team members with information or links to information that will enable them to begin working in a project. The project tips window is fully customizable on a project-by-project basis. Using controls in the Admin client, project administrators may define both the content and format of the project tip. To define a project login tip: 1Select Project Settings > Project Login Tip in the tree panel. 2Input the title of the project login tip in the Title text box. 3Define and format the project login tip.?to define or edit the project login tip using a wysiwyg editor, click the Edit button.?to define or edit the project login tip using HTML markup tags, click the Edit Source button. To enable project login tip preferences: To enable project team members to define their own project login tip preferences, select the Allow Users To Skip Project Tip Screen check box. To override project login tip preferences: To override project team member project login tip preferences, clcik the Reset User Project Tip Preferences button. If this button is clicked, the project login tip window is displayed in the workspace of every DevTest user the next time they log into the project. Chapter 4 Team Administration 4.1 Administering Work Project Privileges and Access Controls Work projects enable testing teams to plan and execute test tasks in release cycles and test cycles. The account types that a project administrator creates in a work project represent roles that appropriate to the tasks that must be performed within that project.

186 The administrator may differentiate between account types by assigning different work project privileges to each account type. Project administrators may create any number of account types to represent all of the different roles that a project member may perform in the QA process. Work project privileges enable project member to plan and execute test tasks in a work project. A typical testing team for a DevTest work project might include the following account types: Product Manager QA Lead Engineer Developer QA Engineer QA Manager Administering Test Planning Management Privileges In DevTest, a privilege is a right to perform a task that is granted to project members based on their account type. Test planning management privileges determine which project team members may create, modify, and delete test folders. Planning view privileges are generally only assigned to account types responsible for planning or managing test assignment and executions; for example, a test manager. Can Access Planning View --The Can Access Planning View privilege enables an account type to access the Planning view of a work project. Can Create Test Folder --The Can Create Test Folder privilege an account type to create new planning folders in the Planning Tree window. Can Modify Test Folder--The Can Modify Test Folder privilege enables project members to edit planning folders in the Planning Tree window. Can Delete Test Folder--The Can Delete Test Folder privilege enables project members delete planning folders in the Planning Tree window. Can Create New Release -- The Can Create New Release enables the account type to create a new release (release folder) and define release settings. Can Create New Test Cycle -- The Can Create New Release enables the account type to create a new test cycle (test cycle folder) and define test cycle settings. Can Show Template Tree--The Can Show Template Tree enables the account type to view the template tree panel in the planning and test task view of the DevTest client. Can Access User Preference --The Can Access User Preference enables the account type to define personal preferences in the DevTest client. Can Push User Preference Settings To Other User --The Can Push User Preference Settings To Other User enables the account type to define the personal preferences of other project team members. Administering Test Task Management Privileges In DevTest, a privilege is a right to perform a task that is granted to project members based on their account type. Issue management privileges determine which project team members may submit and manage test tasks in a project. Work view privileges are assigned to account types that are responsible for executing test tasks in a work project. Can Access Task View privilege --The Can Access Task View privilege enables project members to access the Task view within a work project. Can Forward Own Task to Own Group Members privilege --The Can Forward Own Task To Own Group Members privilege enables project members to forward the test tasks they own to members of their group.for more information on groups see Administering Team Groups on page 94 Can Forward Other User s Task Within Own Group privilege --The Can Forward Other User s Task Within Own Group privilege enables project members to forward tasks belonging to members of their group to other members of the same group. For more information on groups see Administering Team Groups". Can Forward Own Tasks to All Project Members privilege -- The Can Forward Own Tasks to All Project Members privilege enables an account type to forward the test tasks they own to any other project member. Can Forward Other User s Task to All Project Members privilege -- The Can Forward Other User s Task to All Project Members privilege project members to forward test tasks belonging to anyone in the project to any other project member. Can View Tasks With Own Group privilege--the Can View Tasks of All Groups privilege enables project members to view every test tasks that is owned by a member of their group. For more information on groups see Administering Team Groups. Can View Tasks of All Groups privilege --The Can View Tasks of All Groups privilege enables project members to view all tasks belonging to every groups. For more information on groups see Administering Team

187 Groups. Can Edit Tasks within Group privilege --The Can Edit Tasks within Group privilege enables project members to edit test tasks belonging to anyone within their group. For more information on groups see Administering Team Groups. Can Edit All Tasks privilege -- The Can Edit All Tasks privilege enables project members to edit test tasks belonging to all project members. Can Edit Other User s Notes privilege--the Can Edit Other User s Notes privilege enables project members to edit notes created by all project members. Can Define Public Query privilege --The Can Define Public Query privilege enables project administrators to define queries that are available to all project members. Can Perform Group Change privilege -- The Can Perform Group Change privilege project members to edit or forward groups of test tasks simultaneously Can Perform Inter-project Defect Submission privilegethe Can Perform Inter-project Defect Submission privilege enables project members to submit product defect issues to an integrated DevTrack project from within the Task view of a DevTest work project. Can Link a Defect to a Test Task privilege The Can Link a Defect to a Test Task privilege enables project members to create links between DevTest test tasks and DevTrack product defect issues. Can Delete a Test Task privilege The Can Delete a Test Task privilege enables project members to delete test tasks in a work project. Can Add Template Feedback Note privilege The Can Add Template Feedback Note privilege enables project members to create template feedback notes. Template feedback notes enable project members to inform template project members of errors found in child test tasks. Can Edit Time Tracking Item privilege The Can Edit Time Tracking Item privilege enables project members to edit the time measured by the time tracking stopwatch. The Can Edit Time Tracking Item privilege may only be granted if time tracking is enabled in the Time Tracking Settings page. Administering Knowledge View Privileges Work Knowledge view privileges enable project members to perform certain actions in the Knowledge view of a template project. All DevTest privileges are granted to account types. Project members inherit privileges when they are assigned an account type in a project. Administering Report View Privileges The Report view enables users to create public reports. Report view privileges are generally only granted to team members responsible for generating and examining test plan results. Can Access Test Task Report View The Can Access Test Task Report View privilege enables the account type to access the test task report view. Can Create Public Test Task Report The Can Create Public Test Task Report privilege enables the account type to author public test task reports. Can Create Private Test Task Report The Can Create Private Test Task Report privilege enables the account type to author private test task reports. Can Access Template Report View The Can Access Template Report View privilege enables the account type to access template report view. Can Create Public Template Report The Can Create Public Template Report privilege enables the account type to author public template reports. Can Create Private Template Report The Can Create Private Template Report privilege enables the account type to author private template reports. Can Delete Public Test Task Report The Can Delete Public Test Task Report privilege enables the account type to delete public test task reports. Can Delete Public Template Report The Can Delete Public Template Report privilege enables the account type to delete public template reports. Can Enable Web Query Report The Can Enable Web Query Report privilege enables the account type to enable and define web query reports. Administering Invisible Test Task Pages and Fields Invisible page and field access controls enable project administrators to choose the data is displayed to project team members based on their account type.

188 Pages or data-entry controls that track confidential data may be displayed to project members of one account type for example, management and hidden from other account types. Using controls in the Account Type page, project administrators may define selected fields (data-entry controls) or entire pages as invisible. Administering Read-Only Test Task Pages and Fields Read-only page and field access controls enable project administrators to control which project team members may update project data based on their account type. Pages or data-entry controls that track confidential data may be editable to project members of one account type for example, management and read-only to project members belonging to other account types. Using controls in the Account Type page, project administrators may define selected fields (data-entry controls) or entire pages as read-only. 4.2 Administering Team Groups In DevTest, a team group is an administrator-defined collection of project members who do not necessarily share the same account type, but who share common responsibilities in a work project. Team groups organize support teams into smaller, more useful entities that facilitate the assignment and control of issues and events. Team groups are fully customizable. Project administrators create team groups to represent teams of project members that share the same manager, are working on the same product or component, share the same shift, work from the same office, or any other grouping that makes sense to the organization. Figure 6-2: Project Members and Groups Team groups cannot own work items. But project administrators may use team groups to determine which project team members may own work items in particular workflow states or who may be automatically assigned issues based on administrator-defined rules. Team groups are particularly useful to project administrators when they define work item workflow and routing rules, privileges and access controls, and issue notification and escalation rules. Workflow Team groups may be defined as anapplicable ownerof issues in each workflow state. Only those project members that are members of an applicable team group may be assigned issues in that state. Routing Team groups may be defined as the target of work items automatically routed based on administrator-defined routing rules. Notification and Escalation Team groups may be defined as potential recipients of issue or event notification and escalation messages based on administrator-defined rules. Privileges Team groups may define the scope of the privileges granted to project members of a particular account type. The ability of a project member to view or forward work items may be restricted based on team membership. In the DevTest client, work items may be filtered in the issue list panel by team group. Moreover, report authors may run reports that return project data grouped by team group. Defining Team Groups Using controls in the Team Groups page, project administrators may create any number of team groups and assign any number of project team members to each team group. A project member may belong to multiple team groups. To create groups: 1Select Project Settings > Team Groups in the tree panel. The Team Groups page appears. 2Click The New button. The New Team Group dialog box appears. 3Enter a name in the In The Group Name field.

189 4Click the Ok button. The New Team Group dialog box closes and the group appears in the Existing Groups list of the Groups page. 5Select the group in the in Existing Groups list. 6Select project members in the Groups Member Selection area. A check mark appears next to the name of the project member when they have been added to the group. 7Define the notification list for the group. For step-by-step instructions see Defining Team Group Notification Lists. To rename a group: 1Select Project Settings > Groups in the tree panel. The Groups page appears. 2Highlight a group in the Existing Groups list. 3Click the Rename button. The Edit Team Group dialog box appears. 4Enter a name for the group in the Group Name field. 5Click the OK button. The Edit Team Group dialog box closes. The new group name is displayed in the Existing Groups list. To delete a group: 1Select Project Settings > Groups in the tree panel. The Groups page appears. 2Highlight a group in the Group Team list. 3Click the Delete button. A DevTest Admin warning may appear prompting asking you if you really want to remove this group from the project. 4Click the Yes button. Adding Project Members to Groups Administrators may use controls in the Group page to add project members to groups. To add members to groups: 1Select Project Settings > Groups in the tree panel. 2Select a group in the Group Team list. 3Select project members in the Group Member Selection list. A check mark appears next to the members name when they have been added to the group. Removing Project Members from Groups Administrators may use controls in the Group page to remove project members from groups. To add members to groups: 1Select Project Settings > Groups in the tree panel. 2Select a group in the Group Team list. 3Deselect project members in the Group Member Selection list. No check mark appears next to the members name when they have been removed from the group. Defining Team Group Notification Lists To define group notification lists: 1Select Project Settings > Groups in the tree panel. 2Select the Define Group Notification List button in the Groups page. The Group Notification Manager appears. 3Select a project member in the Available Members list. The Available Members list displays all project members regardless of group or group folder membership. 4Click the Add button. The name of the selected project member is displayed in the Members to be Notified list. To notify all group members click the Notify to All Group Members check box.

190 4.3 Understanding Team Administration All DevTest testing activities are controlled by account typed-based privileges, workflow rules, and access controls. The ability of a DevTest user account to access projects, views, folders, and pages depends on the role (account type) assigned to that user in the project. The account type concept provides administrators with the flexibility to customize project workflow and security to support their unique business requirements. DevTest team representation structures enable development organizations to define sophisticated and flexible workflow rules for managing project data and security. Project-level team administration is the process of defining team management structures (account types, team groups, and group folders), adding user accounts to the project, and assigning appropriate role and responsibilities to each project member. An account type is a set of access rights, privileges, and responsibilities that define the role that a user account plays in a project. Every user account is assigned one account type in each project. A team group is a collection of project team members that do not necessarily share the same account type but who share common responsibilities in the project. A group folder is a mechanism for managing the distribution of work items in a project. 4.4 Administering Account Types, Access Controls, and Privileges In DevTest, privileges and access rights are not granted to user accounts directly, but assigned to administrator-definedaccount types. An account type defines the role assigned to a user account in a project and determines the projects, views, data, and reports that are available to a project team team member through the DevTest clients. Users are assigned an account type when they join a project and assume the rights and privileges granted to that account type when a user s responsibility changes, he or she may be assigned a different account type. In each project, the project administrator is responsible for creating all account types, granting privileges and access rights to those account types, and assigning these account types to each project members based on the role and responsibilities that user performs in the project. Defining Account Types DevTest team representation provides development organizations with maximum flexibility to manage work items in workflow, enforce security, and ensure accountability. All account types are project-specific and defined by the project administrator. In DevTest, organizations are free to define the account types that best represent their business processes. For example, a typical development project might feature five different account types: the Manager account type, the System Architect account type, the Programmer account type, the Tech Support account type, and the QA account type. Figure 6-1: Typical DevTest Project Account Types Every licensed DevTest user may be a member of multiple projects and may be assigned a different account type in each project. To create an account type: 1Select Project Settings > Account Type. 2Click the New button in the Account Type page. The New Account Type dialog box appears. 3Enter a name in the Account Type Name text box. 4 Optional: To copy standard access privilege settings from another account type: Select the Copy Account Type Setting From check box. Select an account type from the dropdown list.

191 5Click the OK button. To rename an account type: 1Select Project Settings > Account Type. 2Click the Rename button. The Rename Account Type dialog box appears. 3Enter a name in the Name field. 4Click the OK button. To delete an account type: 1Select Project Settings > Account Type. 2Select an account type in the Account Type list. 3Click the Delete button. The Delete Account Type warning appears. 4.5 Administering Template Project Privileges and Access Controls Template projects enable testing teams to develop, edit, and manage the test templates that are used to create test tasks in multiple work projects. Template project privileges enable project members to create, edit, and otherwise manage test templates in template projects. For example, a typical template development in a template project might include the following account types: The QA Lead The QA Manager Developer Product Manager The QA Lead account type represents a lead tester who is responsible for managing testers in a work project. This individual understands which templates are needed to create test tasks in the child work projects and can be expected to create and edit create and edit new test templates. The QA Manager account enables a project member to edit and approve test templates for use in work projects as part of workflow process. The QA manager would be assigned privileges that enabled that user to control every aspect of the project. For example, the QA manager might be granted the Can Edit All Templates privilege The Developer and Product Manager account types are often used in organizations that wish to have a review and approval process for tests. It is often helpful to have team members familiar with a feature's requirements or responsible for the implementation review the tests. Administering Template Management Privileges In DevTest, a privilege is a right to perform a task that is granted to project members based on their account type. Test template privileges determine which project team members may submit and manage development test templates in a project. Using controls in the Privileges tab of the Account Type page, project members may grant standard issue management privileges to project members of each account type in a DevTest project Administering Template Management Privileges In DevTest, a privilege is a right to perform a task that is granted to project members based on their account type. Test template privileges determine which project team members may submit and manage development test templates in a project. Using controls in the Privileges tab of the Account Type page, project members may grant standard issue management privileges to project members of each account type in a DevTest project Can Submit Template The Can Submit Template privilege enables project members to create new test templates in a template project. Can Edit own Template The Can Edit own Template privilege enables project members to edit test templates that they created in a template project. Can Edit Template within own Group The Can Edit Template within own Group privilege enables project members to edit test templates created by project members who belong to the same group that they do. For more information on groups see See?dministering Team Groups? Can Edit All Templates The Can Edit All Templates privilege enables project members to edit all of the test templates created in a template project. Can Edit Other User? Notes The Can Edit Other User? Notes privilege enables project members to edit notes created by other project members.

192 Can Perform Group Actions The Can Perform Group Actions privilege enables project members to edit or forward groups of test templates simultaneously. Can Define Public Query The Can Define Public Query privilege enables project members to create queries that are available to all project members. Private queries are only available in the client of the project member who created them. Can Create Template Snapshot The Can Create Template Snapshot privilege enables project members to create a snapshot of a version of a test template. Can Delete Template Snapshot The Can Delete Template Snapshot privilege enables project members to delete snapshots of test templates. Can Perform Rollback Template Snapshot The Can Perform Rollback Template Snapshot privilege enables project members to roll back to a previous version of a test template. Can Create Default Value Template The Can Create Default Value Template privilege enables project members to create default value templates. Can Create Template Folder The Can Create Template Folder privilege enables project members to create template folders in the Template Tree window. Can Delete/Move Template Folder The Can Delete/Move Template Folder privilege enables project members to move or delete the template folders in the Template Tree window. Can Import Template (including Template Folder) The Can Import Template (including Template Folder) enables project members to import template folders and test templates from other template projects. Can Delete Template The Can Delete Template enables project members to delete test templates. Can Define Template Folder Write Access Control The Can Define Template Folder Write Access Control enables project members to determine which project members may create test templates in a specific template folder. Administering Invisible Template Pages and Fields Invisible page and field access controls enable project administrators to choose the data is displayed to project team members based on their account type. Pages or data-entry controls that track confidential data may be displayed to project members of one account type?or example, management?nd hidden from other account types. Using controls in the Account Type page, project administrators may define selected fields (data-entry controls) or entire pages as invisible. To define invisible pages and fields: 1Select Project Settings > Account Type page in the tree panel. 2Select an account type in the Account Types list. Invisible pages and fields may be uniquely defined for each account type. 3Select the Invisible tab. The Invisible tab is only displayed in the Account Type page if Standard Access Controls are enabled in the project. 4Select a page or field in the Invisible tab. The Invisible tab displays all pages and fields in a hierarchical tree structure. An invisible field is a data-entry control that cannot be viewed or edited in the client.data-entry controls may be defined as invisible fields based on account type-based access controls or state-based workflow rules. An invisible page is a system or custom page that cannot be viewed or edited in the client. Any system or custom page except the Description page may be defined as invisible to project account types. Administrators may, however, make all the individual fields in the Description page invisible. Administering Read-Only Template Pages and Fields Read-only page and field access controls enable project administrators to control which project team members may update project data based on their account type. Pages or data-entry controls that track confidential data may be editable to project members of one account type?or example, management?nd read-only to project members belonging to other account types. Using controls in the Account Type page, project administrators may define selected fields (data-entry controls) or entire pages as read-only. The Read-Only tab is only displayed in the Account Type page if standard access controls are implemented in the project. To define read-only pages and fields: 1Select Project Settings > Account Type page in the tree panel. 2Select an account type in the Account Types list. Read-only pages and fields may be uniquely defined for each account type.

193 3Select the Read-Only tab. The Read-Only tab is only displayed in the Account Type page if Standard Access Controls are enabled in the project. 4Select a page or field in the Read-only tab. The Read-Only tab displays all pages and fields in a hierarchical tree structure. A read-only field is a data-entry control that may be viewed, but not edited in the client. Data-entry controls may be defined as read-only fields based on account type-based access controls or state-based workflow rules. A read-only page is a system or custom page that cannot be viewed or edited in the client. Administering DevTest Knowledge Management Privileges DevTest knowledge management privileges enable project team members to access, manage, publish, and update project knowledge in the knowledge view of the DevTest Windows client Using controls in the Knowledge Access tab of the Account Type page, project administrators may grant knowledge access privileges to project team members based on their account type.: Can Access Knowledge View The Can Access Knowledge View privilege enables project members to access the Knowledge view through a template project. Can Build Public Knowledge The Can Build Public Knowledge privilege enables project members to create knowledge items that are available to all template project members. Can Build Protected Knowledge The Can Build Protected Knowledge privilege enables project members to create protected knowledge items in a knowledge project. Can Read Protected Knowledge The Can Read Protected Knowledge privilege enables project members to open and view protected knowledge items in a knowledge project. Can Delete Knowledge The Can Delete Knowledge privilege enables project members to delete knowledge items in a knowledge project. Can Set up Knowledge Tree and Access Control The Can Set up Knowledge Tree and Access Control privilege enables project members to manage knowledge folders in the Knowledge Tree window. Can Unlock Documents Checked Out by Other UsersThe Can Unlock Documents Checked Out by Other Users privilege enables project members to unlock documents that have been checked out or locked by other project members. Administering Report Management Privileges DevTest features a built-in, robust reporting tool for end users. DevTest features over 150 predefined reports and graphs, including customizable text reports for issue lists, graphic reports for defect distribution and trends, tabular reports, lifetime analysis reports, Web Query reports, and time tracking reports at the Issue level and project level Using controls in the Report Access tab of the Account Types page, project administrators may define account type-based access rights to reports in the DevTest Windows client and the DevTest Web client. Distinct access rights may be defined for the reports in the DevTest Windows client and reports in the DevTest Web client. Administrators may make reports visible to an account type by selecting the check box next to the report type in the Client Access and Web Access lists. Reports may be viewed by an account type only if a black check mark appears in the check box next to the report type. The Report view enables users to create public reports. Report view privileges are generally only granted to team members responsible for generating and examining test plan results. Can Access Test Template Report View The Can Access Test Template Report View privilege enables the account type to access the test template report view. Can Create Public Test Template Report The Can Create Public Test Template Report privilege enables the account type to author public test template reports. Can Create Private Test Template Report The Can Create Private Test Template Report privilege enables the account type to author private test template reports. Can Delete Public Test Template Report The Can Delete Public Test Template Report privilege enables the account type to delete public test template reports. Can Create Web Query Report The Can Create Web Query Report privilege enables the account type to create web query reports. 4.6 Administering Project Members In DevTest, all development and project management tasks are managed and tracked by a project team consisting of multipleproject team members.a project team member is a licensed DevSuite user that has been assigned an account type. A DevSuite user account cannot access a DevTest project unless they have been assigned a DevTest (or DevSuite) license by the system administrator and a project account type by the DevTest project administrator.

194 Using controls in the Project Member page, project members may add user accounts to DevTest projects, assign account types to user accounts, and view project member information. Adding User Accounts to Projects To add user accounts to a project: 1Select Project Setting > Project Member in the tree panel. 2Select a user from the Available Members list. Administrators may use the SHIFT and CTRL keys to select multiple users for account type assignment. 3Click the Add button. The Account Type dialog box appears. 4Select an account type option from the Account Type dropdown list. 5Click the OK button. The user account appears in the Members in Project list. Inactive user accounts are displayed with the word Inactive to show they are inactive. Editing Project Member Account Types To edit a project member account types: 1Select Project Setting > Project Member in the tree panel. 2Select a user from the Members in Project list. 3Select an account type option from the Account Type dropdown list. Removing User Accounts from Projects To remove a user account from a project: 1Select Project Setting > Project Member in the tree panel. 2Select a user from the Members in Project list. 3Click the Remove button. The user account disappears from the Members in Project list and appears in the Available Members list. Viewing Project Member Information To view project member data: 1Select the Project Member page in the Admin Tree window. 2Select a user account in the Available Members list or Members in Project list. 3Click the View button. The User Information page appears. 4.7 Administering Group Folders DevTest team representation provides development organizations with maximum flexibility to manage work items in workflow, enforce security, and ensure accountability. Group folders are an optional DevTest feature that enables development organizations to more effectively manage the distribution of work assigned to a group of project team members. Issue ownership In DevTest, a work item is at all times owned by a project team member or group folder. Unlike team groups which cannot own work items, work items may be assigned to group folders as if they were actual project members. Using group folders, development organizations may store a pool of work items that are held in common and manually distribute those issues. Any issue that may be assigned to a project team member may be assigned to a group folder. Group folders may be assigned work items based on workflow and routing rules. Workflow Group folders may be defined as anapplicable ownerof issues in each workflow state and project members may assign work items to an applicable group folders as if it were another project member. Routing Group folders may be defined as the target of work items automatically routed based on administrator-defined routing rules. Security Access to the issues assigned to a group folder is controlled by account type-based access controls. Only project members with the appropriate access rights may View, Put, or Get issues in a group folder. Used in this way, group folders serve as a buffer between project members and their workload. For example, an administrator may require that all issues forwarded to the QA Testing state are assigned to the QA Testing group folder. The QA team leader belongs to the Manager account type and so has been granted the Get privilege. The QA team leader may

195 view issues assigned to team folder and then assign those issues to specific team group members based on their workload or expertise. Enabling Group Folders Group folders are an optional DevTest feature that must be enabled by the project administrator on a project-by-project basis. To enable support for group folders in a project, select the Enable Group Folder Support check box in the Group Folders page. Defining Group Folders A group folder is a mechanism that enables development organizations to assign and store a pool of common work items and serves as a buffer between project members and their workload. Every group folder is defined by its name, a team group, account type-based access controls, and (optionally) an notification list. Using controls in the Group Folder page, project administrators may create group folders, define group folder membership, and group folder access controls. In DevTest, every group folder is owned by an administrator-defined team group or by the All Members user variable. Account type-based access controls enforce folder-level security. To access or manage the work items assigned to a group folder, the user must be long to an account type that has been granted the appropriate access rights for that folder. An account type may be granted three access rights for each group folder.: View The View access right enables the user to view the issues assigned to a group folder. Put The Put access right enables the user to forward issues to a group folder. Get The Get access right enables the user to get issues assigned to a group folder. To create a group folder: 1Select Project Settings > Group Folder in the tree panel. The Group Folder page appears. 2Click the New button. The New Group Folder dialog box appears. 3Define a unique name and description of the group folder. The name of the group folder is displayed in the Team Member dropdown list of the DevTest clients. 4Select a team group from the Owner Group dropdown list. The Owner Group dropdown list displays all team groups defined in the project as well as the All Members user variable. 5Click the OK button. The New Group Folder dialog box closes and the group folder is displayed in the Group Folder list. 6To grant folder access rights to an account type, select the View, Put, and Get controls in the Folder Access Control list. A red check mark indicates that the access right is granted to all project members belonging to that account type. To edit a group folder: 1Select Project Settings > Group Folder in the tree panel. The Group Folder page appears. 2Select a group folder in the Group Folder list. 3Click the Edit button. The Edit Group Folder dialog box appears. 4Enter a name in the Folder Name field. 5Select a group from the Owner Group dropdown list. 6Enter notes into the Description text area. 7Click the OK button. To delete a group folder: 1Select Project Settings > Group Folder in the tree panel. The Group Folder page appears. 2Select a group folder in the Group Folder list 3Click the Delete button.

196 A confirmation dialog box appears. 4Click the Yes button. Defining Group Folder Notification Lists Group folder notification enables development teams to ensure that appropriate stakeholders are notified by whenever a work item is assigned to a particular group folder. Unique notification list may be defined for each group folder in a project. To define a group folder notification list: 1Select Project Settings > Group Folder in the tree panel. The Group Folder page appears. 2Click the Define Folder Notification List button. The Group Folder window appears. 2Add or remove project team members from the notification list. The Available Members list displays all project members regardless of group or group folder membership. To add a project member to the notification list, select the project member in the Available Members list and click the Right Arrow button. To remove a project member to the notification list, select the project member in the Members To Be Notified list and click the Left Arrow button. 3 Optional: To notify all group members click the Notify to All Group Members check box. Chapter 5 Template Project Administration 5.1 Administrating Template Projects In DevTest, a template base project is a project for creating, defining, and managing a test library through the creation and management of test templates. Once defined test templates may be used to generate test tasks in one or more child work projects. Template project administration is the process of defining test template management structures, identifying the data managed and tracked as test templates, defining project team structures, and enabling and defining optional project features including environmental variables, verification points, template feedback notes, and TestLink integration. Template Management Structures In DevTest, template project customization is the process of defining test template and test template management structures. All test template management structures are manifested in the test template view. Test Template Folder Test Template Each template project is the parent of many child work projects. Template structures and features enabled in the parent template project are manifested in all child work projects.test template management structures include test template folders and test templates. Team Administration Every test template project is defined by unique team management structures account types, team groups, and team folders. Template base project administrators are responsible for assigning the appropriate account types to all project team members. Test Template Folder Test Template Optional Features Template project administrators must enable and define five features before these features can be used in a DevTest implementation: Template WorkflowTemplate workflow defines the test template management lifecycle and rules for managing test templates within that lifecycle. The template workflow is typically used to manage an approval process for the creation and modification of test coverage. Environmental VariablesAn environmental variable represents the applicable environments that a particular test can be run against. Every test template may be defined by one or more environmental variables which in turn represent multiple environmental variable (EV) values. One test tasks may be generated for every EV value permutation of a test template. EV's act as a filter when planning test coverage and they can be used to create multiple test tasks when a test template is applicable for more than one environment. Verification PointsVerification points enable testing teams to track multiple validation points in a single test case. Each verification point defines a different checkpoint (expected result) that the tester must confirm during the execution of that test task. Template Feedback NotesTest template feedback notes enable work project members to pass information to test template project members about the test templates used to create test tasks and, optionally, to change the template state of those test templates. Testlink IntegrationTestLink integration enables testing organizations to integrate their test template and test task management project with third party automated testing solutions. 5.2 Administrating Test Template Folders In test template projects, test templates are managed in a hierarchical tree structure the test template tree that organizes test templates in the workspace, implements security, and enforces good development practices. Every area of development within the template tree framework is represented by a template folder. A template folder is a discreet area of work that corresponds a test case. Customizing Add Template Folder Pages In the DevTest client, project members may create test template folders and define test template folder access controls, applicable environmental variables, and applicable work projects using the Add Test Template Folder window.

197 The Add Template Folder page may display multiple system pages and custom pages including: Applicable ProjectThe Applicable Project system page enables project members to restrict access to the test templates contained in a test template folder. Environmental VariableThe Environmental Variable system page enables project members to choose which environmental variables may be included in a test template and which environmental variable values may be used for that environmental variable in the test tasks based on the test template. Folder DescriptionThe Folder Description custom page enable project members to define template folder properties. Write AccessThe Write Access system page enables project members to restrict which project members may create test templates in a template folder by project account types. To customize template submission pages: 1Select Template Folder GUI Settings > Function Pages > Submission Page in the Admin Tree window. The Template Folder Submission page appears. 2Add or remove system or custom pages to the function page. Four pages may be displayed in the Template Folder Submission page: the Applicable Project page, the Environmental Variable page, the Folder Description page, and the Write Access page. To add pages select a page in the Available Pages list and click the Right arrow button. To remove pages select a page in the Working Pages list and click the Left arrow button. 3 Optional:To change the title of the function page, enter a new title in the Page Display Name field. 4 Optional: To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button. Customizing Edit Template Folder Pages The Template Folder Editing function page enables template project members to update template folder properties and, depending on the pages displayed, manage how the test templates contained in a template folder are used in a project. Administrators may determine which pages are displayed in the Template Folder Editing form by adding custom pages and system pages to the Template Folder Editing function page in DevTest Admin: Applicable Project System PageThe Applicable Project system page enables project members to restrict access to the test templates contained in a test template folder to designated work projects. Environment System PageThe Environmental system page enables project members to choose which environmental variables are used in a test template and which environmental variable values may be used for that environmental variable in the test tasks based on the test template Change Log System PageThe Change Log system page enables project members to view a readonly log of changes made to the template folder. Folder Order System PageThe Folder Order system page enables project members to determine the order of the template folders displayed in the Template Tree window. Notes System PageThe Notes system page enables project members to add notes or note attachments to template folders. Template Order System PageThe Template Order system page enables project members to define the order of the test templates contained in a template folder. Template and work project members may sort records based on template order. Time Report System PageThe Time Report system page enables project members to track the time used to perform test tasks based on the test templates contained in a particular template folder. Folder Description Custom PageThe Folder Description custom page enable project members to define template folder properties. To customize the edit template folder page: 1Select Template Folder GUI Settings > Function Pages > Submission Page in the Admin Tree window. The Template Folder Submission page appears. 2Add or remove system or custom pages to the function page. To add pages select a page in the Available Pages list and click the Right arrow button. To remove pages select a page in the Working Pages list and click the Left arrow button. 3To change the title of the function page, enter a new title in the Page Display Name field. 4To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button. 5.3 Administering Test Templates Customizing Add Test Template Pages The Template Submission function page enables template project members to define test template properties. Administrators may determine which pages are displayed in the Template Submission form by adding custom pages and system pages to the Template Folder Submission function page in DevTest Admin: Folder Description Custom PageThe Folder Description custom page enable project members to define template folder properties. Environment System PageThe Environmental system page enables project members to choose which environmental variables are used in a test template and which environmental variable values may be used for that environmental variable in the test tasks based on the test template. To customize the add test template page: 1Select Template Folder GUI Settings > Function Pages > Submission Page in the Admin Tree window. The Template Folder Submission page appears. 2Add or remove system or custom pages to the function page. To add pages select a page in the Available Pages list and click the Right arrow button. To remove pages select a page in the Working Pages list and click the Left arrow button. 3To change the title of the function page, enter a new title in the Page Display Name field. 4To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button. Customizing Edit Test Template Pages The Template GUI Editing function page enables template project members to update test template properties. Template project administrators may determine which pages are displayed in the Template Editing page by adding or removing system and function page to the Template GUI Editing function page: Environment System PageThe Environmental system page enables project members to choose which environmental variables are used in a test template and which environmental variable values may be used for that environmental variable in the test tasks based on the test template. Notes System PageThe Notes system page enables project members to add notes or note attachments to template folders.

198 Snapshot System PageThe Snapshot system page enables project members to take a snapshot of a test template at a particular pointin-time and revert to that snapshot. Template Description Custom PageThe Template Description custom page enable project members to define test template properties. To customize template submission pages: 1Select Template Folder GUI Settings > Function Pages > Submission Page in the Admin Tree window. The Template Folder Submission page appears. 2Add or remove system or custom pages to the function page. To add pages select a page in the Available Pages list and click the Right arrow button. To remove pages select a page in the Working Pages list and click the Left arrow button. 3To change the title of the function page, enter a new title in the Page Display Name field. 4To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button. Customizing Template Detail Pages The pages displayed in the Template Detail window enable template project members to update test template properties. Administrators may determine which pages are displayed in the Template Detail window by adding custom pages and system pages to the Template Detail function page in DevTest Admin: Environment System PageThe Environmental system page enables project members to choose which environmental variables are used in a test template and which environmental variable values may be used for that environmental variable in the test tasks based on the test template. History System PageThe History system page enables project members to view a read-only history of a test template. Linked Task System PageThe Linked Task system page enables project members to view test tasks linked to test templates. Notes System PageThe Notes system page enables project members to add notes or note attachments to template folders. Snapshot System PageThe Snapshot system page enables project members to take a snapshot of a test template at a particular pointin-time and revert to that snapshot. Testlink System PageThe Test Link system page enables project members to run automated test scripts. Template Description Custom PageThe Template Description custom page enable project members to define test template properties. To customize the test template detail page: 1Select Template GUI Settings > Function Pages > Submission Page in the Admin Tree window. The Template Submission page appears. 2Add or remove system or custom pages to the function page. To add pages select a page in the Available Pages list and click the Right arrow button. To remove pages select a page in the Working Pages list and click the Left arrow button. 3To change the title of the function page, enter a new title in the Page Display Name field. 4To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button. Customizing Test Template Forward Pages The Template Forward function page enables template project members to forward test templates to other project members and, optionally, to update test template properties. Administrators may determine which pages are displayed in the Template Forward form by adding custom pages to the Template Folder Submission function page in DevTest Admin. To customize template submission pages: 1Select Template GUI Settings > Function Pages > Submission Page in the Admin Tree window. The Template Submission page appears. 2Add or remove system or custom pages to the function page. To add pages select a page in the Available Pages list and click the Right arrow button. To remove pages select a page in the Working Pages list and click the Left arrow button. 3To change the title of the function page, enter a new title in the Page Display Name field. Customizing Test Template Snapshot Pages The Template Snapshot function page enables users to take a snapshot of test templates and save them in the project. Using the Snapshot page users can save several different versions of a test template and rollback to previous versions of the test template. Administrators may determine which pages are displayed in the Snapshot page by adding custom pages to the Template Folder Snapshot function page in DevTest Admin. Generally, the snapshot page is used to take a snapshot of general test template properties such as those displayed in the Template Description custom page. To customize template submission pages: 1Select Template GUI Settings > Function Pages > Submission Page in the Admin Tree window. The Template Submission page appears. 2Add or remove system or custom pages to the function page. To add pages select a page in the Available Pages list and click the Right arrow button. To remove pages select a page in the Working Pages list and click the Left arrow button. 3To change the title of the function page, enter a new title in the Page Display Name field. Customizing Default Value Template Pages The Default Value Template manager enables template project members to pre-define the field values for the test templates created in the Template view. Project administrators may add an unlimited number of custom pages to the Default Value Template function page. Each custom page that the project administrator adds to the Default Value function appears in the Default Value Template manager. The Test Template Default Value Template function page enables project administrators to define which pages template project members may pre-define when they create test templates. To customize the default value template page: 1Select Template GUI Settings > Function Pages > Submission Page in the Admin Tree window. The Template Submission page appears. 2Add or remove system or custom pages to the function page. To add pages select a page in the Available Pages list and click the Right arrow button. To remove pages select a page in the Working Pages list and click the Left arrow button. 3To change the title of the function page, enter a new title in the Page Display Name field. Customizing Template Group Change Pages The Template Group Change function page enables template project members to change test template properties for a group of test templates.

199 Administrators may determine which pages are displayed in the Template Group Change form by adding system pages and custom pages to the Template Group Change function page in DevTest Admin: The Environmental Variable system page enables project members to choose which environmental variables are used in a test template and which environmental variable values may be used for that environmental variable in the test tasks based on the test template. Administrators may add any number of custom pages to the Template Group Change function page. To customize template submission pages: 1Select Template GUI Settings > Function Pages > Submission Page in the Admin Tree window. The Template Submission page appears.2add or remove system or custom pages to the function page. To add pages select a page in the Available Pages list and click the Right arrow button. To remove pages select a page in the Working Pages list and click the Left arrow button. 3To change the title of the function page, enter a new title in the Page Display Name field. 4To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button. Customizing Template Group Folder Pages The Template Group Folder function page enables template project members to define which pages appear in the Template Detail window of template projects. Administrators may determine which pages are displayed in the Template Group Folder form by adding custom pages and system pages to the Template Group Folder function page in DevTest Admin: Administrators may add any number of custom pages to the Template Group Change function page. To customize template submission pages: 1Select Template GUI Settings > Function Pages > Submission Page in the Admin Tree window. The Template Submission page appears. 2Add or remove system or custom pages to the function page. To add pages select a page in the Available Pages list and click the Right arrow button. To remove pages select a page in the Working Pages list and click the Left arrow button. 3To change the title of the function page, enter a new title in the Page Display Name field. 5.4 Administering Template Project Workflow Template project workflow rules determine the way that test templates are managed in DevTest work projects. All DevTest workflow rules are based on the relationship between three entities: workflow states, transitions, and applicable owners. Project administrators may define workflow rules to manage test templates that are based on template states or the transitions between template states. Template workflow rules define the how test templates are managed in a template based project. Workflow rules define which members may own a test template, what changes may be made to test template, or even which controls are displayed in the test template itself. Creating Template States In DevTest template base projects, all test template management tasks are based on template states. A template state represents a particular stage in the life cycle of a test template. The administrator-defined workflow rules are based on template states or state-to-state transitions. At all times during template workflow, access to a test template including the ability to view and update is controlled by the template state. Template states might include: Approved Draft Pending Approval All template states are defined in a template project within DevTest Admin. The template states are shared by every work projects based on that parent template project. Work project administrators may define their own workflow rules to manage these template states and need not utilize every template state inherited from the parent template project. Template administrators may create as many workflow states as they deem necessary to implement workflow in their work projects. To create template states: 1Select thetesttaskstatepage beneath the State Definition folder in a test template project in DevTest Admin. The State page appears. All currently defined workflow states and their current status appear in the State list. 2Click the New button. The Add anewstatedialog box appears. 3In the State text box enter the state name. 4In the Status area, select a status property for the state. Select the Open radio button if a user can open an issue in this workflow state. When a user opens an issue, the issue must be in one of these workflow states. Select the Closed radio button if a user can close an issue in this workflow state. When a user closes an issue, the issue must be in one of these workflow states. 5Click the OK button. Defining Default Template States Template project administrators may use thetaskdefaultstatedropdown list in thetesttaskstatepage to define the default template state for all test templates created in child work projects. To define default template states: 1Select thetesttaskstatepage beneath the State Definition folder in a test template project in DevTest Admin. The State page appears. All currently defined workflow states and their current status appear in the State list. 2Select a default template state in thetaskdefaultstatedropdown list. Editing Template States Template project administrators may use thetesttaskstatepage to edit work project workflow states. To edit test template workflow states: 1In the Template Base project Tree window select the State Definition folder. 2Select thetesttaskstatepage. The State page appears. 3Select a workflow state in the State list. 4Click the Edit button. The Edit the State dialog box appears. 5 Optional:To change the title of the workflow state, enter a new title in the State text box. 6 Optional:To change the status of the progress, select an option in the Status area. 7 Optional:To make data-entry controls in this workflow state read-only, select the Read Only in this State check box.

200 8Click the OK button. Enabling State-to-State Transition Options The State to State Transition option enables the administrators to define workflow rules which manage the transitions between template states. To enable the state-to-state option, select the State-to-State Transition check box. State-to-state workflow rules restrict template state changes. For more information see See Defining State Transition Workflow Rules. Enabling State-based Applicable Owner Rules The Applicable Owners option enables project administrators to specify the user accounts, account types, and groups that may own a test template based on its template state. To enable the applicable owners option, select the Applicable Owners check box. Applicable owner workflow rules enable the administrator to ensure that test templates are only assigned or forwarded to a designated applicable owner. For more information see See Defining Applicable Owner Workflow Rules. Enabling State-based Read-only Field Rules The Read-Only Fields option enables project administrators to designate controls as read only in particular template states. To enable the read-only fields option, select the Read-only Fields check box. If this option is enabled, read-only workflow rules may be defined that prevent controls from being updated when a test template is in certain template states. For more information see See Defining Read-Only Workflow Rules. Enabling State-based Invisible Field Rules The Invisible Fields option enables project administrators to designate test template controls as invisible when that test template is in certain template states. To enable the invisible controls option, select the Invisible Fields check box. For more information see See Defining Invisible Fields Workflow Rules. Enabling State-based Mandatory Field Rules The Mandatory Fields option enables project administrators to designate test template controls as mandatory when that test template is in certain template states.mandatory controls must be completed before the template state of the test template can be changed. To enable the mandatory controls option, select the Mandatory Fields check box. For more information see See Defining Mandatory Fields Workflow Rules. Enabling State-based Access Controls The Who Can Change option enables project administrators to restrict which project members may make changes to test templates based on their workflow states. Who Can Change rules may be based on the current workflow state of the test template, or they may be based on state transitions. To enable the who can change option, select the Who Can Change check box. For more information see See Defining Who Can Change Workflow Rules. To enable test template workflow properties: 1Select the Options page beneath the State & Workflow folder in a work project in DevTest Admin. The Options page appears. 2Select the appropriate check box to enable each workflow property option. Administrators may enable the following workflow properties in each template project: 3If the State-to-State Transition option has been enabled, the administrator may select a workflow option from the Who Can Change dropdown list. Current state workflow rules limit who can change template states based on the current state of the test template. Transition workflow rules define who can change template states based on state-to-state transitions. Defining State Transition Workflow Rules Template project administrators may use tools in the State Transition tab of the Template Workflow page to define transitions between template states in template projects. State transition workflow rules enable administrators to ensure that project members may only change the template state of test templates to appropriate states. For example, administrators may define state transition workflow rules ensure that project members can only change the workflow state of a test template from State A to State B and not from State A to State C. Administrators may only define state transition workflow rules if they have enabled the State-to-State Transition workflow option in the Options page. To define state transition workflow rules: 1Select the Settings page beneath the State& Workflow folder in the Tree window. The Settings page appears. 2Select the State Transition tab. The State Transition page appears. 3Highlight a workflow state in thetaskstatetext box. 4Select test templates in theavailablenextstatetext box. The options displayed in thenextstatefield represent the template states that may follow the template state highlighted in thetaskstatetext box. Defining Applicable Owner Workflow Rules Template project administrators may use tools in the Applicable Owner tab of the Template Workflow page to define applicable owner rules and default applicable owners for test templates. Applicable owner rules determine which project members may own a test template based on the template state of the test template. Default applicable owners are the default owners for test templates in a particular template state. An applicable owner may be a user, an account type, a member of a group or group folder, or any of a number of a predefined system users (Unassigned, Submitter, Current Owner and Previous Owner). Ownership means a user has privileges and responsibilities for the test template that other users do not have. Applicable owner workflow rules enable managers to direct test templates to individuals or teams with particular skills or expertise. Work project administrators may enable test template ownership for five different types of applicable owners: account types, groups, group folders, system applicable owners, and user accounts. An account type applicable owner represents an administrator-defined account type. A group applicable owner represents an administrator-defined group of account types. A group folder applicable owner represents an administrator-defined group of account types. System applicable owners represent system variables that may be assigned ownership of test templates in particular template states. Administrators may enable five different types of system applicable owners: {Unassigned], {Submitter}, {Current Owner}, and {Previous Owner}. A user applicable owner represents a user account. Administrators may only define applicable owner workflow rules if they have enabled the Applicable Owner workflow option in the Options page.

201 To define applicable owners workflow rules: 1Select the Template Workflow page in the State Definition folder of a template base project. The Template Workflow page appears. 2Select a template state in the Template States list. 3Select the Applicable Owners tab. The Applicable Owners page appears. 4Select a template state in thetaskstatelist. 5Select all appropriate workflow applicable owners in the Applicable Owners list. Administrators may assign as many applicable owners as needed for each template state. 6Select a default applicable owner option in the Default Owner dropdown list. Default applicable owners are by default responsible the test templates in each workflow state. Defining Applicable Owners in the User Manager Project administrators may define applicable owner workflow rules using controls in the User Manager. The User Profile page in the User manager enables administrators to define or update applicable owner rules for each user account across all template states. Applicable owner workflow rules determine which project members may own a test template in a particular template state. All changes made to the profile of a user account in the User Manager are immediately implemented in project workflow rules. To apply ownership in the user profile: 1Select System > User Manager in the tool menu. The User Manager appears. 2Select a project member in the User Manager. 3Click the Profile button. The User Profile page appears. 4Click the Workflow page. The Workflow tab allows users to specify applicable ownership rules for the selected user. All predefined workflow states will be listed in the window. 5Select the appropriate test template states. The user may own test templates in all selected template states. 6Click the OK button. Defining Who Can Change Workflow Rules Work project administrators may use tools in the Who Can Change tab of the Settings page to define which project members may change the template state of a test template. Who Can Change workflow rules are based either on template states or the transition between template states. Current state workflow rules designate which project members may change template states based on the current state of the test template. Transition workflow rules designate which project members may change template states based on the transitions between tasks states. Administrators may grant project members the ability to change the template state of test template based on either on current states or on the transitions between template states. The workflow rules defined in the Who Can Change tab depend on the Who Can Change option selected by the project administrator in the Options page. If the administrator has enabled the Based on thecurrentstateoption in the Options page, Who Can Change workflow rules define which project members may change the template states of test templates based on the current template state of the test template. If the administrator enabled the Based on State Transition option in the Options page, Who Can Change workflow rules restrict the options available to project members when they change the template state of test templates. Note:Account type privileges override the Who Can Change workflow rules. Even though administrator-defined Who Can Change workflow rules may entitle a project member to change template states, that project member may only change the template state of template states for which they have been granted the edit privilege, based on their account type. Administrators may only define who can change workflow rules if they have enabled the Who Can Change workflow option in the Options page. To define current state workflow rules: 1Select the Settings page beneath the State & Workflow folder in the Tree window. The Settings page appears. 2Select the Who Can Change tab. The Who Can Change page appears. 3Select a template state in thetaskstatetext box. 4Select one or more project members in the Member Name text box. To define transition workflow rules: 1Select the Template Workflow page in the State Definition folder of a template base project. The Template Workflow page appears. 2Select a template state in the Template States list. 3Select the Who Can Change tab. The Who Can Change page appears. 4Select a template state in thetaskstatetext box. 5Highlight a template state in thenextstatetext box. The options displayed in thenextstatetext box represent all of the template states that may follow the template state selected in thetaskstatetext box based on state transition workflow rules. If a template state does not appear in thenextstatetext box, no transition is possible between the two template states. For more information see See Defining State Transition Workflow Rules. 6Select one or more project members in the Member Name list. The selected project members may change the template state of a test template from the template state selected in thetaskstatetext box to the template state highlighted in thenextstatetext box. Defining Read-Only Workflow Rules In DevTest, a read-only field represents a data-entry control that may be viewed but not edited in the client in a particular workflow state. Template workflow rules enable project administrators to define one or more test template properties as read-only in each template state. Template properties managed in the in the Description,CurrentState, and all custom pages may be defined as mandatory in template workflow. To define read-only workflow rules: 1Select the Template Workflow page in the State Definition folder of a template base project. The Template Workflow page appears. 2Select a template state in the Template States list.

202 3Select the Read Only Fields tab. The Read Only tab is only displayed in the Template Workflow page if read-only workflow rules have been enabled in the project. For more information see See Enabling State-based Read-only Field Rules. 4Select one or more fields in the Read Only text box. The Read-only Fields list displays the following test template properties: TemplateStateTemplate Owner Expected ResultTitle E. Setup TimeE.Test Time Test Procedure The selected fields are designated as read-only when a test template is in the selected template state. Defining Invisible Fields Workflow Rules In DevTest, a invisible field represents a data-entry control that is not displayed in the client in a particular workflow state. Template workflow rules enable project administrators to define one or more test template properties as invisible in each template state. Template properties managed in the in the Description,CurrentState, and all custom pages may be defined as mandatory in template workflow. To define invisible field workflow rules: 1Select the Template Workflow page in the State Definition folder of a template base project. The Template Workflow page appears. 2Select a template state in the Template States list. 3Select the Invisible Fields page. The Invisible Field tab is only displayed in the Template Workflow page if read-only workflow rules have been enabled in the project. For more information see See Enabling State-based Invisible Field Rules 4Select one or more fields in the Invisible Fields text box. The Invisible Fields list displays the following test template properties: TemplateStateTemplate Owner Expected ResultTitle E. Setup TimeE.Test Time Test Procedure The selected fields are designated as invisible when a test template is in the selected template state. Defining Mandatory Fields Workflow Rules In DevTest, a mandatory field represents a property that must be defined in a particular workflow state. Template workflow rules enable project administrators to mandate that one or more test template properties be defined in each template state. Template properties managed in the in the Description,CurrentState, and all custom pages may be defined as mandatory in template workflow. To define mandatory fields workflow rules: 1Select the Template Workflow page in the State Definition folder of a template base project. The Template Workflow page appears. 2Select a template state in the Template States list. 3Select the Mandatory Fields tab. The Mandatory Fields tab is only displayed in the Template Workflow page if read-only workflow rules have been enabled in the project. For more information see See Enabling State-based Mandatory Field Rules. 4Select one or more fields in the Mandatory Fields list..the Mandatory Fields list displays the following test template properties: TemplateStateTemplate Owner Expected ResultTitle E. Setup TimeE.Test Time Test Procedure The selected fields are designated as mandatory when a test template is in the selected template state. 5.5 Administrating Environment Variables In DevTest, an environmental variable identifies an environmental factor that may performance of a feature or function during a test cycle examples include the operating system, hardware, network infrastructure, or browser types. Each environmental variable represents one or more environmental variable values (EV values). EV values are the specific instances of an environmental variable. For example, the Web Browser environmental variable may represent three different EV values: Internet Explorer, Firefox, and Safari. When a test template includes multiple environmental variables, project teams may generate one test task for eachpermutationof EV values present in the parent test template. A permutation represents one combination of all of the possible EV values present in the test template.: Test templates are particularly powerful when they include multiple environmental variables each of which represents multiple EV values. A test template that includes two environmental variables (X and Y) that represent three EV values a piece may be used to create nine test tasks (3 x 3).

203 A test template that includes three environmental variables that represents three EV values a piece may be used to create 18 test tasks (3 x 3x 3). By building environmental variables into test templates, testing organizations may create powerful test templates that may be used to generate many different test tasks that are appropriate to different testing environments. Environmental variable administration the process of enabling the environmental variable features. identifying environmental factors, defining environmental variable assignment options, creating the environmental variables and EV values, defining the maximum number of EV permutations per test template, and defining the maximum number of EV permutations that may be selected in each test template. Enabling Environmental Variables Environmental variables are an optional DevTest feature that must be enabled on a project-by-project basis. To enable environmental variables, select the Enable Environmental Variables check box in the Features Options page in the tree panel. Defining Environment Variable Assignment Options In DevTest, environmental variables may be assigned to test templates on atemplate-by-template basisorfolder-by-folder basis. Template-by- TemplateThe By Template option enables project members to assign environmental variables to each test template individually. Each test template contained in a template folder may be assigned a unique set of environmental variables. Folder-by-FolderThe By Template Folder option enables project members to assign environmental variables to all of the test templates contained in a particular template folder. Every test template within a template folder uses the same set of environmental variables. To define environmental variable assignment options: 1Select Project Settings > Environment Variable Settings in the tree panel. 2Select an option in the Environment Variables Option area. To assign environmental variables on a template-by-template basis, select the By Template option button. To assign environmental variables on a folder-by-folder basis, select the By Template Folder option button. Defining Environmental Variables To add an environmental variables: 1Select Project Settings > Environment Variable Settings in the tree panel. 2Click the New button in the Environment Type area. The Add Environment Type dialog box appears. 3Enter a name for the environment variable in the Name text box. 4Enter a brief description of the environment variable in the Description text area. 5Click the OK button. The Add Environment Type dialog box closes and the new environmental variable is displayed in the Environment Type list. To edit an environmental variable: 1Select an environmental variable in the Environment Type list of the Environment Variable Settings page. 2Click the Edit button in the Environment Type area. The Edit Environment Type dialog box appears. 3Update the title of the environmental variable in the Name text box. 4Update the description of the environmental variable in the Description text box. 5Click the OK button. The Edit Environment Type dialog box closes. To delete an environmental variable: 1Select an environmental variable in the Environment Type list of the Environment Variable Settings page. 2Click the Delete button in the Environment Type area. A confirmation dialog box appears. 3Click the Yes button. Defining Environmental Variable Values An environmental variable value (EV value) is a specific value that is substituted for an environmental variable when test tasks are generated from a test template. For example, a Web Browser environmental variable may represent three EV values: the Firefox, Internet Explorer, and Safari EV values. To add an environmental variable value: 1Select Project Settings > Environment Variable Settings in the tree panel. 2Select an environmental variable in the Environment Type list. 3Click the New button in the Environment Value area.

204 The New Environment Type Value dialog box appears. 4Enter a name for the EV value in the Name text box. 5Click the OK button. The New Environment Type Value dialog box closes and the EV value is displayed in the Environment Value list. To add an environmental variable value: 1Select an environmental variable in the Environment Type list of the Environment Variable Settings page. 2Select an EV value in the Environment Value list. 3Click the Edit button in the Environment Value area. The Edit Environment Type Value dialog box appears. 4Update the name of the EV value in the Name text box. 5Click the OK button. The Edit Environment Type Value dialog box closes and the updated EV value is displayed in the Environment Value list. Defining Maximum Possible EV Value Permutations An EV permutation represents a combination of environment factors such as the operating system, hardware, and network architecture that may affect the performance of an application in a test cycle. Each combination of EV values defines a specifictesting environment. Test templates with built-in environmental variables enable test planners to generate test tasks for many different environments using a single test template. Using controls in the Environmental Variable Settings, template project administrators may define the limit the number EV value permutations that may be generated in each test template. The maximum number of possible EV value permutations is To define the maximum number of EV permutations: 1Select the Project Settings > Environmental Variable Settings in the tree panel. 2Enter a number in the Maximum Number of Possible Environmental Variable Permutations text box. This number determines the maximum number of total environmental variable permutations that may be generated in a test cycle. 3Enter a number in the Maximum Number of Possible Environmental Variable Permutations text box. This number determines restricts number of total environmental variable permutations that may be selected to generate test tasks in a test cycle. Defining Maximum Selectable EV Permutations An EV permutation represents a combination of environment factors such as the operating system, hardware, and network architecture that may affect the performance of an application in a test cycle. Each combination of EV values defines a specifictesting environment. Test templates with built-in environmental variables enable test planners to generate test tasks for many different environments using a single test template. Using controls in the Environmental Variable Settings, template project administrators may limit the number EV value permutations that may be selected to create test tasks based on each test template. << div/> Chapter 6 Test Planning Administration 6.1 Understanding DevTest Test Planning DevTest simplifies the management, assignment, and scheduling of test cycles by organizing testing in distinctrelease cyclesandtest cycles. This twotiered approach simplifies test management by leveraging the power of test templates and environmental variables to create test cycles for different environments and to provide instant access to summary statistics. A release cycle defines the scope and objectives of a group of test cycles the test schedules, test templates, environments, and testing teams that are applicable to the test cycles within that release cycle. A test cycle is a group of tests that are generated within a release cycle. Test cycle planning is the act of choosing appropriate test templates and environments, generating test tasks, and assigning those test tasks to testers for test execution. The scope and depth of each test cycle is determined by the applicable test templates, environments, and project members that are defined at the release cycle level. Every test cycle is the child of a release cycle and test cycle options are limited to those options defined as applicable to that release. Test planning administration is the defintion and customization of tools that enable test planners to define and manage release cycles and test cycles in the planning view of a work project. Using planning wizards project members may generate multiple test tasks from each test template utilizing each templates built-in environmental variables and EV values. Project administrators may make relatively few customizations to the planning wizards in DevTest projects. Planning wizard customization consists of three tasks: Project administrators may change the title of all planning wizard pages. Project administrators may add and format page descriptions in each planning wizard page. Project administrators may customize headers and enable target data reporting in the Target Data Planning wizard. 6.2 Administering Planning Folders In DevTest, all test planning the definition of the scope and objectives is managed in release cycles. A release cycle defines the scope and objectives of a group of test cycles the test schedules, test templates, environments, and testing teams that are applicable to the test cycles within that release cycle.

205 DevTest test planning is managed in theplanning tree, a hierarchical tree structure that represents products, releases, and test cycles as a series of folders and subfolders. Just as the test template tree organizes the test library (test templates) by functional areas of development, the planning tree organizes the test tasks based on those templates into products, releases, and test cycles. Product Folders: Product folders enable project teams to organize their test processes by product. Within each product folder project members may organize testing processes by release and test cycle. Release Folders: Release folders contain all of the test tasks performed during a particular release. Within a release folder test task records are stored in multiple test cycle folders. Test Cycle Folders:Test cycle folders contain all of the test tasks that are used during a test cycle within a release. Each test cycle folder is contained within a release and inherits the team members, test templates, and environmental variable definitions assigned in the parent release folder Customizing the Planning Folder Notes Page 6.3 Administering Planning Wizards To enable test planners to view notes in a modeless window, select the Enable View Note in Modeless Window check box in the Notes page of the Folder System Page subfolder in the Planning View GUI Settings folder in a work project. To display the Notes page in the folder property, select the Display in Folder Property check box in the Notes page of the Folder System Page subfolder in the Planning View GUI Settings folder in a work project Understanding the Release Wizard Understanding the Test Cycle Wizard Defining Wizard Page Titles and Descriptions Defining Coverage Update Warning Messages Displaying the Notes Page in Planning Folders Displaying Target Data in the Release Folder Editing Page Displaying Target Data in the Release Wizard Enabling Target Data Reporting 6.4 Administering Summary Reports Test planning is the process of selecting, generating, and assigning test tasks to project members for testing. Test planners may choose appropriate test templates, environments, and team members for reach release cycle and test cycle. In DevTest, all test planning is managed in a work project planning view using two planning wizards the release wizard and the test cycle wizard. The release wizard enables test planners to define the test templates, environments, test coverage, team members, and the target data that may be used in a release cycle. The test cycle wizard enable test planners to define the the test templates, environments, and test coverage that may be used in the test cycle. A wizard is a GUI element that progressively discloses the operations that are required to complete a complex process. In the planning wizards each operation is represented by a distinct page a planning wizard page that is displayed in a prescribed sequence. Planning wizards simplify the process of defining testing teams, test templates, environmental variables, and test tasks by representing each of these tasks as a distinct page. The release wizard is comprised of the Team Selection page, selection page, EV Permutation page, Coverage Selection page, Coverage Update page, and, optionally, the Target Data page. The test cycle wizard is composed of the Selection page, EV Permutation page, Coverage Selection page, and the Coverage Update page. The Team Selection wizard page is optional in the Test Cycle wizard.

206 Although each wizard organizes different processes, each wizard draws on same set of system pages. Figure 8-1: Planning View Wizards Administrators may edit the Page Display Name and Page Description fields of all planning wizard pages, but may not make any no other changes to the graphical user interface of the page. For more information see Understanding Summary Report Columns Adding or Removing Summary Reports Defining Planning Summary Report Refresh Options Defining Display Names for Summary Report Columns Customizing the Summary Report Customizing the Test Coverage Summary Report Chapter 7 Test Task Administration 7.1 Understanding Test Task Management In DevTest, all tests are managed and tracked astest tasks. A test task is an instance of a test template that may be used to test a feature in a specific environment. Test tasks give testers the information that they need to set up and execute a test (the environment, test procedure, and expected result), they enable the testing team to track and analyze the results of the test, and they are foundation for any bug reports based on that test. Test tasks not only define test procedures and expected results, they also enable testers to record the result of those tests and other testing data. As test templates are fully customizable, testing groups may define templates that may be used to track a wide range of testing information all information may be tracked and reported. Each test task give testers what they need to run tests A test task typically consists of a procedure, an expected result, and other properties such as instructions for setting up the test environment. Information may be presented to testers in the test task itself through test task notes or attached to the test task. Knowledge items may be attached directly to a test task or attachments may be inherited by test task from the test template used to generate it. Key knowledge items such as test plans are always at the testers fingertips. 7.2 Customizing Test Task Function Pages Work project administrators may customize six function pages that are displayed in the test task view of a DevTest work project Edit Test Task page, the Test Task Detail page, the Forward Test Task page, the Override Test Task page, the Group Change Test Task page, and the Group Forward Test Task page. A function page is a GUI element that enables the user to perform a specific action such as submitting, updating, or forwarding a record. In the DevTest client, a function page as a multiple-page tabbed form called amanager. Each function page may display multiple system and custom pages. Customizations include adding or removing system and custom pages, defining page titles, and changing the display order of tabbed pages Customizing the Test Task Editing Function Page

207 7.2.2 Customizing the Test Task Detail Function Page Customizing Test Task Forward Function Page Customizing Test Task Override Function Page Customizing the Test Task Group Change Function Page Customizing the Test Task Group Forward Function Page 7.3 Customizing the Test Task List Panel In the DevTest client, test team members may update and manage test task properties in the Edit Test Task manager, a multiple-page tabbed form that may display multiple system or custom pages. Customizations include adding or removing system and custom pages, defining page titles, and changing the display order of tabbed pages. The following system pages may be added to the Edit Test Task function page: Notes system page TestLink system page To customize task editing function page: 1Select the Editing page in the Function subfolder within the Test Task GUI Settings folder in a work project. The Tasks Editing page appears. 2Add or remove system or custom pages to the function page. To add pages select a page in the Available Pages list and click the Right arrow button. To remove pages select a page in the Working Pages list and click the Left arrow button. 3 Optional:To change the title of the function page, enter a new title in the Page Display Name field. 4 Optional:To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button Adding or Removing List Columns Defining Test Task List Indicator Icons Defining Test Task List Text Formatting 7.4 Administering Test Task Workflow In the DevTest client, the task detail panel displays detailed information about a single test task in multiple tabbed pages. Using controls in the task detail panel, test team members may update and manage test task properties. The test task detail panel represents a customized task detail function page that may display multiple system or custom pages as tabbed pages. Customizations include adding or removing system and custom pages, defining page titles, and changing the display order of tabbed pages. The following system pages may be added to the Edit Test Task function page: Notes system page Linked Defect system page History system page TestLink system page To customize the task detail function page: 1Select the Detail Pages page in the Function subfolder within the Test Task GUI Settings folder in a work project. The Test Task Detail page appears.

208 2Add or remove system or custom pages to the function page. To add pages select a page in the Available Pages list and click the Right arrow button. To remove pages select a page in the Working Pages list and click the Left arrow button. 3 Optional:To change the title of the function page, enter a new title in the Page Display Name field. 4 Optional:To change the order of the custom and system pages displayed in the function page select the page in the Working Pages list and click the Up button or the Down button Understanding Task States Understanding Verification Points and Test Task Workflow Enabling State-to-State Transition Workflow Rules Enabling Applicable Owner Workflow Rules Enabling Read-only Field Workflow Rules Enabling Invisible Field Workflow Rules Enabling Mandatory Field Workflow Rules Enabling Access Control Workflow Rules Enabling Product Defect Submission Triggers Defining State-to-State Transition Workflow Rules Defining Applicable Owner Workflow Rules Defining Applicable Owners in the User Manager Defining Task State Access Controls Defining Read-Only Field Workflow Rules Defining Invisible Fields Workflow Rules Defining Mandatory Fields Workflow Rules Defining Defect Submission Trigger Workflow Rules Chapter 8 GUI Customization 8.1 Understanding the DevTest Clients All DevTest processes are managed in two applications: DevTest Admin and the DevTest clients. DevTest Admin enables administrators to create, manage, and customize DevTest projects. The DevTest client enable project members to work in DevTest projects. Project members may log into DevTest projects using either the Windows client or the Web client applications Understanding DevTest Admin Understanding the DevTest Clients

209 8.2 Understanding Projects DevTest Admin is an application that enables administrators to manage system-level settings and to configure, customize, and manage DevTest projects. Figure 10-1: DevTest Admin GUI Thegraphical user interface(gui) of the DevTest Admin application consists of two panels: the Admin Tree panel and the Page panel. The Admin Tree panel enables administrators to select the page displayed in the Admin Page panel. The folders and pages displayed in the Admin Tree panel are project-specific. The Admin Page panel enables administrators to define project settings. All administrative tasks are managed by two types of administrators: System administrators are responsible for defining system-level settings and for enabling functions that are used across an entire DevTest implementation: knowledge projects, template projects, and work projects. Project administrators are responsible for defining project membership and workflow rules, and for customizing the graphical user interface of DevTest projects. Each DevTest project may have its own project members and workflow rules Understanding Project Hierarchy Understanding Knowledge Projects Understanding Template Projects Understanding Work Projects 8.3 Understanding Views The DevTest client is an application that enables project members to work within DevTest projects. Project members may log into and work in three types of projects using the DevTest client applications: knowledge projects, template projects, and work projects. Each project consists of one or more views. A view is a graphical user interface that enables project members to work within a project. DevTest provides two different types of client applications: The DevTest Windows client The DevTest Web client The DevTest Windows client application enables project members to log into project using a client application running on the Microsoft Windows operating system.

210 Figure 10-2: DevTest Windows Client The DevTest web client enables project members to log into projects using a web browser. Figure 10-3: DevTest Web Client The DevTest web client is a thin client that connects to the DevTest Web Server over the Internet. Using DevTest Web does not require users to install any additional software on their local machine all that is needed is a web browser. All processing is performed by the DevTest Web Server. DevTest Web may be accessed using the following web browsers: Mozilla Firefox 1 and above Microsoft Internet Explorer 5.0 and above Netscape Navigator 6.0 and above Apple Safari 2 and above Every task that may be performed in the DevTest Windows client may be performed in the DevTest Web client. To log into and work in a DevTest project a user must be a member of that project. Project membership is defined by a project administrator of each project in DevTest Admin Understanding the Knowledge View Understanding the Template View Understanding the Planning View Understanding the Task View Understanding the Report View Understanding the DevTrack View 8.4 Understanding Panels

211 Project members may use tools in the DevTest client to organize, manage, and track testing processes in projects. DevTest enables project teams to create three different types of projects. Each project type provides users with the views and tools that a project team may use to manage an aspect of the testing process. Knowledge projects enable project teams to collect and manage information gathered across multiple template projects and work projects. Knowledge project members may manage knowledge items in the knowledge project. Template projects enable project teams to create and manage test templates that may used to create test tasks in multiple work projects. Template project members may manage test templates in a template project. Work projects enable project teams to plan and execute test cycles using test tasks that have been generated from test templates created in a parent test template project. Work project members may manage test tasks in the work project Understanding Tree Windows Understanding List Windows Understanding Detail Windows 8.5 Understanding Pages The project hierarchy represents the organization of projects within the DevTest system and defines how project customizations and project access are shared across different projects. Every DevTest implementation must consist of at least three projects: a knowledge project, a template project, and a work project. The relationship between each of the three project types is hierarchical. Each knowledge project is the parent of one or more child template projects. Each template project is the parent to one or more child work projects. Each work project is the child of a template project. The project hierarchy enables project members to use views to access and work within a parent project from within any child project. A view is a graphical user interface (GUI) that enables project members to access and perform tasks in a project. Each project type consists of one or more views. Each DevTest project is comprised of one or more views that enable project members to plan, manage, and execute testing processes. All DevTest projects within a DevTest implementation have a relationship to other projects based on their place within the project hierarchy. Each project is either a parent project, a child project, or a sibling project to other projects. A parent project forms the basis for many child projects. The child project has visibility to the parent project through views and inherits customizations made to the parent project. Each knowledge project is the parent to many template projects which, in turn, are the parent to many work projects. A child project is based upon a parent project and inherits customizations made to the parent project. All work projects are children of a parent test template project. Work projects share the test template created in that project and have access to the test template project through the Template view. A sibling project shares a common parent project with other projects of the same project type. All of the work projects based on the same template project are siblings of one another. Sibling project do not have visibility to the views in other sibling projects and do not inherit customizations made to their siblings. All of the projects in a DevTest integration stand in a hierarchical relationship with one another. Their place in that hierarchy and the customizations made to their parent projects determine the functionality.

212 Figure 10-4: DevTest Project Relationships The project hierarchy and customizations The project hierarchy enables work project administrators to customize each project to meet their individual business needs without affecting other projects. Customizations made to a parent project are visible in all child projects through views. Customizations made in child project are not visible in parent projects. Customizations made in a project are not visible in any sibling project. In DevTest multiple work project testing teams may share the same template base structures and test templates and still define their own team members and workflow rules, and track project-specific data independently. Because each work project is a sibling of every other work project based on the same template project, they share the same template structures, but project membership and workflow rules are completely independent Understanding Function Pages Understanding System Pages Understanding Custom Pages Understanding Planning Wizard Pages 8.6 Administering Page Customization Knowledge projects provide project teams with a central repository for storing and managing information collected throughout a DevTest implementation. Knowledge projects enable project teams to manage knowledge items. A knowledge item is a document, HTML link, or topic that is created and managed in the Knowledge view. Every DevTest implementation must include at least one knowledge project. A knowledge project is the foundation, the knowledge base, for multiple template projects and work projects. Each knowledge project is the parent to one or more template projects and the grandparent to one or more work projects. A knowledge base is a central repository that enables members of various projects to store and exchange general information relevant throughout a DevTest implementation. The Knowledge view in a child template project or grandchild work project provides project members with direct access to a parent knowledge project. 8.7 Understanding Function Pages Template projects enable project teams to create, organize, and manage test templates for multiple work projects. Test templates are the master copies (test plans) of the test procedures (test tasks) that QA engineers use to execute product testing in DevTest work projects. Each template project is the parent of multiple child work projects, and the test templates created in the

213 parent template project may be used to create test tasks in the child work projects. Test template enable project teams to save time and effort by building environmental variables into their test templates and using these test templates to create multiple test tasks. Test templates enable project teams to enforce standardization in test tasks across all child work projects. Every DevTest implementation must include at least one template project. Each template project is the foundation (the template base) for multiple work projects. Child work projects may use test templates created in a parent template project to create test tasks Understanding Applicable System Pages Chapter 9 DevTrack Integration 9.1 Understanding DevTest-DevTrack Integration TechExcel DevTrack is the premiere project and defect-tracking solution for product development organizations. Using DevTrack, development teams may define and manage development projects in workflow. DevTest-DevTrack integration enables organizations to automate the testing, fixing, and retesting of product defects, streamline the submission of bug reports to DevTrack projects, and facilitate the sharing of information between the development and QA teams. Figure 11-1: Integrated DevTest-DevTrack Workflow Interproject searching, bug submission, and tracking enable businesses to define workflow rules that enable them to track issues across multiple test and build cycles. Test task failures may prompt testers to submit a bug report development issue to an integrated DevTrack project. A link automatically created between the development issue and the failed test task enabling developers and testers to easily research and track the bug through the entire life cycle. Integration is achieved by mapping DevTest test task fields to DevTrack development issue fields. DevTest- DevTrack integration enables QA and development organizations to work more effectively by facilitating the submission of product defect reports discovered during each test cycle and providing both teams the ability to effectively track and communicate bugs and bug fixes. Issue Searching:Issue Searching settings enable both DevTest and DevTrack users to search for information about a particular record in the other project. Issue Submission:Issue Submission settings enable DevTest project members to submit development issues to the integrated DevTrack development projects using the DevTest client. Once submitted, product defects may be tracked as development issues in the DevTrack project Understanding System-Level Integration Understanding the DevTrack View 9.2 Administering DevTest-DevTrack System-Level Integration TechExcel DevTest and DevTrack are key components of the TechExcel DevSuite of application life cycle management (ALM) solutions that includes DevPlan, DevSpec, DevTrack, and KnowledgeWise. DevTest work projects are not limited to an integration with an individual DevTrack development projects. Rather, each DevTest project can be integrated with an entiredevtrack or DevSuite site. A DevTrack site consists of a system settings project and one or more development projects. Every development project shares a common database, knowledge base, and other system-level configurations.

214 Figure 11-2: DevTest-DevTrack Integration All DevTest-DevTrack integrations are defined on a project-by-project basis. A single DevTest work project may be integrated with multiple DevTrack projects provided that those projects belong to the same DevTrack site. A DevTest user may submit a development issue to any DevTrack project in the integrated DevTrack site. The development projects in a DevTrack site also share a common group of user accounts that may be assigned different account types and privileges in each development project. In an integrated DevTest-DevTrack environment, every DevTest project member is mapped to a DevTrack site user account. User account mapping equates a DevTest user account with a DevTrack user account in the integrated DevTrack site Enabling DevTest-DevTrack Site Integration Integrating DevTest with DevTrack Sites 9.3 Administering DevTest-DevTrack User Mapping and Privileges The DevTrack view is an optional view that enables DevTest projects members to manage and DevTrack development issues from within the DevTest client. Using controls in the DevTrack view, project members with the appropriate privileges may track, submit, and edit development issues. DevTest project members may submit development issues to integrated DevTrack projects from either the test task view or the DevTrack view. Unlike the bug reports created in the test task view, development issues submitted in the DevTrack view are not linked to test tasks. The ability to view, submit, or edit development issues in the DevTrack view is restricted based account type-based privileges. Unlike other DevTest views, the DevTrack view is not customizable. The DevTrack view organizes the DevTest client workspace into two panels: the issue list panel and the issue detail panel. All forms in the DevTrack view are defined in the DevSuite Admin client by the DevTrack project administrator.the DevTrack summary contents that are visible, are defined by the "History" sections selected in the Advanced Features, Inter-Project Settings Manually Mapping DevTest Users to DevTrack Users Automatically Mapping DevTest Users to DevTrack Users Exporting Users from DevTest to DevTrack Sites Importing User Accounts from DevTrack to DevTest Administering DevTrack View Privileges 9.4 Administering DevTrack Issue Submission Settings System-level integration of DevTest and DevTrack enables QA and development organizations to work more effectively by facilitating the submission and tracking of bugs and bug fixes across projects. System-level integration settings define the connection between a DevTest site and a DevTrack site. Using controls in the DevTrack Integration System Settings window, system administrators may integrate a DevTest site with multiple DevTrack sites. System-level DevTrack integration tasks include enabling system integration, defining connection settings to an integrated or standalone DevTrack site. If the DevTest site is integrated with a standalone DevTrack site, DevTest and DevTrack user accounts must be mapped to support product defect submission and searching Defining DevTrack Issue Submission Settings

215 9.4.2 Mapping DevTest Fields to DevTrack Fields Mapping DevTest and DevTrack Field Choices 9.5 Administering DevTest-DevTrack Interproject Searching DevTest-DevTrack integration is an optional feature that may be enabled on a project-by-project basis. Using controls in the DevTrack Settings manager, enable DevTest-DevTrack integration and define the name of the target DevTrack implementation, the database source name, and the name of the server hosting the application. DevTest and DevTrack implementations may be on different application servers or use different databases. To enable DevTrack integration: 1Select System > DevTrack Integration. The DevTrack Integration System Settings window appears. 2Select the Enable DevTrack Integration check box Administering Custom Product Defect Search Fields to DevTrack Fields Chapter 10 Knowledge Administration 10.1 Understanding DevTest Knowledge Management One key factor to meeting the demands of contemporary software development is to ensure that all project stakeholders management, developers, and testers have access to the most up-to-date control documents and may effectively communicate with others both within and outside their organizations and teams in short, everyone must beon the same pageat all times. To address this issue, TechExcel DevTest takes a knowledge-centric approach to test management that places the collection, management, and distribution of information at the core of all development and quality assurance processes. Knowledge management enables all stakeholders to access, manage, and share information so that QA may make informed decisions throughout the testing process, leverage the information collected and generated by development, and learn from their past successes and failures so that they may implement more efficient and intelligent processes. Key components of the DevTest approach to knowledge management include a centralized knowledge base, instant access to quality reports, and tools for communicating information relevant to individual test cases and the project as a whole Administrating Project-Level Knowledge In DevTest, all testers may access a centralized repository of information from within the DevTest client. The DevTest knowledge view, powered by TechExcel KnowledgeWise, provides development and QA organizations with a tool for collecting and organizing the ideas that drive product development and testing. All ideas, both formal and informal are collected and managed in the same, centralized knowledge base. TechExcel KnowledgeWise is a key component in the TechExcel DevSuite of application life cycle management products. KnowledgeWise provides project managers, designers, developers, testing groups, and sales and marketing departments with a secure repository for all project documents the project plan,business requirements, functional and technical specifications, risk management documents, and corporate standards and guidelines may be managed in one knowledge base that is shared by the entire business. A centralized knowledge base increases efficiency, prevents the loss of information, helps to reduce system and maintenance costs, and facilitates collaboration by distributed teams. Access to knowledge items is protected by privilege-based access controls. The ability of project members to view, edit, lock, check out, and check in protected files is defined by their role in the project. Built-in version control tools ensure that all project development and testing teams (no matter where they are in world) always have access to the most up-to-date documents. DevTest knowledge projects provide testing teams with central repository for all information collected throughout the business. Common access to the a knowledge project (through the knowledge view) enables project members to exchange information between projects. Knowledge project administrators may restrict access to the knowledge view or the ability to create knowledge items in all child template projects and work projects.

216 Creating Knowledge Folders Editing Knowledge Folders Defining Knowledge Folder Access Privileges Defining Knowledge Folder Build Privileges Defining Knowledge Project Field Labels Defining Knowledge Topic Page 10.3 Administrating Task-Level Knowledge Knowledge project administrators may use the Knowledge Access page to create knowledge folders and define access privileges in DevTest Admin. Figure 12-1: Access Page in DevTest Admin In the DevTest Knowledge view project members may use knowledge folders to store knowledge items (documents, HTML links, and topics). To create knowledge folders: 1Select the Knowledge Access page in the Knowledge Tree window. The Knowledge Access page appears. 2In the Knowledge Folder area select the Knowledge folder. 3Click the New button. The Add New Knowledge Folder dialog box appears. 4Enter a name for the new knowledge folder in the Folder field. 5Click the OK button. The knowledge folder appears in the Knowledge tree window. 6Select the new knowledge folder. 7Define read access privileges for the knowledge folder. Administrators may restrict read access to this knowledge folder using knowledge project access privileges. 8Define build access privileges for the knowledge folder. Administrators may restrict write access to this knowledge folder using knowledge project access privileges. Chapter 11 Notification Administration 11.1 Administering Notification