DOCUMENT MANAGEMENT - University of Edinburgh



Stage: Business AnalysisBusiness Requirements DocumentBOXI UpgradeIntegrated ServicesITS092[ANNUAL PLAN NUMBER]Document Version: 1.7Date: 14/02/2013Contents TOC \o "1-3" \h \z \u 1DOCUMENT MANAGEMENT PAGEREF _Toc222464653 \h 41.1Contributors PAGEREF _Toc222464654 \h 41.2Version Control PAGEREF _Toc222464655 \h 42PROJECT OVERVIEW PAGEREF _Toc222464656 \h 52.1Description PAGEREF _Toc222464657 \h 52.2Scope PAGEREF _Toc222464658 \h 62.2.1In Scope PAGEREF _Toc222464659 \h 62.2.2Out of Scope PAGEREF _Toc222464660 \h 72.3Objectives PAGEREF _Toc222464661 \h 92.4Business Dependencies & Constraints PAGEREF _Toc222464662 \h 92.5Legislative Impact PAGEREF _Toc222464663 \h 93IMPACT ON CURRENT PROCESSES PAGEREF _Toc222464664 \h 103.1Product Name Changes PAGEREF _Toc222464665 \h 103.2Universe Design PAGEREF _Toc222464666 \h 103.3Reporting PAGEREF _Toc222464667 \h 113.4EASE Authentication PAGEREF _Toc222464668 \h 113.5Off-campus Access PAGEREF _Toc222464669 \h 113.6Training & Support PAGEREF _Toc222464670 \h 123.7BI Client Tools PAGEREF _Toc222464671 \h 134BUSINESS REQUIREMENTS PAGEREF _Toc222464672 \h 144.1Functional Requirements PAGEREF _Toc222464673 \h 144.2Non-functional Requirements PAGEREF _Toc222464674 \h 165PROJECT PROCESSES PAGEREF _Toc222464675 \h 215.1BOXI Upgrade Pathway PAGEREF _Toc222464676 \h 215.2Business Area Migration Pathway PAGEREF _Toc222464677 \h 226USER ACCEPTANCE TESTING PAGEREF _Toc222464678 \h 246.1Acceptance Test Strategy PAGEREF _Toc222464679 \h 246.2Test Scenarios (DRAFT) PAGEREF _Toc222464680 \h 256.3Acceptance Criteria for Functional & Non-functional Requirements PAGEREF _Toc222464681 \h 267TRAINING PACKAGE PAGEREF _Toc222464682 \h 278DOCUMENT SIGN-OFF PAGEREF _Toc222464683 \h 288.1Project Associates PAGEREF _Toc222464684 \h 288.2Business Stakeholders PAGEREF _Toc222464685 \h 28DOCUMENT MANAGEMENTContributorsRoleUnitNameBusiness Analyst(s) (Owner)Project ServicesService ManagementCraig MiddlemassAndrew McFarlaneProject Manager Project ServicesCraig MiddlemassSystem AnalystConfiguration TeamDefeng MaSystem AnalystConfiguration Team Geir GranumBusiness area Manager Service ManagementAndrew McFarlaneSystems Analyst DesignerApps ManagementDavid SmythProject SponsorService Management Alex CarterDeveloperDevelopment TechnologyPeter JacksonDeveloperApps SupportRon McLeodProject SponsorService ManagementMark WettonVersion ControlDateVersionAuthorSectionAmendment06/03/121.0AM & CMAllInitial Draft11/10/121.1AMAllExpanded overview, scope, current process24/10/121.2AMAllFurther revisions, expansions30/10/121.3AMAllFurther revisions, expansions07/11/121.4CMAllRevision following internal review06/02/131.6AMAll + added 3.7Revision following stakeholder review14/02/131.7AM4.1Added in new functional requirement (1.5)PROJECT OVERVIEWDescription The University of Edinburgh currently deploys SAP Business Objects version XI Release 2 (BOXI R2) as its chief data-reporting tool. Major areas of the University use it extensively including Finance, HR and Registry, and there are over 4400 unique user accounts associated with the service as of Oct 2012. R2 reached end of life in June 2011 and is therefore no longer maintained or supported by SAP. The primary aim of this project is to upgrade to the latest supported and stable version of the Business Objects reporting tool – SAP Business Objects BI Platform Release 4 (BOXI R4). The benefits of upgrading are two-fold: it will allow the University to continue enjoying the benefits of operating a vendor-supported release and also enable technical and end-users to take advantage of the many universe design and reporting-side enhancements it contains (see section 3 below).In broad outline, this project will deliver:A robust, well-performing and vendor-supported installation of BOXI Release 4 that mirrors the reporting and administrative service components available in R2. No changes will be made to underlying data or databases referenced by BOXI.Technical migration of all areas’ Public Folder reports, user accounts, universes, and security settings from R2 to R4.Incremental testing and roll out of R4 for operational use across business areas and Schools and Colleges, with ‘just in case’ access temporarily maintained to R2.A proactive communications strategy – jointly executed by the project team, business areas, and College Consultancy teams – to ensure that all users in Schools and Colleges are briefed about service changes, timings, and impact. A robust training and support package for all our users.EASE-enablement of R4 TEST and LIVE services, removing the need to use the VPN for off-Edlan access.Activation of the new BOXI System Monitoring tools.Readying of the Auditing facility for future adoption by the Business.MyEd launcher channel for the new R4 LIVE services.The post-migration decommissioning of BOXI R2.ScopeIn Scope1. Build. Implement Business Objects XI Release 4 as a University-wide service, and ensure that a like-for-like offering is made for the following software service components: Infoview (renamed ‘BI Launchpad’ in R4) and Web Intelligence; the Central Management Console (the user management web client); and the Universe Designer desktop client. R4 does not have a dedicated Desktop Intelligence client – see note 2.2.2.2 below.2. Migration. Business areas will be fully consulted about their reporting requirements, and the project team will work with each to agree and produce a migration plan for their existing universes, reports, and users that is tailored, as far as is practicable, to those requirements. A migration calendar will be established, and all area migrations will be completed in-project. In addition, the project team will clearly define each business area’s responsibilities around testing and communications, and will engage concerns and feedback. 3. EASE Integration. BOXI R2 has EASE single sign-on authentication for Infoview, but the Central Management Console (CMC) does not, and is fronted by its own proprietary authentication mechanism. For security and convenience, EASE authentication will be extended to cover both these service elements in R4 (with CMC proprietary authentication possibly being maintained for added security).4. VPN. There is currently no off-campus access to the BOXI service except by VPN connection to Edlan. To broaden access to users working from home, or who are at the University but not on Edlan, this project will remove the VPN restriction in R4. This action is entirely conditional upon extending EASE authentication to cover both CMC and BI Launchpad.5. MyEd Access. Two MyEd launcher channels exist by which authorised users can access Infoview and the CMC. We also deployed a JSR-168 portlet so users could view a list of their Release 2 reports within MyEd – the “Business Objects Document Viewer Portlet”. This project intends to deliver equivalent functionality within MyEd for the same R4 service elements.6. System Monitoring. Release 4 has facilities for monitoring various system functions and processes through the CMC. These monitoring tools will be configured and enabled so that technical staff can view the crucial information they need to make informed decisions relating to server performance and security, etc. 7. Report & Event Auditing. The auditing facility will be installed and made technically ready for business area adoption as part of this project. Actual roll-out of auditing to areas, the gathering of auditing requirements, and the writing of an adoption process are not within scope of this project, but may be pursued in parallel with it.8. Training & Support. A comprehensive package will be delivered around R4. Online strand: electronic manuals and videos demonstrating key workflows, etc. Classroom strand: one hands-on training session for key BOXI users in each business area around the time of that area’s switchover to R4. The largely ESSMU-using grass-roots user base in Schools and Colleges will be targeted by a Roadshow, which will be run around the time of SACS’ agreed operational switchover to R4. University staff will receive training via regular classroom sessions bookable through MyEd.9. Availability of Release 2. Naturally, access to R2 will be maintained for business areas not yet migrated to R4. And after migration, R2 will continue to be available to each area for a limited period, acting as a trusted fall-back option in the event of problems. During this grace period, each area should work to ensure their users are manually replicating their reports in R4. Note that R2 will be decommissioned at project-end after entire business area migration sign-off has been achieved. Out of ScopeThus delimited, the project unfortunately cannot include delivery of the following items; workarounds are specified where available: 1. Automation of BOXI user account creation and deletion. Building a connector between the Identity Management System and BOXI would allow for the automatic creation and removal of BOXI user accounts. However, considering account creation, this provides no discernible return on investment because there is no clear efficiency saving: a) creating an individual user account through the CMC takes an equivalent amount of time as searching for the user in the IDM and provisioning the service; b) users cannot be bulk added to the service through the IDM; and c) group assignment would still have to be done manually in the CMC by devolved administrators.It is mandatory that we prescribe a robust, preferably automated, method of account removal, however. This is to mitigate an evident security risk: because EASE passwords never expire, staff that have left the University could continue to access BOXI. 2. Freehand SQL for Finance, SACS et al. The ability was available within BO5 to write SQL queries directly against a database and output the results through the BOXI reporting interface. This was a very useful feature since it allowed for the writing of powerful queries that were not hamstrung by the data objects in BOXI. In R4 this ability is lost, since BO5 has been deprecated; logically but unfortunately, then, Freehand SQL cannot be delivered as part of the project. However, a potential technical workaround has been identified in R4, which all interested parties are committed to pursuing in parallel with the project, once R4 infrastructure has been set up. Additionally, we will attempt, within project, to make available to authorised power-users the ‘Custom SQL’ function, which allows for some light modification of the universe-based SQL BOXI generates.3. Dashboards. Registry SACS, figures within IS Applications and others, have identified the need for a Dashboarding solution. While the project team likewise acknowledges the clear business need, our current remit is not to upgrade the Business Intelligence platform at Edinburgh as a whole, but only to deliver a new version of one of its components, the reporting tool. But in recognition of the future convenience to the business of having these and other modules available for inspection, the project team will install the Dashboard Designer, BI Workspaces, and Live Office modules as part of the upgrade – if licencing terms permit. Note that configuration, deployment, and support for these is strictly out of scope. Again, these topics can be approached in parallel with the project.4. New Universe Format. Rather than creating discrete universes for different purposes and in order to segregate user access, R4 has a new universe format that, if adopted, could see all universes in one or more business areas federated into one ‘data layer’ – that is, ‘pooled’ in one location – with granular access to objects, and the information they refer to, set at universe-level. This is highly advantageous for many reasons, but in particular because of the potential to share or hide any available object with a user group as required, without incurring the costs associated with universe redevelopment. Converting existing universes to the new format is worthwhile, but of a scale such that it cannot be pursued sensibly in project. Interested areas will need to arrange this work separately. A document highlighting all the benefits will be circulated in due course to business stakeholders. For now, note the following benefits;Users of Admissions may envy ESSMU universe users who have access to a range of objects not available to them. If Admissions and ESSMU objects were pooled in one data layer, those objects could easily be made visible to Admissions users. A researcher in HSS has been given access to the Finance object for “Cost of Research”. Rather than allowing her to report on research across the entire University, security can quickly be set on her user group so that she would only be able to see the “Cost of Research” values related to HSS research.5. Understanding the Data. Recent feedback suggests that grass-roots users require more support on the specific data represented within their universes. While it is acknowledged that it would be useful to co-ordinate this kind of education with the roll-out of the new tool, it is not within the scope of this project to deliver training on the data, since the project is concerned only with upgrading the reporting tool itself, and not with making changes to universes or to the datasets or databases BOXI references.ObjectivesNoDescriptionO1Maintain vendor support for the Business Objects XI platformUpgrade core Business Objects infrastructure and components – Report portal (“BI Launchpad”), CMC, Information Design ToolAll existing users, universes, folders, standard corporate reports and current security model are migrated to the new versionO1aFacilitate and broaden access to reporting and administrationFacilitate off-campus access by removing VPN restriction to BOXI, in conjunction with moving CMC behind EASE.Deploy updated MyEd channelsO2Take advantage of improved universe and reporting featuresUniversity-wide communication and training on new functionality and changes within Release 4.Update IS help and support informationUpdate business partner help and support information (to be completed by business partners)O3Improve each business area’s cognition of system and report usageEnable and prepare the BOXI Auditing module for gradual Business adoptionBusiness Dependencies & ConstraintsMigrations should be scheduled to avoid key points in the year when the BOXI service needs to run uninterrupted, e.g. start and end of semesters one and two, and during exam board period.Before migration of a business area’s BOXI assets can begin, the area must notify the project team that it has explicitly satisfied the following two conditions: It must have organised and tidied public folders and standard reports, and; Have advised their users regarding switchover timings and on the need for them to re-create personal reports in R4. Deployment timescales as set by the area need to factor in the time it will take them to test reports before the service goes live, and must also factor in the time it will take them to create new support resources. The timing will be agreed with each business area and documented in the Migration Pathway for that area (see section 5.2 for details)Availability of R2 will be maintained for each area until sign-off has been achieved, thus providing an immediately accessible roll back option.Legislative ImpactPlease highlight any legislative issues that could impact this project, including:Continued compliance with Data Protection ActPlease ensure that any potential risks are identified in the project Risk Register.IMPACT ON CURRENT PROCESSES This section describes the material ways in which the upgrade project will impact and change existing BOXI service processes.Product Name ChangesUsers will immediately notice that with the advent of Release 4, SAP has changed the name of some of its products and report viewers. Technical and support documentation should be updated to reflect these new naming-choices.In R2In R4DescriptionBusinessObjects EnterpriseBusinessObjects Business Intelligence PlatformSAP’s name for the suite of applications and technologies for gathering, storing, analysing, and providing access to viewBI LaunchpadThe name of BOXI’s web-based portal through which users access and keep track of their reports.Web IntelligenceWeb Intelligence – note that installer name and some official SAP documentation refers to it as “Interactive Analysis”.Accessed within Infoview, Web Intelligence is BOXI’s web-based query and report creation, viewing, editing, and analysis tool.Universe Design ToolThere are now two tools:Information Design Tool (IDT)Universe Designer (legacy)For the creation, editing and publishing of universes.Please note that IDT is only used where the migrated universe has been converted to the new .UNX format. BusinessObjects XcelsiusBI DashboardsA tool for creating Dashboards.Universe DesignThere are now two universe design tools in Release 4. Designers will be able to use an updated version of the Universe Designer to perform a range of standard functions on existing .unv universes, e.g. import, modification, saving and republishing.R4 introduces a new universe format, .unx, which allows for universes that federate multiple relational data sources. To develop universes in this format, designers will use the new Information Design Tool (IDT). This tool offers several enhancements to the design environment not available in Universe Designer, such as: finer grain control of universe security, the ability for designers to work on the same project at the same time and share and synchronise their universe resources, and better connection and repository management. Note that .unv universes cannot be managed using IDT. It is envisaged that new universes will be developed in the new .unx format using IDT, whereas existing .unv ones will be maintained using Universe Designer. There is undoubted major technical and business benefit to be derived from converting existing .unv universes into .unx. The scale of this task means that while the project aims to make such changes possible, it is for interested areas to take this forward for their universes as separate projects in line with their business needs and priorities. For a detailed list of potential benefits, consult the Universe Design Tool User Guide.Please note that key technical and business staff will have access to both?design tools through a virtual machine for testing and review purposes. Usage?of those tools to edit existing or develop new universes is expressly forbidden, except with the explicit agreement of production services.ReportingA user satisfaction survey conducted in 2011 (“The BOXI Training & Support Review 2011”) identified key features users thought BOXI needed in order to address their gripes and improve reporting efficiency. Many of these features are built into Release 4, making it a highly desirable upgrade. These include: An updated and streamlined user interface for Infoview (now called BI Launchpad) and the Web Intelligence report viewer; Less folder clutter and ‘drill-down’: favourite reports are now easily accessible and presented as a list on the Home tab, along with those recently accessed;Multiple tabs: several web intelligence documents can now be open simultaneously in separate tabs (with each document potentially containing multiple report tabs);Auto-save: backups of currently open reports are now automatically saved to the Favorites folder;Printing: tidier output now possible in virtue of the new ‘fit report to page’ option;Improvements to the display and refreshing of variable lists in prompt boxes;For more information on these and other new features, consult the new BI Launchpad and Web Intelligence user guides. Those guides are for reference only; it may not be possible or desirable to implement all features they describe.EASE AuthenticationAs it stands, users must be connected to Edlan in order to access BOXI Infoview. This restriction is in place for a good security reason: although Infoview is behind EASE, the CMC is not, so limiting access to people on Edlan minimises the security risk of unauthorised access to the CMC. It is recognised, however, that this situation negatively impacts users at the University who need access to BOXI but who are not on Edlan, e.g. those staff working on outlying campuses. We wish to place both the Release 4 CMC and BI Launchpad LIVE services behind EASE to broaden user access. The TEST services should also be placed behind EASE, for convenience and security.Off-campus AccessAn advantage of making the service EASE-enabled is that we can simplify off-campus access to BI Launchpad. Users will no longer need to use the VPN to access BOXI, and create and run reports. This should not be implemented for the CMC, which for security reasons should be accessed only by those on Edlan.Training & SupportCourses to familiarise users with the features and workflows of R2 have been run intermittently since 2010 by Information Services. There also exists a user-maintained knowledgebase, a BOXI user group, and electronic manuals on basic and advanced reporting. Business areas also provide training and support materials. Most notably, Registry SACS, whose user-base is the largest within BOXI, offer live demo sessions, hands-on training, and instructional manuals for their most popular universe, the EUCLID Schools Student Management Universe (ESSMU). A very limited amount of locally developed support resources are available for users of non-SACS universes (including those owned by Information Services), which puts an often sizable burden on expert staff to support fellow colleagues. Central and local resources will need re-written for R4. In terms of central provision, a new ‘Getting Started with BOXI’ course will be developed by IS Apps and IS Skills and run for staff in each business area prior to go-live, and then delivered regularly thereafter. A new knowledgebase will also be established. Video demonstrations of key workflows will be created, and new comprehensive electronic training manuals publicised. The new feature-set will be promoted at the User Group, and will be demoed around Schools and Colleges by way of a BOXI R4 Roadshow and by one hands-on training session delivered in each College.An additional ‘Advanced Reporting’ course has been requested, but will only come into scope if time permits, as will the development of a BOXI Online Resource Centre that will list and link to all available documentation per universe. Both these desirables will be pursued off-project by IS Apps Service Management, if time does not permit in project.Note the following expansions and caveats:While the project will deliver new support resources, it makes no attempt to redraw the actual lines of support users currently follow to request and receive assistance from central or local help providers, e.g. IS Helpline, sacs helpdesk. BOXI resource creators will be invited, at their area’s cost, to attend vendor-supplied training on report writing well in advance of the first R4 go-live. This is to allow them to begin reworking their support materials at the earliest possible opportunity. Business areas will continue to assume responsibility for developing and maintaining their own user-facing support materials and training courses, and for ensuring that these are delivered to their users in a timely fashion. BI Client ToolsIt is envisaged that the BI Client Tools that accompany BOXI R4 will be made available to nominated technical and business staff for testing and review purposes, either via a standalone virtual machine (VM) or as a direct download from the SAP Marketplace. In terms of the first option, the client tools themselves will be installed on the virtual machine, and will be configured to ensure they connect and work as intended with the necessary BI servers and repositories. Users may configure the tools to work with the BI TEST or LIVE environment. As noted above, usage?of these tools to edit existing or develop new universes is by negotiation and agreement with production services.The following tools will be installed as a minimum:1. Report Conversion Tool. For converting deski and r2 webi reports to R4. Needed by project team and business areas for migration and testing purposes. 2. Universe Design Tool. For administration of our existing .unv universe stack.3. Web Services Query Tool. Allows BOXI queries to be embedded in third-party apps.4. Information Design Tool. For creating and administering new .unx universes. 5. Data Federation Administration Tool. For fine-tuning the data federation query engine and optimising actual queries, e.g. you can test your SQL queries using it.6. Web Intelligence Rich Client. This tool lets users work 'offline' with Web Intelligence document files (.wid), and import data from Excel files into BOXI reports.The following tools will not be installed:1. Translation Tool - allows you to translate universes and reports into another language.2. Widgets - these allow users to see and refresh reports from a widget on their desktop. This can’t be delivered in scope and so the ability to create such widgets via this tool is not yet needed. BUSINESS REQUIREMENTSFunctional Requirements1. Upgrade core Business Objects XI framework including EASE authentication and MyEd integrationIDRequirementCategory1.1Creation of new DEV, TEST and LIVE server environments for Release 4.M1.2Install all components of SAP BI Platform 4.0 Feature Pack [Latest] as defined in the Technical Architecture Document, and install the following Platform Tools & Clients: Information Design Tool, Central Management Console, BI Launchpad (main application), Web Intelligence & Web Intelligence Rich Client, BI Workspaces, Dashboard Designer, Live Office.M1.3Ensure System Monitoring functionality in the CMC is present and enabled in TEST and LIVE, and configured to provide system metrics as defined in the TAD.M1.4Ensure Auditing (incl. the auditing repository, universe, reports and database) has been installed in TEST and LIVE.M1.5Establish a procedure for removing defunct BOXI user accounts, i.e. of those staff that have left the University.M1.6MyED Portal Integration for BOXI LIVE: add two launcher channels to enable access to R4 through MyEd.M1.7SACS have a tool that lets them do basic auditing of universes and reports. Ensure this tool will work against R4. (Please note that retaining the SACS specific auditing tool is dependent on ability to roll out BOXI’s own auditing tools – i.e. should BOXI’s own tools not work out of the box then work will be undertaken to ensure the SACS auditing tool continues to work – see Requirement 1.4)HD1.8Authentication: place TEST and LIVE CMC and BI Launchpad behind EASE, and remove the Edlan / VPN restriction. HD1.9Make the BI client tools, including the Information Design Tool and Universe Designer, available to a small number (<10) of key technical and business staff in SACS and Finance via a virtual machine.D2. Migrate all existing users, universes, folders, standard corporate reports and current security model to Release 4IDRequirementCategory2.1Migration plan (including timings and change freeze to universe, reports and other BOXI assets) to be agreed with each business area.M2.2Business area to organise and tidy their public folders and standard reports in readiness by the agreed migration start date. See Phase 4 of Switchover Pathway below. M2.3Business area to advise their users regarding switchover timings and on the need for them to re-create personal reports in R4.AMcF and userM2.4Project team to migrate all items for the area to TEST (for Pilot area only) and LIVE platformsThis required an agreed list of Universes, folders and reports to be migrated for each business area.M2.5Preliminary testing of migrated items done by project team, including:Check sizes of universes and report folders in R4 match those in R2Run sample report to check that it runsRun sample of simple and complex reports and compare outputs in R2 and R4 ensuring same results returned only (excluding format of output)*.Compare with R2 to ensure all user groups present, and permissions set appropriately.*Some migrated reports may lose their print formatting, this will not be corrected for all reports by the project team.Any ‘Desktop Intelligence’ Reports in R2 will have to be converted to ‘Web Intelligence’ Reports. This is a separate action not covered by the main universe migrationM3. BI Launchpad Configuration RequirementsIDRequirementCategory3.1Configure the Default User – preferences, views, available tools. See this page for settings.HD3.2Ensure all export destinations are enabled and properly configured in the CMC for standard report despatch and for scheduling (needs configuring on two separate job servers). Destinations = BOXI inbox, email, external disk, ftp. M3.2aEnsure ‘Use job server defaults’ is unticked by default, as this will make the sending of report simpler as the user always has to untick ‘Use job server defaults’ to send any report.3.3Create user group ‘Custom SQL’ under each Business area in the CMC and configure its permissions to allow members to customise the sql of reports being run within WebI. Andrew to draw up list of eligible users.HD3.4Configure Java and Browser settings (and add certificates) on Windows and Mac MDP to prevent unnecessary browser prompts and pop-ups when running and exporting reports.D4. Platform technical testingIDRequirementCategory4.1Load and performance testing will be carried to confirm NG/Apps Management – to design testsPlease note that load testing of applications would be best practice however this is impractical due to having to load test BOXI and the application it is running against at the same time.HD4.2Browser compatibility testing (Firefox, IE, Safari on the MDP) – publish list of known issues on new knowledgebaseHD5. UAT & Roll-out, by Business AreaIDRequirementCategory5.1Establish UAT period and flexible operational go-live date with each area (done as part of migration planning).M5.2Deliver training in Launchpad (and instructions on using CMC) to area prior to start of UAT.M5.3Provide appropriate access to appointed business area stakeholders to conduct UAT of reports. M5.4Business area to set actual operational go live date once UAT satisfaction and familiarisation achieved and responsible for communicating with user base regarding roll out.MNon-functional Requirements1. SecurityRefSecurityRequirementCategory1.1AuthenticationEASE Authentication to be usedLive to Live EASETest to Test EASEM1.2Authorisation Levels (as defined and used in the CMC)“Administrator” – read/write access to all of application’s administrative functionality in CMC; and access to all ‘reporting data’. (Reporting data = run, create, modify all reports and results, build reports using any universe.) “Devolved Admin: BOXI“ – limited read/write access to administrative functionality in CMC for user admin purposes only, and access to all reporting data.“Devolved Admin: [Area]“ – limited read/write access to administrative functionality in CMC for user admin purposes only, and access to area’s reporting data only“[Area] Owner“ – no access to CMC; access to all area’s data“[Area] User” – no access to CMC; and view + print-only access to area data; no edit permissions.M2. Scalability and Performance RefScalability RequirementCategory2.1Typical and Maximum number of concurrent usersMaximum – ≤ 50 (if current licence conditions are maintained)Typical – unknownM2.2Expected annual user growth100M2.3Expected initial and maximum data volumesSame size as the existing R2 environmentM2.4Expected annual data growthMay increase from R2 due to launch of BI Launchpad – can only be achieved by monitoring of the R4 service and looking for degradationUseful because if we can estimate over 5 years then we can decide on what size/type of server is needed. More universes?How many connections should the server be able to handle at once?HD2.5Performance TestsSimple report and complex report run under zero load, and then same reports under 50 concurrent user load. Times to be noted and then compared to how R2 handles the same reports under the same load.Important reports that were known to seriously degrade performance in R2, when run, should be tested in R4. Load testing on the application being queried is not in scope of this project. Only comparative testing can be completed.M2.6 Performance required of key functions under load Large reports should return data before a user’s session times out. Session time out threshold may need increased.Please note that this will only be tested against reports that can currently run in R2 without timing out. The nature of BOXI allows users to create reports that may not be optimised and no change can be delivered by the project to tackle the unconstrained nature of report creation.Testing will be carried out on a comparative basis only (i.e. R2 versus R4 performance).HD3. Availability / Business Continuity Check IS Alerts Log for metrics; priority 2 (recovery within 4 days)Note particular points of performance degradation.RefAvailability & Business Continuity RequirementCategory3.1The solution should be designed to be highly available during normal working hours. 99.9% availability excluding planned maintenance during 8am – 6pmHD3.2In the event of a failure the system must be designed to be recoverable in less than 1 working day with minimal loss of saved corporate and personal reports.Recovery in less than 1 working day from time of failure HD4. Back Up / Archive (N/A)RefBackup/ArchiveRequirementCategory4.1Daily BackupNightly backup for Disaster Recovery incremental backup with full backup over weekend.M5. Data Interfacing & Migration No data interfacing – all data interfacing and migration arrangements that have been agreed with each area will remain in place without any alteration, since this project will not be altering universe structures or the data in databases. 6. Conformance with Browsers, Operating Systems & Mobile DevicesSee the supported platforms.pdf for full details of availability and compatibility with server platforms, virtualisation software, mobile platforms, etc.A. Server and Desktop (“Client” below) Minimum Hardware RequirementsManaged Desktop (Mac & Win) will need following hardware spec:2gb of RAM and 2Ghz Core CPUNo Disk Space required as interface is web-basedB. Supported Web BrowsersBOXI now supported on Safari 5.1 and upwards on Mac OS (though Safari is not officially supported at Edinburgh)IE7 with Java 1.5 on Win 7 not supported (but may run)IE9 with Java 1.6 on Win XP not supported (but may run)Current list of supported web browsers at the University C. Java / Flash RequirementsManaged Desktop (Mac & Win) will need following software spec:Adobe Reader version 8 or aboveAdobe Flashplayer 10 or abovePROJECT PROCESSESThis section describes the pathways the project will follow in order to meet the key objectives of (1) upgrading the BOXI reporting tool to R4 – from initial Business consultation to the decommissioning of Release 2; and (2) migrating Business areas and their BOXI assets to R4. Technical IT procedures relating to the server setup, installation, and migration are covered in the Technical Architecture Document for this project.BOXI Upgrade PathwayPhaseDescriptionCompleted whenGather business requirementsProject team gathers requirements from all areas, critiques them in light of scope and resources, and produces a Business Requirement Document.BRD is signed-off by stakeholders in each areaTEST environment (1) – BuildTEST platform built according to TAD specification. N/ATEST environment (2) – Testing1. Undertake sample migration of universes, reports, folders, etc. to help define the technical migration process workflow.2. Open TEST to key business stakeholders so that they can begin updating their support materials and communicating internally about features. Note, training and support not provided.Project team sign-off on the build, and also on the technical migration process to be usedLIVE environment (1) – BuildLIVE built to mirror TEST configuration.N/ALIVE environment (2) – Testing1. Sample migrations again undertaken. 2. MyEd launcher channels added.3. Platform testing by project team: Functionality and workflowsBrowser compatibility Load, usage and performanceLIVE testing is signed-off by project teamConduct business area migrationsArea migrations undertaken one-by-one – refer to the migration calendar. Each should begin during the specified change freeze period, but only after sign-off has been achieved on the pre-migration tasks agreed upon with each area.All areas have reached Step 8 of ‘Switchover pathway for each business area’ defined belowRemove access to Release 2An area’s access to R2 will be removed one month after go-live (user groups will be archived). Decommission Release 2R2 will be completely decommissioned.After entire area access has been removed.Business Area Migration PathwayThe following schedule will be agreed and completed for each of the business areas involved in the migration, prior to commencing migration work for that business area.PhaseDescriptionTarget DateArea ConsultationPeriod in which project team works with each area to identify their reporting needs and agree a migration plan (that includes timings for the periods below). The Business Requirement Document produced is to be signed-off by stakeholders in each munication PlansIt is the responsibility of each area to communicate their agreed upgrade plans and timings to their users and colleagues. We would encourage larger areas to put in place a communications plan to effect this after BRD sign-off has been achieved. The project team will work with business areas, College Consultancy teams, and School representatives to facilitate the dissemination of information.Change FreezeAn agreed date after which no changes will be made to an area’s universes or standard reports, and after which migration can commence.Pre-migration tasksNested within Change Freeze, this defined time period is for the area to conduct a final tidy-up of their report folders and user accounts, and to send necessary comms to users. The project team will also perform old universe decommissioning and folder related tasks as explicitly agreed with the business area and documented here.MigrationPeriod in which the technical process of migrating an area’s BOXI assets to Release 4 TEST and LIVE platforms will be undertaken by the project team, allowing for some post-migration technical testing to make sure reports are accessible and produce the expected data.TrainingDeliverable at any point between phases 3 and 6, is familiarisation training in the new BI Launchpad interface for key stakeholders in each area, to allow them to undertake UAT (see phase 7 below). Instructions or user guides for administrators who use the CMC will be provided.Note that larger areas such as Finance and SACS must liaise with the project team to ensure that training is scheduled for their large user-bases well in advance of the Go-Live date they set.User Acceptance Testing (UAT) Date after which key area stakeholders will be given access to BOXI R4 LIVE to do UAT on reports. Testing scripts will be provided by the project team. UAT / Migration sign-offThe date – around 2 weeks after UAT began – on which UAT is completed and when the business area confirms to the project team that the migration of reports, users, and folders has been successful.Go-LiveThe date, set by the business area, when its end-users are told they may access and begin using R4, and when area helpdesks (sacs, fisusers) assume support of R4 for their users.Removal of access to R2Access to R2 will be removed from all users in the area 1 month after the Go-Live date, on condition that R2 is not needed as a fall-back option.It is the responsibility of each area to ensure that all their users are adequately briefed and have been encouraged to re-create their personal reports before the R2 service is shut down.USER ACCEPTANCE TESTINGAcceptance Test StrategyUAT constitutes phase 7 of the “Business Area Migration Pathway” outlined above. It begins after (1) technical confirmation has been achieved that an area’s BOXI assets have been migrated to R4 LIVE and TEST (phase 5), and (2) training has been delivered to stakeholders in the Area (phase 6). After an Area has signed-off on UAT, it should progress to Go-Live (Phase 9), i.e. to general release in the Area.Note the following two points:The purpose of UAT is to verify that reports, users, folders and security operate in a like manner to Release 2. Please note that, at the request of the Business, UAT will only be conducted on the R4 LIVE environment so as to make efficient use of their resources. 1. Scheduling & Duration. UAT start date and duration will be set by the Area in dialogue with the project team, who will consult the migration calendar to ensure that a period is chosen in which technical support can be offered to the Area.2. Sources of test data. (1) Migrated standard corporate reports contained in their public folders; (2) migrated universes, on which new reports will be created; (3) migrated users and user groups.3. Test scripts. Provided by the project team and mandatory; but an Area may add their own scripts to these if they feel some aspect is not adequately covered. 4. Required test participants and any training requirements. Areas will be responsible for selecting testers, and for ensuring they attend the training provided to the Area prior to commencement of UAT.5. Technical and business support required during testing. The project team will provide documentation to support UAT activities, and nominate someone whom the Area can contact in the event of a major problem and to whom they will send their feedback. Test Scenarios (DRAFT)A short guidance note will be provided to each Area to assist with UAT. We would recommend that, at minimum, all corporate reports are scrutinised and tested using the list of actions below. Issues should be gathered up and passed back to the nominated project team contact. Please conduct testing with users who belong to a user group in your area. And as there are three basic types of user group in your area – you should ensure that testing of reports is carried out with each (see 3.5 Non-functional requirements for definitions).Devolved Administrator > [Your Area][Your Area] > Owner[Your Area] > UserUsers from each of these groups should work through the standard corporate reports in their area, testing the following. You may add your own test scripts to these.Be aware that reports that failed or exhibited formatting / data issues in Release 2 will not be automatically corrected by the migration to R4.Access – Can authorised users access the tool through the MyEd Launcher Channels? Have they got access to the correct set of folders and reports for that area? Navigation – Are tabs for Home and Document visible upon loginUnder Home, can a user see panels for Recently Run, Recently viewed, and alerts? Under Document, can a user see a navigation pane with drawers, a workspace area, a details pane at the right, and ribbon toolbar?Under Document, can a user select and navigate through each of the drawers?Standard Corporate Reports – general manipulation: can users – Run from inside a public folderModify (‘Edit’)Export to email, external diskSave to computer as .csv, .xls, .pdfPrint Schedule reportsAdd tag and comment to a reportStandard Corporate Reports – data:Select simple and complex reports for testingCompare with the same report in R2 – do the R4 versions produce the expected data?Compare timings in R2 and R4 - Are there any noticeable differences in the time sample reports take to run / return data?Private folders:Access Favourites and My Inbox?Save copy and shortcut of a corporate report to FavouritesRun that report from inside FavouritesCreate a subfolder in FavouritesCopy reports into itSend report from inside that folder to another BOXI inboxRun a report (copy) sent to your inboxRun a report (shortcut) sent to your inboxDelete report from inside that folderDelete subfolder inside FavouritesHow to compare reports between R2 and R4:Open your chosen report in R2Hit Edit > Query Panel to show list of report objectsOpen R4 in a new tabOpt to create a new report based on same universeView objects present in R2 reportIn R4, drag and drop same set of objects in the same order, including filters and promptsRun both reportsNote time taken to completeObserve layout: is column order and cell data presented in R4 exactly as in R2?Observe data: how does data in R4 compare to data in R2?Any discrepancies between:Rows returned?What data is missing?Values returnedIf differences in values returned, note the report element (object) in question.Acceptance Criteria for Functional & Non-functional Requirements Acceptance of the R4 release will be on the basis of comparative testing to the existing R2 release, as detailed in the test scenarios above.Acceptance on behalf of the business units will constitute the completion of comparative testing for the BOXI assets migrated from R2 to R4, to ensure that the R4 release provide comparable services to those offered via the existing R2 release and that no critical issues are outstanding (e.g. no reports run on a migrated universe).Performance and resilience will be accepted again on a basis of comparison to the existing R2 release. Completion of the load testing as defined in the non functional requirements must be completed and demonstrate that the service is not degraded by moving to R4. Performance and Resilience will be monitored as the project progresses and any issue relating to performance will be highlighted by the project team along with any potential issues where delivering the same capacity as the R2 release have licencing, infrastructure or design implications. The business units will be fully involved in accepting the release as a viable replacement to R2. TRAINING PACKAGEWhich groups will require training?GroupRequirementProvisionTechnical Staff in IS Apps, Business)They will need intimate familiarity with the system in order to design universes, administer the system, and perform service management tasks, including engaging with Business (help with reports, run training).Maxima-run courses inInformation Design ToolServer & User AdministrationReport WritingBusiness area stakeholdersThey need proficiency in the reporting and user administration tool so that they can perform UAT, and after Go-Live, expected Business reporting activity. They may also write and publish standard corporate reports for others to use.“Getting Started with BOXI R4” (IS Apps / IS Skills) – delivered before UAT.They may purchase Maxima run course on Report Writing.Central and Business support staff, e.g. IS Helpline, sacs and fisusers helpdesks.AND Staff responsible for delivering training, e.g. IS Apps, IS Skills.They need proficiency in reporting and perhaps the CMC in order to provide support to their user-base and colleagues.“Getting Started with BOXI R4” (IS Apps / IS Skills) – delivered before UAT or bookable through MyEd thereafter.They may attend Maxima-run courses on Report Writing.Standard and expert users in Schools & Colleges (local administrative staff)Familiarity with the reporting tool to conduct reporting activities in their School.BOXI R4 Roadshow 2013“Getting Started with BOXI R4” course bookable through MyEd.DOCUMENT SIGN-OFFProject AssociatesProject ManagerNameProject Sponsor NameBusiness Analyst NameSystems Analyst Designer NameBusiness StakeholdersRegistry SACSNameFinanceNameHuman ResourcesNameEstates & BuildingsNameCareersClaire MacDonnell – 19/10/2012Records ManagementKirsten Donaldson Wheal – 20/09/2012Development & AlumniJonathan Bruce – N/A – Area not migratedGov. & Strategic PlanningNameIS HelplineName ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download