Question
Bluevoir Inc.
IN
Last activity: 20 Mar 2019 9:24 EDT
Looking for preparation material for the following topics of the CRSA 8.0 exam
To be more precise, i'm looking for preparation material for the following topics of the CRSA 8.0 exam
Project Management (18%)
- Interpreting & implementing business requirements
- Performing Application Discovery
- Estimating Development Effort , so kindly provide where is the study material or webinar link - no material available
***Updated by moderator: Lochan to branch reply and create new post; Move to Academy***
Pegasystems Inc.
US
Please note that approximately 30% of the Robotics exam is based on field experience and may not have course/training content associated with it. As indicated in the exam blueprint at: https://academy.pega.com/library/80/certified-robotics-system-architect, we recommend that exam candidates have a minimum of 6-12 months of field experience before taking the exam.
NTT Data
US
Hi
At least provide just details about what is Application Discovery , if search in google many documents -IBM, Amazon all in that arena , but what Pega-Openspan-RPA point of view what is mean by Application Discovery? if I asked Openspan experienced developers they are saying don't know.
Pegasystems Inc.
US
Application discovery is an early technical validation step that involves collecting the information about applications in scope of a potential robotics use case. During discovery you need to find out application types (and if they are on applications support matrix for Pega Robotics), how they are launched, how they are used, and check accessibility and functionality of the controls through interrogation. Application discovery is necessary to ensure that robotics use case is viable and it doesn't have any technical constraints... or, if constraints exist, then what kind of workarounds will be necessary to ensure the use case is successful. The rationale for having application discovery as a best practice is that you don't want to find out half-way through coding an automation that a key control is not available or not performing the desired action.
Datacom group
NZ
Hi petrg,
Who should perform this task and on what exact project life cycle state?and if any blockers came across and there are no work around, what should be done?
Pegasystems Inc.
US
This task is performed by a developer at the initiation stage because outcomes of discovery affect your estimates and iteration plan. The qualifications are the same - you must have Robotics training, have Studio installed, and have application access. The main difference is that you are only interrogating all required windows and representative controls (but not building the automation), which makes this discovery step very quick. If blockers come up, then two things happen - first you file a Pega SR (assuming you are working in an officially supported application) and then you modify the automation use cases to work around the blockers. This is exactly the reason for discovery to enable you design the automation with knowledge of system dependencies. So you don't end up with re-work or lost time/effort, if you don't realize the blocker until too late in the process.
CA
Hi Grigory,
Thanks for the info. Can you please confirm one thing. As per my understanding, Application discovery is done in very initial phase as soon as the application is identified as part of the use case. Will it be done by the business analyst or the devloper?Because BA is the one who documents the use case for the developer by sitting with the client before the actual implementation kicked off. Can you please explain the details like by whom and when exactly the applicatopn discovery is done? Please correct my understanding if it's wrong.Thanks.
Pegasystems Inc.
US
Hi, Hanuma - yes, technical discovery is performed by a developer using the inputs from BA/SME with an overview of the use case to be able to navigate and interrogate applications in scope. Please note that a full use case design and documentation are not required for Application Discovery. For example, if it is known that some activity happens on a screen in the application, then it is a sufficient input for the developer to do initial interrogation because the developer can quickly check the key controls on the screen without needing to know the logic or sequence of actions on the screen. If a BA just goes ahead to prepare documentation and submit a use case for development without a teamwork with a developer in Application Discovery, then there is risk of lost time and effort in case the developer later running into roadblocks due to application compatibility issues.
Virtusa Corporation
SE
Hi Grigory,
Thank you for shedding light on this topic. I am wondering if determining the need for UseKeys is also in this stage? If yes, what value does it bring?
For example, if I am able to interrogate all control representatives how would the fact that the user opens multiple application instances negatively affect my development on the autmation? I have not come across it, but are there some cases that the automation would not be viable just because the users must have multiple instances open?
Pegasystems Inc.
US
Hi, ToniD - the answer is yes and no. Yes is that at this stage you would identify any controls that only accept SendKeys and don't seemingly have any other options. As you might know from the training and your experience - we don't recommend to use SendKeys for anything other than certain small activities in an RPA because SendKeys is such a volatile method. So this would be an immediate red flag. No, you don't have to devise the workaround at this stage - you would just mark it as a risk and add more development effort into the estimate to deal with this control. If the use case is still a "go" after the Discovery, you would jump on that control right away to avoid impacting the timeline. There are several alternatives to using SendKeys that you will then attempt (e.g. writing a script or UI Connector... or even asking a BA to determine with business an alternate process flow). Similarly in a situation with multiple instances. Application discovery will tell you, if a particular application is playing nicely with multiple instances and user logins. I have heard of just a small number of precedents where multiple instances were problematic, but in all those cases it was more on the application side rather than the product that was a limitation (for example, an application won't handle concurrent logon or application would launch multiple instances in a way that are indistinguishable one from another from an interrogation perspective).
Hi, ToniD - the answer is yes and no. Yes is that at this stage you would identify any controls that only accept SendKeys and don't seemingly have any other options. As you might know from the training and your experience - we don't recommend to use SendKeys for anything other than certain small activities in an RPA because SendKeys is such a volatile method. So this would be an immediate red flag. No, you don't have to devise the workaround at this stage - you would just mark it as a risk and add more development effort into the estimate to deal with this control. If the use case is still a "go" after the Discovery, you would jump on that control right away to avoid impacting the timeline. There are several alternatives to using SendKeys that you will then attempt (e.g. writing a script or UI Connector... or even asking a BA to determine with business an alternate process flow). Similarly in a situation with multiple instances. Application discovery will tell you, if a particular application is playing nicely with multiple instances and user logins. I have heard of just a small number of precedents where multiple instances were problematic, but in all those cases it was more on the application side rather than the product that was a limitation (for example, an application won't handle concurrent logon or application would launch multiple instances in a way that are indistinguishable one from another from an interrogation perspective). At the same time we have plenty of best practices how to handle multiple instances gracefully (for example, in a mainframe you can control the session number that the bot opens and that lets you make multiple instances essentially unique). So both SendKeys or multiple instances won't be an immediate "no go" for the use case, but depending on what you see, these findings may prompt the developer add more time and risk into the development timeline or ask business users upfront to be ready to consider workarounds. All of this proactive planning significantly reduces agitation during the development even if it results in additional effort.
Pegasystems Inc.
IN
I think following courses on Pega Academy helps to understand the Discovery concepts
Visualizing Automations with an Agile Mindset