Whenever a new target system comes into scope it is always worth while performing an application assessment. This simply requires running the Application Modeller spy over the elements of the new system to be automated to see how much can be identified and how easily. Typically for Windows, browser and Java applications this activity requires a developer to determine the most appropriate technique for interfacing with each element type (combo box, check box, table, lists etc.). This will help estimate development effort and provide initial approximations of case handling times. 11.5. Project Types Proof of Concept The aim of a POC should be to demonstrate the potential of automation rather than to produce a fully autonomous solution capable of unattended automation. To that end the design should focus more on working the in-scope cases and less on the features required of a Production solution, such as scalability, application control, exception handling, notifications and MI. Evidently the solution needs to work, but it does not need to be a full-strength Production piece and most likely will only be run for a limited period often in attended mode for purposes of demonstration. The design should take into account what can realistically be delivered in the time available and remember what the overall purpose of the project is. Following any proof on concept a design review must take place, final design documented and further development incorporated to ensure the process is production-strength and ready for formal testing. Pilot A pilot is a process that is built to run temporarily against production cases. Similar to a POC, the design of a pilot project should reflect the aim of the project. The objective of a pilot may not be to produce a full-scale solution, and so the agreed scope of what a solution will and will not do should be covered in the design. If the pilot is based on an earlier POC then care must be taken to revisit the original design. As mentioned above, for expediency a POC is likely to have limited the robustness of the solution and any subsequent pilot will need to make improvements. 11.6. Design Authority The principle activities of a Design Authority are to define and govern: • The design process • The design documentation to be used • The design review process The design authority must decide on how common technologies should be used such as: • Email – email clients or SMTP? • Workflow systems – how will Blue Prism utilise existing workflow systems to interact with manual users? • Third party code – how should this be wrapped and exposed to Blue Prism. • Web services
Commercial in Confidence Page 25 of 27 The design authority must define design and development conventions e.g. naming conventions for processes, objects, work queues, environment variables, data items etc., prescribe logging policy and data storage policy and be the custodians of development best practice.
Commercial in Confidence Page 26 of 27 Appendix 12. Design Review Checklist 12.1. Solution • Has the ‘as is’ manual process been defined and documented with enough detail to design an automated solution?
- Summer '09
- ramana rao
- Blue Prism