1 / 48

ClearQuest Application Lifecycle Management Training

ClearQuest Application Lifecycle Management Training. Use-Case Driven Development Practice Demo. Process Overview. The Analyst creates a Request-Type='Requirement' by pushing the Requirement from ReqPro into CQALM or by creating the Request in CQ ALM.

ross-justice
Download Presentation

ClearQuest Application Lifecycle Management Training

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ClearQuest Application Lifecycle Management Training Use-Case Driven Development Practice Demo

  2. Process Overview • The Analyst creates a Request-Type='Requirement' by pushing the Requirement from ReqPro into CQALM or by creating the Request in CQ ALM. • They choose the Stakeholder as the Request Owner from the set of all Users in the SecurityPolicy->ratl_context_groups. • If the Analyst can complete the work with no further delegation, they can Accept the Request and be done. • If more work needs to be done, the Analyst does the CreateTask Action which produces the various Tasks needed for the Use-Case Driven Development Practice. • The Architect Activates the Task (s). • If the Architect can Complete the work without needing to delegate the work, they can Complete the Task. • If the Architect needs to delegate the work, they do the CreateActivity Action. • Developers and Testers Complete the 'Dev' and 'Test' Activities. • The Architect Completes the Task when sufficient Activities have been Completed. • The Stakeholder accepts the Request if they are satisfied with the work.

  3. Submitter Submit request Stakeholder is Owner Project Request Category Release

  4. Submitter • Submit request • Stakeholder is Owner Project Request Category Task • Analyst • Triages requests • Add and plan Tasks • Architect is Use-Case Owner Release

  5. Developer • Architect • Analyst • Activate Task • Assign Activities Tester Project Request Submitter Submit request Stakeholder is Owner Category Task Release Use-Case Activity (Dev) Use-Case Activity (Test) • Analyst • Triages requests • Add and plan Tasks • Architect is Use-Case Owner Activity (Actor/Use-Case Model/ System-wide Reqs)

  6. Developer • Deliver change • Complete Activity Architect Analyst Activate Task Assign Activities Project Request Submitter Submit request Stakeholder is Owner Category Task Release • Analyst • Triages requests • Add and plan Tasks • Architect is Use-Case Owner Use-Case Activity (Dev)

  7. Builder • Create Baseline • Run Build • Validate Build and Promote • Developer • Deliver change • Complete Activity Architect Analyst Activate Task Assign Activities Project Request Submitter Submit request Stakeholder is Owner Category Task Release Use-Case Activity (Dev) • Analyst • Triages requests • Add and plan Tasks • Architect is Use-Case Owner Build Baseline

  8. Builder • Create Baseline • Run Build • Validate Build and Promote • Developer • Deliver change • Complete Activity Architect Analyst Activate Task Assign Activities • Tester • Perform tests • Complete Activity Project Request Submitter Submit request Stakeholder is Owner Category Task Release Use-Case Activity (Dev) Use-Case Activity (Test) • Analyst • Triages requests • Add and plan Tasks • Architect is Use-Case Owner Build Baseline

  9. Builder • Create Baseline • Run Build • Validate Build and Promote • Developer • Deliver change • Complete Activity Architect Analyst Activate Task Assign Activities • Architect • Review status • Complete Use-Case Task • Tester • Perform tests • Complete Activity Project Request Submitter Submit request Stakeholder is Owner Category Task Release Use-Case Activity (Dev) Use-Case Activity (Test) • Analyst • Triages requests • Add and plan Tasks • Architect is Use-Case Owner Build Baseline

  10. Builder • Create Baseline • Run Build • Validate Build and Promote • Developer • Deliver change • Complete Activity Architect Analyst Activate Task Assign Activities • Architect • Review status • Complete Use-Case Task • Tester • Perform tests • Complete Activity Project Request • Submitter • Accept Task Category Task Release Use-Case Activity (Dev) Use-Case Activity (Test) • Analyst • Triages requests • Add and plan Tasks • Architect is Use-Case Owner Build Baseline

  11. Request Submitter • In Windows Eclipse client or CQ Web • Login as ‘UDDP_Analyst’ or ‘UDDP_Stakeholder’ (Blank Password) • If doing Demo, in Eclipse, you can also pre-log in as UDDP_Analyst, UDDP_Architect, UDDP_Developer, UDDP_Tester, UDDP_ReleaseEngineer, UDDP_Stakeholder • Click New Request icon • Choose CategoryTypeLabel ‘UDDP’ • Choose Category ‘Use-Case Driven Development’ • Point out Project (If you set one on chosen Category) • Point out Phase (If you set one on chosen Project) • Point out Iteration (If you set one on chosen Phase) Note: If you do not set a Category->CurrentProject or if you do not choose a Category, the Request->Project will need to be chosen before you will see any choices in the Request->Type form Control • Enter Headline • Choose Type – “UDDP:Requirement” • Choose Severity • Give (brief) tour of Request • Owner should be set to ‘Stakeholder’ • Click OK • All Queries in Public queries\Practices\Use-Case Driven Development folder unless specified

  12. Creating Tasks and setting Dev Lead Ownership Login as ‘UDDP_Analyst’ (Blank Password) Execute ‘Triage Requirements’ query Category = ‘Use-Case Driven Development’ Release = IS NULL Click on Request in Result Set grid Resize Display so Request->Tasks field shows Highlight the Request and Click UtilityCreateTask Note new Request->Tasks Use-Case Owner should be set to Role->Primary for Project= ‘Use-Case Driven Development’, RoleLabel = ‘UDDP_Architect’ Use-Case Model/System-wide Requirements/Actor Owner should be set to Role->Primary for Project= ‘Use-Case Driven Development’, RoleLabel = ‘UDDP_Analyst’ Project Triage

  13. Architect • Login as ‘UDDP_Architect’ • Execute query ‘Delegate Use-Case Work’ • Category = ‘Use-Case Driven Development’ • Release IS NULL • Click on Task in Result Set grid • Change_State ActivateTask • Choose Priority • Set Owner = ‘UDDP_Architect’ • Click Apply • Resize Display so Task->Activities field shows • Click UtilityCreateActivity • OpenTask->Activities (Dev/Test) • ratl_mastership for ‘Dev’ Activity should be WorkConfiguration->Role->Primary->ratl_mastership for a WorkConfiguration where Project= ‘Use-Case Driven Development’, Record_Type =‘Activity’, Type = ‘Dev’ • ratl_mastership for ‘Test’ Activity should be WorkConfiguration->Role->Primary->ratl_mastership for a WorkConfiguration where Project= ‘Use-Case Driven Development’, Record_Type =‘Activity’, Type = ‘Test’

  14. Analyst • Login as ‘UDDP_Analyst’ (Blank Password) • Execute query ‘My Workitems’ • record_type ‘ALMTask’ • Category = ‘Use-Case Driven Development’ • Release IS NULL • Click on Task in Result Set grid • Change_State ActivateTask for all Tasks • Choose Priority • Set Owner = ‘UDDP_Analyst’ • Click Apply • Resize Display so Task->Activities field shows • For each Task if work needs to be delegated, Click UtilityCreateActivity • Note new Task->Activities (Use-Case Model/System-wide Requirements/Actor) in the Submitted State. Open each Activity and set Owner = ‘UDDP_Analyst’ • ratl_mastership for all Activity should be WorkConfiguration->Role->Primary->ratl_mastership for a WorkConfiguration where Project= ‘Use-Case Driven Development’, Record_Type =‘Activity’, Type = ‘Use-Case Model/System-wide Requirements/Actor’

  15. Non-UCM Developer (skip if UCM developer) • Login as ‘UDDP_Developer’ (Blank Password) • Execute query ‘Developer’ • Category = ‘Use-Case Driven Development’ • Release IS NULL • Click on Task in Result Set grid • Resize Display so Task->Activities field shows • Highlight ‘Dev’ Activity • Simulate Fixing code • Dbl-Click then Choose Complete Action • highlight ID and Ctrl-C • Enter a Resolution Summary and Resolution Code • Click Apply

  16. Analyst completing Activities • Login as ‘UDDP_Analyst’ (Blank Password) • Execute query ‘Analyst’ • Category = ‘Use-Case Driven Development’ • Release IS NULL • Click on each Task in Result Set grid • Resize Display so Task->Activities field shows • Highlight Activity with Owner = ‘UDDP_Analyst’ • Simulate performing work • Dbl-Click then Choose Complete Action • highlight ID and Ctrl-C • Enter a Resolution Summary and Resolution Code • Click Apply

  17. Project Release Engineer Create Baseline of Code • Switch hats to become RE <Simulate Scripting> • Login as ‘UDDP_ReleaseEngineer’ (Blank Password) • Choose Menu Actions->New Baseline • Name = ‘<TOD> Baseline’ • PVOB = <TOD> PVOB’ • Project • ADD->Search <Highlight Project where Category = ‘Use-Case Driven Development’ and Release IS NULL • Click Activities Tab, Activities field Add • Paste Copied Activity ID into Search Key Box and click Search • Highlight only record and click OK • Click OK on new Baseline

  18. Project Release Engineer (Build) Simulate Build script (non-UCM) • Login as ‘UDDP_ReleaseEngineer’ (if not already logged in as that UserID) (Blank Password) • Menu Actions->NewBuild • Build= ‘<TOD>Build’ • On ALM Tab • Choose Project • ADD->Search • Highlight record for Project and click OK • Baseline click ADD • enter ‘<TOD>’ used to create Baseline • click->Search • Highlight Baseline created earlier and click OK • Build Status = ‘Passed’ • Owner should be automatically set to Role->Primary for Project= ‘Use-Case Driven Development’, RoleLabel = ‘UDDP_ReleaseEngineer’ • Click OK on Build record

  19. Project Release Engineer (Build) UCM • Login as ‘UDDP_ReleaseEngineer’ (Blank Password) • Execute Baseline and Build UCM scripts

  20. Project Tester • Completing Test Type Activities • Login as ‘UDDP_Tester’ (Blank Password) • Execute ‘Tester wo Build’ (for Projects NOT using Build/Activity) or ‘Tester w Build’ (for Projects using Build/Activity) • Category = ‘Use-Case Driven Development’ • Release IS NULL • Look at ‘Dev’ Activity and (if present) Build info. • Install Build, Test successfully • Choose ‘Test’ Type Activity • Dbl-Click and Choose Complete Action • Choose Validated In Build • Enter ResolutionSummary and Resolution

  21. Architect and Analyst Completing Task • Login as ‘UDDP_Architect’ later as ’UDDP_Analyst’ (Blank Password) • Execute ‘Completing Tasks’ • Category = ‘Use-Case Driven Development’ • Release IS NULL • Assess Activity States • Note Build containing ‘Dev’ fix (if Build was created) • Click Task Actions button and clickComplete • Enter ResolutionSummary and Resolution • Click Task Apply

  22. Request Submitter • Throughout the development cycle, I may be checking on the status of my Requests • Login as ‘UDDP_Stakeholder’ (Blank Password) • Execute ‘Requestor’ query • Category = ‘Use-Case Driven Development’ • Release IS NULL • Request State = ‘Opened’ • Task State = ‘Completed’ • Note States of Task and Task.Activities • Accept the work done on the Request

  23. Comments, Questions and Responses • Owner of a record is expected to be the only person directly modifying or state transitioning the record • This is not hard coded into the system, merely a suggested approach • If you wish to modify a record you are not the Owner of, do a QuestionOrComment Action • May indicate that you are just commenting or that you are Requesting a Response • You may Respond to a Question or Comment • You may also indicate that a Request is a Duplicate • MarkAsDuplicate • DuplicateComplete • Query Unanswered Questions

  24. Duplicates • In order to indicate that a Request is a Duplicate of another Request, we do the following: • 1) Request2 is seen as a duplicate of Request1. • 2) Select Request2. • 3) Choose the MarkAsDuplicate Action. (This creates a Comment on the Request->Comment Tab with ResponseRequested on Request2 and a Comment = "<<DOUBLE CLICK HERE, then select Modify action to provide duplicate information.>>".) • 4) Dbl-Click the Comment and Modify it to update the Comment indicating that this is seen as a ‘Duplicate’. The DuplicateOf field will be Mandatory. Enter the ID of Request1 in the Comment->DuplicateOf field and Save the Comment • 5) The Owner of Request2 runs a query (Duplicates Needing Completion) or is notified of the DuplicateOf Comment with ResponseRequested by email. • 6)The Owner of Request2 decides if they agree that their Request is a ‘Duplicate’ of Request1. • 7) If they agree that their Request2 is a ‘Duplicate’ of Request1 they execute the Request->DuplicateComplete Action on Request2. This State transitions Request2 to ‘Completed’ State. • 8) The Owner of Request2 dbl-Clicks the Request->Comment and choose the Respond Action. • 9) They dbl-click the Comment->Response and Modify it to add their response and save it. • 10) If they do not think that Request2 is a ‘Duplicate’ of Request1, The Owner of Request2 dbl-Clicks the Request->Comment and chooses the Respond Action. • 11) They dbl-click the Comment->Response and Modify it to add their response saying that they do not agree for the following reasons and save their Response. They do not Complete the Request2 by Accepting it.

  25. Rejected, Unreproducible and WorksAsDesigned Requests • Perform steps on ‘Request Submitter’ Slide • Note the Request->ID for later use • Login as ‘UDDP_Analyst’ • Execute \Public queries\Practices\Use-Case Driven Development\Triage Requirements query • Click Utilities icon on Request • Choose Reject_Request (or Unreproducible or WorksAsDesigned) • A Task for the ‘ALL’ Project will appear in the Request->Task Form Control • It will be in the Completed State • No further Tasks will be permitted to be created • Any pre-existing Tasks will be Commented • Reverse this • Login as ‘UDDP_Architect’ • Access Request by Request->ID then ReOpen the Task • Change the Project to ‘Test Driven Development’ • Set Mandatory field values with Type = ‘Defect’, etc. • Click ‘OK’ button

  26. Rejected, Unreproducible and WorksAsDesigned Tasks • Login as ‘UDDP_Analyst’ • Execute \Public queries\Practices\Use-Case Driven Development\Dev Lead query • Note the Task->ID for later use • Click Change State icon and choose Complete Action on the Task just ReOpened • Set ResolutionCode = ‘Reject_Task’ • The Task will be state transitioned to the CompletedState • Any pre-existing Activities will be Commented (CQ ALM 1.1 only) • Reverse this • Login as ‘UDDP_Architect’ • Access Task by Task->ID then ReOpen the Task • Click ‘OK’ button

  27. Rejected, Unreproducible and WorksAsDesigned Activities • Login as any Role that might be an Activity->Owner • Click ChangeState icon and choose Complete Action on any Activity • Set ResolutionCode = ‘Reject’, ‘Unreproducible’ or ‘WorksAsDesigned’ • The Activity will be state transitioned to the CompletedState • To reverse this, ReOpen the Activity and reset auto-generated field values

  28. ClearQuest Application Lifecycle Management Demo End of CQ ALM Training

More Related