Executive Summary.doc.doc

1,243 views
1,188 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,243
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Executive Summary.doc.doc

  1. 1. STATE OF NORTH DAKOTA Project Plan Mainframe Migration Prepared by Software AG, Inc. March 16, 2006 Version 1.2
  2. 2. State of ND - Project Plan – V1.2 NOTICE OF NON-DISCLOSURE This Software AG, Inc. (“Software AG”) Technical Assessment and Detailed Implementation Plan contains information and data, which are privileged and/or confidential to Software AG. The information and data are not to be made available for public review, and are submitted voluntarily to the State of North Dakota (“ND”) only in response to a specific request. No license of any kind whatsoever is granted to State of North Dakota to use the information contained herein or in subsequent discussions unless a written agreement exists between Software AG and State of North Dakota. The information contained herein is submitted to State of North Dakota for purposes of review and evaluation. No other use of the information and data contained herein is permitted without the express written permission of Software AG. Under no condition should the information contained herein or in subsequent discussions be provided in any manner whatsoever to any third party without first receiving the express written permission of Software AG. DISCLAIMER None of the terms set forth in this document should be considered final or binding unless and until they are set forth in an agreement signed by State of North Dakota and Software AG. TRADEMARK DISCLOSURE Software AG, the Software AG logo, Adabas, Natural and EntireX are either registered trademarks or trademarks of Software AG (Darmstadt, Germany). All other company, product or service names referenced herein are used for identification purposes only and may be trademarks of their respective owners. Copyright © Software AG, Inc., 2006. All rights reserved. 3/16/2006 Page i
  3. 3. State of ND - Project Plan – V1.2 Version Summary Version Date By Brief Summary Number Dennis 1.0 12/23/2005 Initial Project Plan DeBruin Dennis Minor modifications based on North 1.1 01/19/2006 DeBruin Dakota input Dennis Minor modifications based on continued 1.2 03/14/2006 DeBruin “learnings” from the project 3/16/2006 Page ii
  4. 4. State of ND - Project Plan – V1.2 Table of Contents EXECUTIVE SUMMARY.......................................................................................1 1 MIGRATION PLAN – CURRENT STATUS.......................................................5 2.1 A Conceptual View.................................................................................................5 1.1 Project Roles and Responsibilities .......................................................................8 Sub-SITAC Committee –State Information Technology Advisory Committee 9 1.2 Project Phases.....................................................................................................12 2 TECHNICAL ARCHITECTURE........................................................................13 2.1 Software...............................................................................................................14 2.2 Creating the Production Environment..................................................................14 2.3 Creating the Development and Test Environments..............................................15 2.4 Hardware Server Configurations..........................................................................15 2.5 System Performance Requirements....................................................................16 3 TESTING ..........................................................................................................18 3.1 Testing in the Linux Environments at ND ............................................................18 3.2 Testing Methodology............................................................................................19 3.2.1 High-level Approach.............................................................................19 3.2.2 Validation Types...................................................................................20 3.2.3 Test Methods........................................................................................21 3.2.3.1 Comparison Testing...................................................................................21 3.2.3.2 Scripted Testing.........................................................................................23 3.2.3.3 Non-scripted Validation.............................................................................23 3.2.4 Test Execution .....................................................................................24 3.2.4.1 Naming Conventions for Scenarios and Test Cases..................................24 3.2.4.2 Pre-test Preparation....................................................................................24 3.2.4.3 Testing Sequence.......................................................................................24 3.2.4.4 User Impact................................................................................................25 3.2.4.5 Testing Schedule........................................................................................25 3.2.5 Test Reporting and Feedback..............................................................25 3.2.6 DISCREPANCY MANAGEMENT PROCESS......................................27 3.2.7 Recording Problems in WMS...............................................................27 3.2.8 Recording Issues in WMS....................................................................30 3.2.9 Key Definitions for Issues ...................................................................32 Priority..................................................................................................................32 3/16/2006 Page iii
  5. 5. State of ND - Project Plan – V1.2 Stage......................................................................................................................32 3.3 User Acceptance Testing.....................................................................................33 4 SOFTWARE DEVELOPMENT STANDARDS .................................................34 5.1 Best Practices in Software Development Standards............................................34 4.1 Quality Assurance Plan........................................................................................35 4.2 Considerations for Mainframe to Linux Migration.................................................36 4.3 Pre-Migration Activities .......................................................................................40 4.4 Preparing the ND Application Infrastructure for Migrating to Linux .....................40 4.4.1 Identifying/Preparing ND Modules for Migration..................................40 4.4.2 Natural..................................................................................................41 4.4.3 COBOL ................................................................................................41 4.4.4 REXX....................................................................................................42 4.4.5 DYL280.................................................................................................42 4.4.6 ASSEMBLER........................................................................................43 4.4.7 FORTRAN ...........................................................................................43 4.4.8 Batch Jobs/JCL....................................................................................44 4.4.9 External Interfaces................................................................................47 4.4.10 Printing Considerations......................................................................47 4.5 Migration Activities at ND.....................................................................................48 4.6 Configuration Management..................................................................................49 5 SECURITY PLAN .............................................................................................50 5.1 UNIX User Authentication/Authorization and Active Directory Integration............50 5.2 Access Control Lists............................................................................................51 5.3 DB2, RACF, and Active Directory........................................................................51 5.4 Natural Security...................................................................................................52 5.5 CICS and Microfocus...........................................................................................52 5.6 Access to Datasets or Files..................................................................................52 5.7 Auditing................................................................................................................53 6 HUMAN RESOURCES/TRAINING PLAN........................................................54 7 MANAGEMENT AND CONTROL METHODOLOGY.......................................59 7.1 Change Management..........................................................................................59 7.2 Communications Plan..........................................................................................62 7.3 Method for Updating the Communications Plan...................................................63 3/16/2006 Page iv
  6. 6. State of ND - Project Plan – V1.2 8 STAKEHOLDER PROJECT COMMUNICATION MATRIX..............................69 8.1 Status Reporting..................................................................................................70 8.2 Managing the New Linux Environment.................................................................73 8.3 ND Project Management Standards and Practices..............................................78 9 IMPLEMENTATION TIMELINE AND METHODOLOGY..................................79 9.1 Go Live Contingency Plan....................................................................................79 10 RISK MANAGEMENT.....................................................................................81 10.1 Mainframe Migration Risks.................................................................................82 3/16/2006 Page v
  7. 7. State of North Dakota Migration Project Plan – V1.2 Executive Summary Following a successful assessment and analysis project, the State of North Dakota contracted with Software AG, Inc. (Software AG) to migrate the significant majority of their mainframe code base to a Linux platform. Three key success factors have become our goals: • The look and feel of the application must remain the same for ITD customers • The migration must lower ongoing operating costs • We must set a foundation for future growth of the State’s hardware and operating systems platforms while still maintaining or improving efficiency in operations and development. The Project Plan is a “living document”. As more information is gained, this document will be updated to reflect the new information. You should expect an updated document at least quarterly. The document may be published more often based on critical needs or findings in the project. The Software AG senior project team is now in place and has permanent offices at North Dakota. It is expected that this team will be on-site a considerable, but not full-time basis, for the next 18 months as we develop the project. The assessment project and continued analysis on this project have indicated that the optimal way to pursue this project is in four phases, which agencies and their respective code assigned to each of the four phases. Those four phases are described in detail in this document. The initial hardware and operating system has been installed. Additional platforms will be installed as the project schedule indicates the need for. Project kick-offs have been conducted at a high level and an agency-level kick-off meetings for the agencies that will be part of the each phase (group) will be scheduled just before we begin to work on each group. To reduce project costs and to increase the learning curve of North Dakota staff, Software AG has included five North Dakota IT staff members into the project. These five people add very valuable practical and business experience to the Software AG team. Drawing from our experience in similar migration endeavors, and taking into account the continuing information through our partnership with North Dakota, we have defined a set of project assumptions and best practices, which guide our recommended approach to the project for the State. As you will note, we see the State’s personnel, and in particular ITD, as being key to a successful migration effort. Our assumptions address the anticipated responsibilities of Software AG and the State, especially in the areas in which we anticipate extensive involvement with the State, such as application and acceptance testing. 3/16/2006 Page 1
  8. 8. State of North Dakota Migration Project Plan – V1.2 The project schedule has also been created and is included in this plan. It is a very detailed schedule that is complete for phase (group) 1. There are many components to the plan, so we are going to create high-level schedules for groups 2-4, and then detail them much more with our experience from Group 1. In summary, while the project is just processing group 1 objects, there are no significant issues and most scheduled tasks are being completed as needed. 3/16/2006 Page 2
  9. 9. State of North Dakota Migration Project Plan – V1.2 DETAILED SUMMARY Migrating is a very comprehensive process, ranging from the beginning phases involving a significant degree of up-front analysis to the final efforts of extensive post-migration testing. In between these initiating and ending activities, several major activities will take place to promote a smooth transition to the Linux platform. As the migration is completed, through all four groups, Software AG will, at a minimum: o Define the User Interface: Identify and implement the State requirements for the user interface features on the Linux platform. o Define the Processing Environment: Describe and assist North Dakota in implementing the operating system, version, and utilities for the new platform. o Assist with Definition of Server Environment: Describe and assist North Dakota in implementing the server environment, including CPUs, disk, memory requirements and any other storage media for the new platform. o Assist with Definition of Communications Protocols, Connectivity, and Hardware Placement: Describe and assist North Dakota to implement the communications protocols, connectivity and hardware placement of the new platform. o Identify Database Version: Identify the versions needed. o Identify Programming Languages: Identify any languages and versions needed. o Assist with Definition of Security: Assist North Dakota with the security aspects of the new platform. o Replace Existing Job Control Language: Describe the means that will be used to replace existing JCL batch operations. o Anticipated Technical Obstacles: Software AG will describe technical difficulties that might be encountered and potential solutions or safeguards that could be used to solve or mitigate such difficulties. o Comprehensive list of 3rd Party Products and Pricing: Software AG will identify all 3rd party products required and recommended to complete the migration phase. Software AG will provide cost estimates and a “source of supply” proposal to supply those products. The complete project schedule is included in Appendix A of this document. Appendix B contains a detailed application profile of the in-scope applications as developed by ITD and Software AG. 3/16/2006 Page 3
  10. 10. State of North Dakota Migration Project Plan – V1.2 As an overview, Software AG will institute a phased approach to the migration project with thorough and thoughtful project management as a key to the success of the project. Software AG will bring to this project all our past migration experience and knowledge as well as our product support capability to ensure we have the right staff to complete the migration in the desired timeframe and to resolve any issue that may arise during the project. We also understand the critical nature of ensuring ITD customers and ITD staff are able to maintain (if not increase) the level of efficiency you have today in your current environment. To accomplish this, we will migrate the applications’ look-and-feel and simultaneously implement new GUI tools that will assist developers and key ITD customer staff to improve productivity. We have also integrated a significant amount of training within the project schedule. 3/16/2006 Page 4
  11. 11. State of North Dakota Migration Project Plan – V1.2 1 Migration Plan – Current Status North Dakota applications will be migrated to the Linux (SUSE) environment. The Adabas and DB2 data files, COBOL and Natural source code will be transferred to the target platform. Outside of the application source code, elements of the mainframe version of the applications will be converted to analogous facilities within Linux. These include FORTRAN, DYL280, REXX, SAS, Assembler, JCL, and TP monitor processes. 2.1A Conceptual View This document provides a detailed plan for migrating the ND applications from the mainframe and implementing them on the Linux (SUSE) platform. The migration will not change business logic, application, or architecture. Rather, migration offers a low development risk and a minimal retraining of users since, from the user’s perspective, the new environment looks and functions much the same as the original mainframe environment. During the migration, the Adabas/ DB2 data files and Natural/COBOL source code will be transferred to the target platform. Source code changes will be performed in the new environment, where necessary, so that the components compile and run on the target system. In addition to Natural/COBOL source, elements of the mainframe version will require conversion to analogous facilities within Linux. These include FORTRAN, REXX, DYL280, Assembler, JCL, SAS, and terminal emulation processes. Figure 1 illustrates the comprehensive nature of the migration project, where the term Application System Migration refers to Software AG moving/migrating all layers of the “Infrastructure Stack,” not just the applications that support business functionality. The discussion immediately following Figure 1 highlights how the solution (equivalent application environment), the functionality, and the assets are preserved (e.g., network environment can still be used). 3/16/2006 Page 5
  12. 12. State of North Dakota Migration Project Plan – V1.2 Business Strategy People and Process SIMPLE Business PORT - Application Performance Measurability Availability Application Infrastructure Storage Platform Computing Platform Network Infrastructure Scalability Security ND Facilities Applications Infrastructure IT Tools IT Processes IT People Business Continuity and Contingency Needs Figure 1: ND Migration Overview The upper portion of the stack defines the execution architecture and supports a number of systemic properties that are key to ND: Business Strategy – business functions that occur, people and processes that support the business functions and the business strategy are defined. This is called the “Business Architecture,” and it will remain the same in the target environment. 3/16/2006 Page 6
  13. 13. State of North Dakota Migration Project Plan – V1.2 Business Application – supports the business functionality. Application modules are modified, recompiled, and deployed on a new hardware platform that supports the Linux SUSE operating system. Compatibility libraries are developed or acquired in the new platform to map older utilities/APIs to the new environment and provide identical functionality. The applications are integrated with the new Linux environment. While source code, scripts, and data are moved; compilers, source code repositories, and software tools are replaced by versions compatible with the new platform. Functionality should remain the same. Changes in the business require changes in the application layer. Change management should be very similar on the new platform. Application Infrastructure – Database technology (data requirements of the applications), backup requirements, and the utilities (APIs) provided by the mainframe operating system. The same application infrastructure should be provided in the new platform. Additionally, Hummingbird terminal emulation software has to be accommodated in the new platform (at the client end and the Linux server end). Computing and Storage Platforms – These hardware components enable the application infrastructure. Network Infrastructure – The same (or similar) interconnect technology (the technology used to connect the application to a network) that ND has connected to the mainframe today would be used to connect Linux systems to the existing networks. Facilities Infrastructure – provides critical support to the elements above. Availability, Scalability, Performance Measurability, and Security –Will be implemented and supported within the new Linux environment providing similar Service Level Agreements (SLAs). The lower portion of the stack represents the management infrastructure. The tools, people, and processes implement the management infrastructure to control, measure, and manage the execution architecture: IT Tools – used to monitor capacity, utilization, and throughput and to help ensure that the service levels are met. IT Processes – in place to support change, service, deployment, and maintenance. IT People – select, develop, and administer the tools and processes. Training must take place to ensure that people understand the management processes, as well as execution architecture. Business Continuity and Contingency Needs – would remain the same, or similar, in the new platform described in Section 2. 3/16/2006 Page 7
  14. 14. State of North Dakota Migration Project Plan – V1.2 1.1Project Roles and Responsibilities A key element in the migration and implementation project plan is the organization of the human resources, their relationships, and reporting structures. Figure 2 shows the project’s organizational structure. Mainframe Migration Organization Chart Chief Information Officer Mike Ressler Executive Committee Project Director Mike Ressler, Deputy CIO & Director of ITD Steve Lowe, Director Professional Services Jerry Fossum, Director of Telecommunications Division Izak Both, Migration Practice Manager, Professional Dan Sipes, Director of Administrative Services Division Services Nancy Walz, Director of Policy & Planning Vern Welder, Director of Software Development Martin Steinhobel, Vice President Professional Service Hans B. Otharsson, Senior Director Professional Services Sub-SITAC Jennifer Witham, Dept. of Human Services Steering Committee Project Sponsor Dean Glatt Director of Computer Systems Division Project Management Office Dave Eckenrode ITD Project Manager Linda Weigel Technical Team Jeff Carr Kyle Forster James Gilpin (SAG) ITD / State Agencies Software AG Communications Project Manager Project Manager Shawn Meier Carl Bondel Development & Porting Test Team Security & Data Conversion Operations Team Implementation Team Teresa Noto (SAG) Infrastructure Team Team James Gilpin (SAG) Larry Madern (SAG) ITD James Gilpin (SAG) James Gilpin (SAG) ITD Brenda Muscha, State Agencies ITD ITD Figure 2: Project Organization Define expected involvement and expected roles of each organization. Use identical/consistent wording to refer to “entire team” or individual components/people on the team. Executive Committee – ITD Directors, DHS State Agency Representative and Software AG Representatives comprise this committee. ITD’s Project Manager will meet with the committee every four to six weeks or more is needed. The North Dakota Project Manager will conduct these 3/16/2006 Page 8
  15. 15. State of North Dakota Migration Project Plan – V1.2 meetings. Any “out of scope” changes will need to be presented to this committee for approval as well as any issues requiring approval at this level. SAG Project Director – Provides senior-level direction to ensure that the project is carried out expeditiously and that Software AG’s resources are being used effectively Sub-SITAC Committee –State Information Technology Advisory Committee Project Sponsor –Responsible for the financial resources for the project. Project Management Office – Oversee the ITD Project Managers ITD Project Manager – Responsible for the overall management of the project. Technical Team – Assists both project managers with the technical aspects of the project. Communications - See Communication Plan Section Software AG Project Manager – Works with the ITD Project Manager and is responsible for the overall Software AG project management. ITD/State Agencies Project Manager – Responsible for working directly with the Development & Porting Implementation, and Test Teams making sure that deliverables are met in a timely manner. This Project Manager will also be the liaison between the Mainframe Migration team and the State Agencies Personnel. Test Team – The ND ITD Test Support Team and the Software AG Test Support Team will have primary responsibilities for major segments in preparing and/or executing the testing tasks. This group will also support the testing process by organizing test results, tracking testing progress, accumulating statistics of successful and unsuccessful test executions, tracking problems, and compiling a final test report. There are three primary groups of testers: 1. Software AG Test Support Team 2. North Dakota ITD Test Support Team 3. North Dakota Business/Agency Testers North Dakota Business/Agency Testers, employees familiar with the functional and/or technical aspects of the applications, will be responsible for actually executing the acceptance testing. Development & Migration and Implementation Team – This team is a rotating group of subject matter experts from Software AG and North Dakota ITD and the North Dakota Business/Agency organizations as applicable. The Software AG and ND ITD groups will provide software development standards, change management processes, production quality control, and program and performance standards. The Software AG and ND ITD groups will also create a target runtime environment inventory, identifying all the components involved in the migration/porting to ensure the completeness of the target environment’s functionality in meeting the needs of the migrated ND applications. They will migrate all the application modules and processes to the new platform, will look at the 3/16/2006 Page 9
  16. 16. State of North Dakota Migration Project Plan – V1.2 configurations, FTP capabilities, printers attached within the mainframe environment, and will convert to appropriate functionalities within the target Linux environment. Finally, the Software AG and ND ITD groups will ensure proper installation in the production environment, preparing both software and data environments for production. This team will also check general performance and stability of the system. The North Dakota Business/Agency organizations will assist the Software AG and ND ITD groups in reviewing the migration strategy, assisting in the definitions of all processes and providing answers to questions as needed. Data Conversion Team – This team will be comprised of Software AG specialists responsible for the transformation or conversion of legacy data for the new environment. The team will perform preparation activities around data conversion and the actual data conversion. Security & Infrastructure Team – This team, primarily comprised of the ND ITD Security staff, supported by Software AG staff, will ensure that the new servers adhere to ND’s security program policies and procedures. The security requirements involve protection of the data, source code, audit logs, etc. This team is also responsible for defining the technical architecture to support the migrated solution. This team will understand and conform to all the existing security policies and procedures in the target environment. Enforcement of the business processing rules on a user’s authority requires an unassailable authentication solution, strong and effective privilege definitions, and the assignment of a privilege list. Security and integrity can be provided through infrastructure products, as can authority limits and privileges. It is necessary to take all of these features into account while designing the Linux environment. Operations Team – This team will be comprised of Software AG specialists and the ND Operations Team and Business/Agency representatives. It has responsibility for day-to-day management of the migrated solution in the new platform. The applications and platforms affected by the migration/porting, as well as existing and new processes, must be assessed to ensure that the migrated application will integrate into the procedures executed by the enterprise. The operations management architecture – operational qualities include performance (throughput), manageability, security, serviceability, and maintainability – will need to be migrated to the new environment. Business and Agency personnel will be involved to confirm the decisions made and verify that the operational qualities of the new system meet their expectations. The refinement process will be iterative in nature. As more information, requirements, and constraints are discovered, changes to the overall design of the platform might also be required. Current capacity planning and service level management knowledge can be input into the engineering process of the platform design. Training Team – Comprised of Software AG, ND application specialists and ND Business Agency experts. An education plan that will address the skill sets needed to support the application systems in the new environment has been developed and will be implemented throughout the project. 3/16/2006 Page 10
  17. 17. State of North Dakota Migration Project Plan – V1.2 A key input into the migration/porting strategy will be the skills of the existing IT staff. Introducing new technology might result in decreased availability or productivity as people come up-to-speed on the new technology. 3/16/2006 Page 11
  18. 18. State of North Dakota Migration Project Plan – V1.2 1.2Project Phases Software AG’s approach to the ND migration incorporates the principles of a lifecycle view and incremental development (cycle of architect, implement, and manage). It provides a common language for defining the non-functional requirements of an application platform, enabling ND to use its structured infrastructure methodology. The approach is based on the following phases: • Building the Migration environment (includes startup tasks, data and source code conversion and movement, building, batch set-up, and functional testing) as well as assisting North Dakota in rewriting processes and procedures for ongoing operations support. • Migration activities (includes hardware set-up and all environmental configuration, data and source code movement) • Testing the applications in the new Linux environments • User Acceptance Testing and Training • Manage Phase (identify, resolve, and incorporate modifications and retest) • Implementation/Deployment • Transitioning to Support Phase 3/16/2006 Page 12
  19. 19. State of North Dakota Migration Project Plan – V1.2 2 Technical Architecture The following “real world” scenario for ITD customer access corresponds to the technical architecture depicted in Figure 3. 1. An ND end user will initialize interaction with the ND server environment by clicking on a “Production ND” icon on his/her desktop. This will invoke terminal emulation software to allow the end user’s Windows PC to appear as a VTxxx terminal when connecting to the Linux server. 2. The end user’s identification will be checked through LDAP-based authentication against the State's Active Directory Domain, NDGOV. If a user is allowed access, s/he will be logged into the ND server. 3. The end user’s Linux account will be tailored to run a script designed to initialize the appropriate application environment without any end user interaction. This script will display a menu that provides access to the appropriate ND subsystems. At this point, the user is able to perform all normal work routines. 4. When the end user selects certain options from the various subsystem menus, specific data will be retrieved from, deleted, or stored into the database environment. Figure 3: ND Technical Architecture Bismarck SSH Data Center Connection DB2 Server End User Workstation Natural/Cobol Server Adabas Server Windows Active Directory Authentication Ldap Authentication Windows Active Directory Server 3/16/2006 Page 13
  20. 20. State of North Dakota Migration Project Plan – V1.2 2.1Software Figure 45 below reflects the supporting software, which will be implemented under the new Linux environments. Appendix I provides additional detail information on the software listed below. Figure 4: List of Software Company Product Name Adabas SQL Gateway Software AG 2.2Creating Adabas C the Production Natural Construct Environment EntireX Communicator Natural Construct The new Entire Access environment will Natural Security consist of a two sets of HP blade Predict servers with one Entire Network set providing the Tamino production Natural Productivity Pack environment IBM DB2 UDB Enterprise Server Addition while the other will provide test OnDemand and Rational ClearCase development InfoPrint environments. In Appworx Appworx addition this second set will MicroFocus Revolve Developer be used for Revolve Enterprise Edition Business Enterprise Server MTO Continuity Net Express MTO functions and will be located in MigrationWare Adabas SQL Addin for MicroFocus the State’s Regression manager Mandan SyncSort DMExpress Datacenter with Syncsort production being housed in FilePort Bismarck. Cronus ESPControl Segue Silktest In overview the Pitney Bowes Finalist Software to be architecture will Address Validation used be of a client server nature with one server hosting Natural and Cobol, and the Job Scheduler. DB2 and Adabas will be housed on their own servers. IBM’s Infoprint will be used to manage printing and will be housed on its own server. 3/16/2006 Page 14
  21. 21. State of North Dakota Migration Project Plan – V1.2 As we build the environments and perform benchmark testing, the summary above may change. Expect those changes to be documented in the next release of this document. Common tasks to be performed with all environments include: • Obtain Hummingbird, Attachmate, IBM Communications terminal emulation • Prepare the environments, including backup and restore facilities and backup/restore scripts, and integrate them into the ND network • Identify the software to use in the new environment and acquire licenses, where appropriate – Check current versions of software • Order the right version of SUSE • Define printers for use on the new Linux servers in ND network and order additional printers, if required • Define all users in the authentication system – userids, passwords, profiles, etc. • Load Terminal Emulation software on each client Additionally, Software AG will continue to address the Software AG products and 3rd party product environment (see Item 2.1 above). All appropriate software will be installed in all the appropriate environments. 2.3Creating the Development and Test Environments The development and test environments will be modeled after the production environment. The development environment will consist of 3 servers with the same architecture as production: One server for Natural/Cobol applications and dedicated servers for Adabas and DB2. Note that this development environment will also host the user acceptance test regions. The test region will consist of two servers, one hosting Cobol/Natural with the other hosting both DB2 and Adabas. This test environment will be used to test new releases/patches of vendor supplied software such as Adabas, Natural, DB2, Operating System, etc. 2.4Hardware Server Configurations The servers of choice are HP Blade servers with AMD's Dual Core Opteron CPU, which provides 64-bit addressing. This will provide much better access to memory above 4GB than the 32-bit Xeons. The production Cobol/Natural server will be a BL45 blade with 4 Dual Core Opteron CPUs and 16 GB of memory. While the production Database servers will be BL25 blades with two Dual Core Opteron CPUs and 8 GB of memory. The comparatively large amounts of memory will permit the Operating System and Databases to aggressively cache disk reads, thus elevating performance. Use of blades will also aid in communication with the database servers. If the Natural/COBOL applications were running on blades in the same enclosure database, requests would never leave the enclosure, resulting in Gigabit connectivity within the enclosure. The production systems will be located in the Bismarck data center, with the Mandan data center hosting the development/test environments. The two centers will be connected via Ethernet, with a maximum bandwidth of 2 GB/sec. 3/16/2006 Page 15
  22. 22. State of North Dakota Migration Project Plan – V1.2 Finally, the environments in both the Bismarck and Mandan data centers will utilize Fiber Channel SANs for data storage. The storage platform of choice for the migrated systems will be the IBM DS6000 line. The DS6000 line does use fiber attached disks within each array. The technology used in the DS6000 is the same as in IBM's Enterprise Storage Server (the Shark) though the DS6000 line fits into a standard 19-inch rack. Mandan Data Center Bismarck Data Center - 2 Gigabit Production Fiber Development Test Environment Environment Natural/Cobol Server – 4 Natural/Cobol Natural/Cobol CPU BL45 Server – 2 Server – 1 CPU BL25 CPU BL25 Adabas DB2 DB2/Adabas Infoprint Infoprint Server – 2 Server – 2 DB2 Adabas Server – 1 Server(s) Server(s) CPU BL25 CPU BL25 Server – 1 Server – 1 CPU BL25 CPU BL25 CPU BL25 Figure 5: Server Configuration 2.5System Performance Requirements In developing this plan, Software AG worked from the basic assumption that performance must be as good, and preferably better than it was before the migration. Some details are available on the current systems’ performance, but additional benchmarking will have to be performed to quantitatively evaluate the performance of the migrated systems for both online and batch. The key metric is the mission effectiveness of ITD to meet your customers’ expectations. We have used five processes in this plan to reduce risk regarding system performance. 1. We are using a phased approach to ensure system performance can be validated to allow for modification of the configuration. 2. We will be performing initial benchmark tests, both single queries and “flood queries” to identify any issues or concerns. 3. We have incorporated significant testing plans into the project to ensure we understand how individual components of the applications interact with other applications. 4. We will integrate testing performance into the current long-term network performance project currently in process. 3/16/2006 Page 16
  23. 23. State of North Dakota Migration Project Plan – V1.2 5. ND can also undertake an option to implement Compuware QA center or Seque Performance Monitoring as part of a short-term load test, which can simulate 450 or more concurrent users. This can allow for additional tuning of system configurations to provide the best possible performance. 3/16/2006 Page 17
  24. 24. State of North Dakota Migration Project Plan – V1.2 3 Testing 3.1Testing in the Linux Environments at ND A well-designed test plan facilitates the testing of ND within the scope of the current functional and technical requirements. Specifically, the ND Test Plan must meet the following objectives: 1. Provide test scenarios that adequately enable ND to verify and validate that the migration to Linux has been successful. 2. Demonstrate that the migrated system meets the functional and technical requirements of ND. 3. Demonstrate that the migrated system meets the business needs of ND. To meet the testing objectives, test scripts and/or other verification methods are required for all documented requirements of modules affected by the migration. The Software AG Test Support Team, working with its North Dakota support team, will be responsible for development of the test plan. The Test Support Team will also support the testing process by organizing test results, tracking testing progress, accumulating statistics of successful and unsuccessful test executions, bug tracking, and compilation of a final test report. ND Agency Testers with the assistance of the Test Support Team are responsible for actual execution of the final acceptance test. This group will consist of ND employees that are familiar with the functional and/or technical aspects of the ND system. This plan establishes the framework for development and execution of the tests associated with the original mainframe application and the migrated Linux-based system. The test plan includes several methods for verifying the ported system, including testing scenarios, report verifications, data entry, and input/output feedback. Tests that need to be planned and executed include: • Unit Testing - Unit testing is an ongoing process. Throughout the migration and batch set- up phases, Software AG will perform unit testing of the migrated application components. • System & Integration testing – As a final test prior to commencement of User Acceptance Testing, Software AG will perform an end-to-end unit test of all applications. This test will be performed using the test scripts prepared (and subsequently accepted by ND) as the template to ensure all required functions are tested. This type of comprehensive testing will relieve end users of having to deal with the more “obvious” bugs. Whereas a wide range of possible test options are possible, at a minimum Software AG will verify that: o System query results “look” correct; o The group of ND end users selected to test the system can readily navigate from screen to screen, comfortable with the “look and feel” of the migrated system and are able to perform the same functions they employ today in their daily jobs; and o System response time is comparable to, or superior to, the current system • User Acceptance Testing 3/16/2006 Page 18
  25. 25. State of North Dakota Migration Project Plan – V1.2 3.2Testing Methodology In validating the system prior to production acceptance, testing methodology shall include: • High-level Approach • Validation Types • Test Methods • Test Execution • Test Reporting and Feedback 3.2.1High-level Approach The Test Support Team will be comprised of Software AG staff, North Dakota staff assigned to Software AG, North Dakota ITD staff and North Dakota agency staff. During the test planning phase, the Test Support Team will first establish the test methods (i.e., scripts, inspection, etc.) that will be required for the various components of the migrated system. Based upon the different methods required for each segment of the system, the test team will develop specific test scripts, scenarios, and other verification methods that will be used for the actual testing. The tests will be designed to demonstrate that each ND module meets the applicable functional and technical requirements through the verification and validation of test results. All Four groups comprising the Test Support Team will execute the scripts (potentially at different times) on the existing mainframe system to verify expectations and accuracy. After the ND code is migrated to the new platform, user acceptance testing will begin. Prior to the initiation of actual testing activities, it is necessary to set up dual environments on the mainframe and Linux with identical initial data. Initially, the dual systems will be used to validate the data conversion, reports, and interfaces. During the scripted testing, the dual environments may be required to investigate any discrepancies that may be found. The ND Agency and ITD Testers will perform the actual tests. The Test Support Team will provide support assistance to the ND Testers during user acceptance testing. After testing is completed, a test report will be submitted to ND for review and formal acceptance. Testing related activities will include: • Establishment of the test methods (i.e., scripts, inspection, etc.) that will be required for the various components of the migrated system. • Development of the specific and detailed test scripts, scenarios, and other verification methods. The scripts will mirror actual production activities and workflows as closely as possible. • Validation of the testing scenarios against mainframe ND. • Review and approval of the test documents by ND. • Exploratory Testing to understand current application behavior. Further testing related activities will include: • Setup of dedicated test areas in both mainframe and Linux environment. • Testing by the ND Testers. 3/16/2006 Page 19
  26. 26. State of North Dakota Migration Project Plan – V1.2 • Organizing test results, tracking testing progress, accumulating statistics of successful and unsuccessful test executions, and issue tracking by the Software AG and ND ITD Test Support Team. • Scheduling and execution of an end-to-end system test. • Compilation of a final test report. • Support for the go/no go decision. 3.2.2Validation Types Depending on the item tested, various validation types will be used to verify proper operation of the migrated ND system. While the majority of the documented functional requirements and verification of ND functionality will utilize the scripts and scenario based testing, other areas will use other methods. For example, for many of the technical requirements it is more appropriate to determine compliance through demonstration or inspection, or compliance may be evident. This methodology provides the flexibility to select the most appropriate methods for system validation. It is envisioned that the technical requirements will mostly be validated through non-scripted methods. The five validation (5) types are: 1. Scripts – A scripted test refers to the use of a predefined, detailed set of steps and actions that are intended to emulate a typical business process performed on the system being tested. As mentioned above, validation of ND operational functionality and compliance with the functional requirements will be done using script and scenario based testing. Test scenarios will be created for typical ND activities in order to verify ND functionality. Each scenario may contain multiple closely related test cases. A single scenario may contain multiple requirements, as the scenarios are designed to mimic daily activities and functions within ND, and these functions can cover more than one requirement. A cross- reference mapping will be created to verify and demonstrate that sufficient test scenarios exist to represent all of the functional requirements. 2. Demonstration - Validation through demonstration refers to the confirmation of functionality by observing the behavior of the system. The tester must witness one or more examples of behavior that demonstrates that the requirement is met by the system. A checklist is used to document compliance and a detailed script is not prepared in advance. For high-level requirements without explicit data values or detail specifications, demonstration methods are more applicable. Requirements Validation Checklists will be used to document compliance. For example, compliance with Technical Requirement – “Display warning messages/verification request when the user is about to submit a sensitive transaction” can be documented with the demonstration validation type. 3. Inspection - Validation through inspection is performed by review of system specifications, item attributes or other reliable documentation. Inspection is used for high-level requirements for which the demonstration method is not practical or viable. An example of a requirement that will be verified through inspection is Technical Requirement – “Utilize scalable software and database components that comply with the (open) standards specified by ND at the beginning of the system development phase.” Many of the hardware and software 3/16/2006 Page 20
  27. 27. State of North Dakota Migration Project Plan – V1.2 requirements will be verified through inspection. 4. Comparison - Comparison validation refers to comparison of features, functions, or data from the one system to another. In the case of ND, comparison validation refers to the comparison of migrated ND to what is produced by mainframe ND under an identical set of data, processes, programs, and procedures. Comparison validation is the envisioned method for verification of the data conversion and reports. A comparison of reports from the mainframe control system and the migrated system will be used to verify that (1) the data port was successful and that (2) reports are operating properly. The comparison method will also be used extensively in the testing of interfaces. This is described in greater detail in Section 3.2.3.1 below. 5. Evident - The evident validation method refers to situations where compliance with the requirement is overwhelmingly obvious. Evident validation can be used for requirements when compliance is obvious and formal additional testing is not required. For example, Technical Requirement – “Provide the ability to communicate with clients using IP protocol.” The fact that users are able to access the system from their workstations over the ND network makes it obvious that this requirement has been met. 3.2.3Test Methods In order to test all aspects of the migrated system, multiple testing methods utilizing the validation types defined above must be used. Comparison Testing, Scripted Testing, and Non-scripted Validation will all be utilized at times: 3.2.3.1Comparison Testing Data Conversion – the first testing activity is validation of the data that has been migrated from the mainframe. During the migration, ND data will be transferred from the existing mainframe system to the new Linux infrastructure. Validation of the data will be performed by comparison of the migrated data to the data on the mainframe. Validation of the data migration must be done before testing activities can alter the data. Reports - To validate that reports are operating properly, a set of reports will be printed out of both ND environments (mainframe and migrated) and compared. Reports used to validate the data conversion have already been compared and can be excluded from this exercise. This test will validate that the reports print as expected and perform as they did on the mainframe. It should be noted that the reports will also be run during execution of the scripted tests. The primary purpose of running reports as part of the scripted test is to validate the data entry, manipulation, and storage capabilities of the migrated system. Interfaces (to both internal and external systems) - ND has interfaces to both internal and external systems. For purposes of this document, internal interfaces are those that are within and under the control of ND. External interfaces are those that pass data between ND and a system that is not under the direct ND staff control, such as Social Security and other Federal Agencies. For a complete listing of the application interfaces see Appendix G. There are two types of external interfaces, inbound and outbound. Inbound interfaces refer to entry points for external data into ND. External interfaces provide ND data to other systems. The validation method varies for the different types of interfaces. The following is a description of the interface validation method. 3/16/2006 Page 21
  28. 28. State of North Dakota Migration Project Plan – V1.2 • Outbound External – The initial interface validation for outbound external interfaces will be performed by comparison of an interface data file between the migrated ND and mainframe ND. For each interface a historical time period will be selected. The interface will then be run for the selected time period on both systems and the output will be compared using a file comparison utility. During this initial testing the interface data will not actually be sent to and processed by the destination system. During the final end-to-end test, the outbound interface will actually be submitted for processing by the receiving systems of entities that have agreed to participate in this test. • Inbound External – In the case of inbound external interfaces, a copy of an actual interface file will be imported into the system. When selecting a file for processing, it will be important to choose data that is consecutive to the most recent data in the system. • Outbound Internal – In the case of outbound internal interfaces the data can be imported into the receiving system and processed where it is practical to do so. The receiving system will then be validated to see if the received data has been imported correctly and if reports and other outputs are correct. • Inbound Internal – The procedure for validation of internal inbound interfaces will be identical to the one used for external inbound interfaces. The initial task will be to confirm the inventory of interfaces and categorize the type (internal vs. external; inbound vs. outbound) of each interface. For each interface, it will be necessary to identify the following attributes: • Interface name • Interface type • Interface description • Interface points of contacts • Testing method • Time span (beginning and end date) to be used • Verification method Dataset Responsibility Interface Interface Verification Testing Testing Names and Points of Target Name Type Method Method Date Description Contact Figure 6: Sample Interfaces Inventory Matrix Interfaces Testing Detail The ND interfaces are tested by initially utilizing the tools provided by each interface type. For example, if the interface uses FTP as its delivery mechanism, FTP commands will be used to verify and qualify its internal workings and functionality. These commands will be executed from a command prompt or application interface dependent upon the FTP application used. The objective is to test the interface for connectivity and appropriate configuration of its target destination. 3/16/2006 Page 22
  29. 29. State of North Dakota Migration Project Plan – V1.2 Once the manual testing of the interfaces has successfully concluded, the next step will be to transfer various sample files to its target destinations. Following this procedure and to complete testing on the interfaces, full transfers of actual publications and reports are transmitted to their respective target destinations. Validation and verification of the transmissions will be conducted through manual or automated verification tools by comparing the “Transferred” and/or “Received” files against the original files. Test scripts are provided to exercise the aforementioned testing method and may be described in the following manner: Script: Manual Testing Steps Interfaces Data matrix (Short) Interface Table and dataset details (Full) Publication Tables with full composing, dataset details, frequency and other notes 3.2.3.2Scripted Testing Scripted testing will be used to test the ND functionality and adherence to the functional requirements. Test scenarios will be created for typical ND activities in order to verify ND functionality. Each scenario may contain multiple, closely related test cases. A single scenario may contain multiple requirements, as the scenarios are designed to mimic daily activities and functions within ND, and these functions can cover more than one of the requirements. A cross- reference mapping will be created to verify and demonstrate that sufficient test scenarios exist to represent all of the functional requirements. Appendix E contains a sample test script, and Figure 8 represents the hierarchical relationship between scenarios, requirements, and test cases. Requirement 4.02.01 Requirement 4.04.08 Test Case BR.1.3 Scenario 4.2.BR.1 Test Case BR.2.12 Test Case BR.4.5 Figure 7: Scenarios, Requirements, and Test Cases 3.2.3.3Non-scripted Validation As mentioned above, the majority of the technical requirements will be validated using non-scripted testing. It may be practical to utilize the scripted tests for some of the technical requirements, such as the publications section, however; for the majority of the 3/16/2006 Page 23
  30. 30. State of North Dakota Migration Project Plan – V1.2 requirements other verification methods will be used. The various methods listed above will be used as appropriate. Requirements validation checklists will be created to organize and formalize the testing process. 3.2.4Test Execution 3.2.4.1Naming Conventions for Scenarios and Test Cases A standard naming convention has been developed and is detailed in a separate test strategy document. Please see Linda Weigel or Carl Bondel for that document. 3.2.4.2Pre-test Preparation The following tasks will need to be completed before actual testing begins: • Team identification – The ND Testers will need to be identified. Testers should include functional users that are familiar with the system and will be able to identify any anomalies. Minimal Linux navigation training will be provided to the testers. Based upon the testers and their typical jobs, tests will be assigned to individual or groups of testers. • System preparation – As described above, a similar environment will need to be established on the mainframe ND with identical data. The initial testing activities will involve comparisons between the two systems that will validate proper operation of the migrated ND. Once the systems have been established, it will be important to create a backup of both. It may be desirable to return the systems to this baseline state at future points in the testing. Periodic backups of the test systems should also be performed. The selection of an “as of date” for the data is important. The “as of date” is the date through which both systems have data. The date should be selected so that there is real data available for dates after the “as of date.” That real data will be valuable for the scripted testing and testing of the inbound interfaces. If the testing takes place during an adjournment, the “as of date” should not be the day of adjournment. It should be at least a day earlier than the adjournment. • Establish test recording and reporting procedures – Test recording and reporting procedures need to be established. The progress of the testing tasks will advance as successful tests are completed. Unsuccessful tests, as well as questions, will need to be tracked for resolution and completion. A formal and documented procedure will need to be initiated to enable testing to proceed efficiently. • Testing kickoff meeting – Prior to initiating the actual testing a kickoff meeting will be held. The meeting will serve to communicate roles and responsibilities, schedule, scope, tasks, and goals of the testing activities. 3.2.4.3Testing Sequence As described above, testing will take place in a specific order. Initial validation will be performed through comparison of the mainframe and migrated systems. It is, therefore, important that this comparison is performed prior to any data entry activities on the migrated system. The following is the recommended order of testing activities: 3/16/2006 Page 24
  31. 31. State of North Dakota Migration Project Plan – V1.2 1. Validate data – This validates that historical data has migrated properly. This will be primarily performed through reports with a limited degree of inspection where required. 2. Validate reports – Report comparisons will confirm that the new reports are working properly. 3. Validate interfaces – Some of the interfaces can be validated through comparison with a similar interface constructed from the mainframe. This would also need to take place prior to any data entry activities. 4. Scripted testing – Scripted testing will be used to validate much of the functionality of the ND system. Agencies may add their own scenarios for testing in addition to the scripts that will be developed by the test support team. 5. Non-scripted validation – Non-scripted validations will be used where scripted testing is not applicable. This can actually be done at any point. 6. Benchmark testing – Benchmark testing is conducted to verify and analyze system performance, scalability, and overall stability. Benchmark testing is executed by a group of testers using a set of specific test scripts that will measure system and application performance during normal system activity. Executing batch jobs in a timed fashion to be run on the system will create the system load. During these batch executions, the same testers will again perform the same test scripts activities and record the response time on the loaded system. The performance result of the system can then be determined by comparing the measurements between the baseline tests and the load tests. Depending on the overall result, possible tuning of the system may be warranted and applied. 7. End-to-end test – Following the conclusion of the other testing activities, a full end-to-end test will be conducted. During the end-to-end test, external interfaces will be submitted to all parties that have agreed to participate in the end-to-end test. A more limited set of test cases may be selected for this test at the option of ND. The primary purpose of this test is to validate the operation of the external interfaces in as near a production environment as possible. 3.2.4.4User Impact The use case and test script creation will be coordinated with both ND ITD and the Business/Agency groups to ensure the least impact their normal work schedule, especially during peak processing periods. 3.2.4.5Testing Schedule Please refer to the Project Schedule (Appendix A) for the complete testing schedule. 3.2.5Test Reporting and Feedback The ND ITD and Business/Agency groups will perform the actual tests. Software AG Test Support Team will support the ND Testers and perform the following activities: • Monitoring progress of the testing tasks • Maintaining the status of each test case and/or script 3/16/2006 Page 25
  32. 32. State of North Dakota Migration Project Plan – V1.2 • Accumulating statistics for passed and failed tests • Maintaining a problems/unknowns database • Tracking the resolution of defects and/or questions. ND Testers will submit test results to the Software AG Test Support Team, which will be responsible for updating the status of each test case to indicate if the item has been tested and if so, what the results were. In cases where the test was not successful or there is a question regarding the outcome of the test, Software AG Testers will work with the developers to seek a resolution to the problem. In some cases, system behavior may need to be confirmed on the mainframe. The problem will be reported via the WMS Problem Log. Testers will be asked to assign a severity to problems encountered. Problems will be prioritized in severity order. Errors identified through testing will be discussed with development team members and/or the Project Manager to verify that the observed behavior constitutes an error. The tester will log identified errors onto a problem-tracking form and electronically send it to the Software AG Test Support Team. The Test Support Team will coordinate a resolution with the development team. After the development team corrects an error, the Test Support Team will record the resolution onto the problem-tracking form and notify the test team. The function will then be retested using the same Test Script that detected the error and the tester will enter validated fixes onto the problem-tracking form. The Software AG Test team will track the status of retests required and performed. The Software AG Test team will provide management reports to assist ND in understanding the progress of the testing. The status of each test case will be tracked on the report. At the conclusion of testing activities, a final report will be produced and submitted. 3/16/2006 Page 26
  33. 33. State of North Dakota Migration Project Plan – V1.2 3.2.6DISCREPANCY MANAGEMENT PROCESS Discrepancy management involves capturing, reporting, escalating, tracking and resolving problems that will occur on this project. For this project we will use ITD’s Work Management System (WMS) to track those discrepancies. During all phases of testing, we will be recording discrepancies as “problems” in WMS. Problems are defined as discrepancies in which someone other than the actual tester must take action to correct. If a tester finds a problem that can be traced to his/her script or other internal document, then it is resolved by them without creating a problem. If a problem cannot be easily resolved by the testing team or the technical migration team, then it may be elevated to an issue. Issues require a higher level of management support to resolve. The following process diagram will control issue and problem creation for the project: Mainframe Migration Project – Handling Discrepancies , Problems and Issues User Acceptance Enter discrepancy Can tester Work with Tester Identify Testing Discuss with resolve Yes Test Application as a Problem in to Retest Discrepancy Assigned tester discrepancy? WMS Agencies No Internal Test or Internal Test User Acceptance Can tester Elevate to James Can technical Identify Testing Enter as a and/or his team as team resolve Test Application resolve No Discrepancy Problem in WMS appropriate discrepancy? discrepancy? Yes Tester coordinates Tester with Technical No Segue is being Yes, team to fix considered to track Usually Data or Script Issue discrepencies Outline issue to Test Manager Fix and Retest Should the Handle outside problem be No WMS (not entered as an recommended) Member of issue in WMS Can Project Management Identify Project No Managers Team enters into Concern Yes resolve? WMS as an Issue Management Team Enter Problem in Yes WMS as an issue (Testing Manager) Does the resolution of the Management concern: Team Resolves Do others need Enter into WMS as 1.) Change (communication to be informed? Yes an information Using WMS project scope via e-mail) item workflow, 2.) Change project management team schedule or cost? tracks and ensures 3.) Change resolution as projects technical priority indicates direction? No Action 3.2.7Recording Problems in WMS A problem is defined as a discrepancy in which the migrated objects are not performing as expected, based on the validation routines described in the appropriate test cases. 3/16/2006 Page 27
  34. 34. State of North Dakota Migration Project Plan – V1.2 Any team member can define a problem. Most testing team members will have direct access to WMS. If someone does not have access, they should work with other members of the migration team to define the problem. The following are the steps are required to enter a problem into WMS: Click on Problem Log and the following form will appear: 3/16/2006 Page 28
  35. 35. State of North Dakota Migration Project Plan – V1.2 You will need to complete the following fields with the appropriate information: • Short Description: Short description for the problem • Sub-Project: If you have sub-projects, you can select the sub-project that the issue relates to. • Test Phase: Linux Verification testing will use “System Test” and User Acceptance testing will use “Acceptance Test” • Log Type: will usually use “problem”. Other values should only be used with Test Manager(s) agreement. • Priority: As defined in a later section. • Object Name: The name of the object that is has the discrepancy. • Test Scenario: A brief indication of the test scenario, with reference to the test case number. • Tester Sign on: The sign on of the person executing the test. • Description: Detailed information on the issue • Initiator: Indicates who initiated the action item. Can only select one person. 3/16/2006 Page 29
  36. 36. State of North Dakota Migration Project Plan – V1.2 3.2.8Recording Issues in WMS An issue is defined as a problem or question that, in order to be resolved, requires a decision be made by the Project Manager, Project Sponsor or Executive Committee, depending on the priority or impact that the issue will have on the overall project. Only the test manager(s) or the technical migration manager can define issues or elevate a problem into an issue. Testing team members will bring potential issues to a Testing Project Manager to evaluate and determine if it should be entered as an issue. The following are the steps are required to enter a issue into WMS: Click on Issues and the following form will appear: 3/16/2006 Page 30
  37. 37. State of North Dakota Migration Project Plan – V1.2 You will need to complete the following fields with the appropriate information: • Short Description: Short description for the issue • Sub-Project: If you have sub-projects, you can select the sub-project that the issue relates to. • Date Required: Indicates the date by which the issue needs to be resolved. Enter the date or select from the calendar. • Description: Detailed information on the issue • Alternatives and Impacts: Describes all alternatives that could be considered and the impact of selecting the alternative. The alternatives/impacts could be modifications to a system, procedural change, customer impact, or financial ramifications. If there is an impact to the cost or schedule, an impact of project change must also be created. • Recommendation: Describes which alternative is recommended. • Department Notes: Area for recording any type of notes. • Initiator: Indicates who initiated the action item. Can only select one person. • Assignee: Select the individual who is assigned to the action item. Can only select one person. • Notifications: Select the individuals who are to be notified when the issue is submitted for review. Can select multiple individuals. • Attachments: This area is used for storing the documents relating the action item. • Resolution: Description explaining what the assignee’s resolution is to the issue. The resolution maybe an agreement with the recommendation or a completely different resolution. If the resolution is different from the recommendation, make sure to clearly explain the resolution. 3/16/2006 Page 31
  38. 38. State of North Dakota Migration Project Plan – V1.2 • Comments: This area can be used to record any information relating to this issue. • Deny/Return/Approve: Used to indicate whether the impact is denied or approved or needs to be returned for correction. Only select one. 3.2.9Key Definitions for Issues Priority The priority defines how quickly the reported issue needs to be resolved. The following matrix defines the priorities: Priority Definition Action(s) 1 Severe Issue resolution within 8 hours, or Acceptable course of action discussed and agreed upon by ND, Decision communicated to end users and all stakeholders 2 High-Impact Problem resolution within 2 days or as agreed to by Testing Manager 3 Intermittent Resolution within 5 days in the absence of higher priority problems, or Raise to priority 2 after 5 days, if warranted 4 Format/Appearance Resolve as schedule allows Stage The stage defines where the issue is in its life-cycle of resolution: Stage Definition Open The issue has been reported but not assigned Submitted The issue has been assigned. The assigned person becomes the owner and is responsible for the resolution of the issue. Retest The issue has been resolved and is awaiting re-testing Returned The issue has failed re-testing and is reassigned to technical team Closed The issue is closed. 3/16/2006 Page 32
  39. 39. State of North Dakota Migration Project Plan – V1.2 3.3User Acceptance Testing User acceptance testing is an important aspect of the project, contributing to ultimate project success. The test cycle will be established and testing executed in the ND Test environment by the ND team, assisted by the Software AG team. User Acceptance Test Planning entails: • Defining test strategy • Setting test objectives • Reviewing testing methodology • Reviewing pre-defined acceptance criteria • Reviewing test scenarios/test scripts • Estimating time and resources (Software AG activity) • Finalizing test plan (Software AG activity) The User Acceptance Test Execution Process is equally comprehensive, encompassing: • Training team members • Executing test plan • Tracking progress • Performing complete system/integration testing • Documenting test results • Defect reporting • Status reporting • Fixing defects (Software AG activity) • Going through lifecycle testing • Final reporting (Software AG activity) The successful execution of all acceptance testing criteria, the resolution of all problems, and customer sign-off constitute the end of the acceptance testing phase, signaling that the environment is ready for production implementation. 3/16/2006 Page 33
  40. 40. State of North Dakota Migration Project Plan – V1.2 4 Software Development Standards 5.1Best Practices in Software Development Standards While there will be very little new development for this project, it is still important to have consistent and clear processes for the development of new software and the purchase of new products. Following are the system development and technical documentation standards for all new sub- components that need to be created or existing software components that need to be modified. 1. Requirements - Gathering and agreeing on requirements is fundamental to a successful project. Those requirements need to be validated, their size determined (each set of requirements describe functionality from the user’s point of view and they can be converted to function points; assigning function points to a set of requirements helps us understand how large a set of requirements is and the associated effort needed to produce it.), and a plan for implementation established. Then, ND needs to incorporate the sets of requirements into the system design to serve as the foundation of design reviews and turn them into code and documentation. These requirements are the backbone of testing and documentation. When the requirements are clearly stated and testable, they form the basic system test plan. They are also well suited for user acceptance testing. Knowing where each set of requirements is within the software lifecycle is valuable for managing the project and determining status. 2. Architecture - Ensure that the new or modified components or new vendor packages fit within the existing architecture. 3. Design - There are two basic principles: “Keep it simple, and keep it modular.” 4. Construction of the Code - Construction of new code is a very small fraction of the total project effort, but it is very visible, as it will change the user interface. 5. Peer Reviews - It is important to review other people's work. Experience has shown that problems are eliminated earlier this way and reviews are as effective as, or even more effective than, testing. Where possible, two-person teams are employed to assess a particular task. The teams subsequently define and implement an agreed upon course of action to complete the task. 6. Testing - Testing is not an afterthought or cutback when the schedule gets tight. It is an integral part of software development that needs to be planned. It is also important that testing is proactive; meaning that test cases are planned before coding starts and test cases are developed while the components are being designed and coded. 7. Integration - Testing is usually the last resort to catch application defects. It is labor intensive and usually only catches coding defects. 8. Configuration Management - Configuration management involves knowing the state of all objects that make up the ND system or project, managing the state of those objects, and releasing distinct versions of the migrated code. 3/16/2006 Page 34

×