2.120.5 Performance Engineering

Manual Transmittal

September 25, 2015

Purpose

(1) This transmits a revised Solution Engineering (SE) Performance Engineering (PE) Process Description (PD).

Material Changes

(1) This document has been converted to the current Integrated Process Management (IPM) Process Description template.

Effect on Other Documents

• Version 1.0 dated September 18, 2014 is superseded.

Audience

The Performance Engineering Process Description is applicable to all development projects following the Enterprise Life Cycle (ELC) and other organizations having a need to use the Performance Engineering process.

Effective Date

(09-25-2015)

Terrence V. Milholland
Chief Technology Officer

Introduction

  1. This document describes the formal process for implementing the requirements of the Performance Engineering (PE) process. It provides an operational definition of the major components of the process and how to perform each step in the process. This document also describes the logical arrangements of steps that are essential to successfully completing the process and achieving its desirable outcome.

Administration

  1. All proposed changes to this document must be submitted in writing, with supporting rationale, to the Solution Engineering.

Purpose of Process

  1. This document defines the step-by-step instructions on how to conduct the activities used to implement the Performance Engineering process in the Solution Engineering organization. The purpose of a procedure document is to institutionalize and formalize the preferred method of performing tasks that staff is using. The objective is to have everyone using the same tools and techniques and follow the same repeatable steps so that the organization can quantify how well the procedure is working and train future staff members who may not currently know the routine. Ensuring consistency is a critical component for ensuring optimum efficiency.

Overview

  1. A process is defined as “A set of related of activities that accomplish a common goal”. The process definition laid out in this document further breaks down these Activities into Tasks, each of which have a complete set of attributes defined such as data and tool specifications and the role(s) responsible for executing the tasks. The document also includes process goal and objectives, metrics, role definitions, policies and other process related attributes.

Process Description

  1. This Performance Engineering Process Description describes what happens within the Performance Engineering process and provides an operational definition of the major components of the process. This description specifies, in a complete, precise, and verifiable manner, the requirements, design, behavior characteristics of the Performance Engineering process. The Process Description is a documented expression of a set of activities performed to achieve a given purpose. Tailoring of this process in order to meet the individual needs of each project is covered in the Tailoring Guidelines section of this document.

  2. Performance Engineering is a collection of techniques and methods that provides reasonable prediction, measurement, and validation of the performance of applications on a variety of computing platforms at the Internal Revenue Service (IRS). It encompasses the set of roles, activities, best practices, tools, and deliverables applied at every phase of the Enterprise Life Cycle which ensures that a solution will be designed, implemented, and operationally supported to meet the non-functional performance requirements defined for the solution. Performance Engineering is the subset of Systems Engineering that aims to ensure that a project's system solution enables the project to comply with the specified performance and operational requirements without incurring unanticipated cost or delay.

  3. For the purpose of this document, the role of Performance Engineer is provided to describe a set of responsibilities for performing a particular set of related activities.

Goal

  1. The process goal describes a specific purpose or achievement toward which the efforts of the process are directed. Each process has a specific focus and when combined with the other processes, forms a comprehensive framework for delivering and managing services.

    • The goal of the Performance Engineering Process is to address Project Performance requirements.

Objectives

  1. Process objectives describe material outcomes that are produced or achieved by the process. The following is a list of objectives for this process:

    • The objective of the Performance Engineering Process is to manage, control, and predict the performance of the Physical Design.

Workflow

  1. A workflow consists of Activities and Tasks, Inputs and Outputs, Roles, and Flow Diagrams. It describes the tasks, procedural steps, organizations or people involved, required input and output information, and tools needed for each step of the process.

Main Process Diagram

  1. Performance Engineering Flow Diagram

    Figure 2.120.5-1

    This is an Image: 65262001.gif

    Please click here for the text description of the image.

Inputs

  1. Process inputs are used as triggers to initiate the process and to produce the desired outputs. Users, stakeholders or other processes provide inputs. The following is a list of inputs for this process:

    Name Description Supplier
    Business Service Report (BSR) A report that provides an alternative to preparation of a separate BSCR, BSAR and BSRR for projects or releases where a single, integrated document will not introduce significant risk with regard to definition of system scope or architecture. The BSR documents the vision or concept, architecture and requirements analysis that form the basis for subsequent business solution design, development, integration, and testing Requirement Engineering
    Project Management Plan (PMP) The PMP defines the project's scope of work and its approach to managing all project activities. The purpose of the PMP is to provide a framework for managing project activities and for completing the project successfully. The PMP is a requirement for all IRS IT projects and is a key project planning artifact. Project Manager
    Design Specification Report (DSR) The Design Specification Report (DSR) provides explicit information about the requirements for a system and how the system is to be put together. Technical Solution Process
    Interface Control Document (ICD) The ICD defines the details for boundary conditions and data at the design solution interfaces. The purpose of the ICD is to establish an agreement of responsibilities among the organizations owning the interfacing entities. The ICD is first created in the Preliminary Design phase (MS 3) and is subsequently updated during the Detailed Design phase (MS 4A). Technical Solution Process
    Test Environment Government Equipment List (GEL) The GEL provides a complete listing of equipment to be installed for use in various system environments. The system environments needing a GEL are: Development, Unit Test, Integration, Production and Disaster Recovery. The purpose of the GEL is to identify and track the incremental hardware and software required by a project for the proposed system. Technical Solution Process
    Final Integration Test (FIT) Environment GEL The Final Integration Test (FIT) is a test conducted to determine if the performance requirements of a specification or solution are met. Technical Solution Process
    System Test Plan (STP) The System Test Plan (STP) can be used by systems classified as New Development or Planned Maintenance. The STP is an Enterprise Life Cycle (ELC) requirement. The purpose of the STP is to provide a standard artifact to summarize the complete test effort for the release. The STP gives the project an opportunity to mitigate risks that may cause delays to project implementation. Software Testing Process
    Production Environment GEL The GEL provides a complete listing of equipment to be installed for use in various system environments. The system environments needing a GEL are: Development, Unit Test, Integration, Production and Disaster Recovery. The purpose of the GEL is to identify and track the incremental hardware and software required by a project for the proposed system. Technical Solution Process
    End of Test Report (EOTR) The End of Test Report (EOTR) is a requirement for all testing and may be used as an Enterprise Life Cycle (ELC) functional equivalent for the End of Test Completion Report (EOTCR). The purpose of the EOTR is to provide a standard artifact to summarize the complete test effort for the test type(s). The EOTR also allows the test managers an opportunity to mitigate risks that may cause delays to project implementation. Software Testing Process
    Computer Operators Handbook (COH) The Computer Operator Handbook (COH) provides instructions to the system operator for the proper execution and validation of the technical architecture and the on–line processing specifications for Selection and Workload Classification of the solution. It does this by supplementing standard operational instructions with other information that may assist in the understanding and maintenance of Selection and Workload Classification. Technical Solution Process

Outputs

  1. Each process produces tangible outputs. These outputs can take the form of products or data and can be delivered to a user or stakeholder, or, they can be used as inputs to other processes. Outputs are measurable in terms of quantity and quality.

    Name Description Supplier
    Performance Section in DSR Design Specification Report section addressing design requirements for performance. Project Manager
    Performance Engineering Model (PEM) A Performance Engineering Model provides objective or subjective results used as input into the Enterprise Life Cycle. Project Manager

Activities

  1. An activity is a major unit of work to be completed in achieving the objectives of the process. A process consists of a sequence of related activities that transforms inputs into outputs and performed by the roles defined in the process. Identify the activities in the process and provide a brief description. The activities must correspond with the high-level process flow diagram above.

    ID Name Description
    PE 1.0 Performance Requirements The purpose of this process step is to support the development of useful and meaningful performance requirements and contribute to the BSR Business System ReportThe result of this process is completing an agreed-to set of requirements.
    PE 2.0 Logical Design The purpose of this process step is to work with the Enterprise Technical Solution process to define interfaces and data flow and support the development of the final performance requirements for the various business functions. In addition, the process step is used to refine the initial performance information; develop the initial Performance Engineering documentation required by the Enterprise Life Cycle (ELC); and, model alternative logical designs. The result of this process is completing an agreed-to set of Design Specification reports, Interface Control Documents (ICDs), Testing Environment Government Equipment Lists (GELs), System Test Plans (STPs), and Business Systems Requirements.
    PE 3.0 Physical Design The purpose of this process step is to ensure the logical design is transformed into a physical design by supporting the project development of the physical design by modeling alternative physical designs; refining the performance models based on the final physical designs; developing performance budgets for the processing threads; supporting performance test planning in instrumenting the software; and taking the necessary steps needed to ensure that test data will be available to verify that the project performance requirements are being met. The result of this process is completing an agreed-to set of DSRs, ICDs, Production Environment GELs, STPs, and Business Systems Requirements.
    PE 4.0 Implement the Physical Design The purpose of this process step is to refine the application performance model as a result of any new information from installation of the project software in the production environment; supports performance tuning of the physical design; and updates to the performance sections to reflect the changes to the Application Performance Model. The result of this process is completing an agreed-to set of Design Specification Reports with updated testing results and final documentation to pass on to Enterprise Operations (EOps) and End of Test Report (EOTR).
    PE 5.0 Operations and Maintenance The purpose of this process step is collect project performance and resource utilization data in the production environment; update the Enterprise Performance Engineering Model as appropriate based on that data; and incorporate information into the models any design changes that are made during the Operations & Maintenance phase. The result of this process is completing a Computer Operator’s Handbook (COH) that provides input on performance monitoring as needed and the system configuration that is used to update, maintain, or improve performance.

Roles

  1. Each process defines at least one role. Each role is assigned to perform specific tasks within the process. The responsibilities of a role are confined to the specific process. They do not imply any functional standing within the hierarchy of an organization. For example, the process manager role does not imply the role is associated with or fulfilled by someone with functional management responsibilities within the organization. Within a specific process, there can be more than one individual associated with a specific role. Additionally, a single individual can assume more than one role within the process although typically not at the same time.

    Name Description
    Performance Engineer Manages the various Performance Engineering activities that need to be conducted to support a project. Key responsibilities include: capturing and analyzing performance data to forecast potential capacity issues; assisting with identifying what metrics to capture; adding to or scaling up to meet capacity and performance objectives; ensuring satisfactory accomplishment of all performance engineering activities; defining resource consumption relationships in terms of functional workloads for the information technology (IT) infrastructure; developing test cases; ensuring performance tests are administered; collecting and analyzing data; ensuring performance issues are identified and addressed; and, generating testing reports.

Process Control

  1. Activities involved in ensuring a process is predictable, stable, and consistently operating at the target level of performance.

Controls

  1. Process controls represent the policies and guiding principles on how the process will operate. Controls provide direction over the operation of processes and define constraints or boundaries within which the process must operate.

    Name Description
    Performance Engineering Policy Performance Engineering is a required activity mandated by the IRS CTO.
    DSR Performance Section The IRS IT Solution Engineering Organization will design the Performance aspects of the DSR.
    Performance Testing Prior to acceptance by the Business Owner, all Physical Designs will be formally tested to prove that they meet all Performance Requirements.
    Performance Monitoring Performance Monitors will continuously verify that Performance Requirements are being met.
    Performance Monitor Reporting Performance Reports will inform the Business Owner, Service Level Management, and IT Operations Managers regarding the status of Performance Service Level achievements.

Metrics

  1. Metrics are used for the quantitative and periodic assessment of a process. They should be associated with targets that are set based on specific business objectives. Metrics provide information related to the goals and objectives of a process and are used to take corrective action when desired results are not being achieved and can be used to drive continual improvement of process effectiveness and efficiency.

  2. Management will regularly set targets for process performance, gather quantifiable data related to different functions of the Performance Engineering process, and review that data in order to make informed decisions and take appropriate corrective action, if necessary. All Measurements will have a defined data dictionary, map to the organizational strategic goals, and be documented in a Process Measurement Plan. The Process Measurement Plan template is available in the IT PAL.

Policies

  1. Policies outline a set of plans or courses of action that are intended to influence and determine decisions or actions of a process. Policies provide an element of governance over the process that provides alignment to business vision, mission and goals.

Process Management
  1. Statement: The Performance Engineering process will have a single Process Owner and a separate Process Manager, responsible for implementation and ensuring adherence to the process. The process will be reviewed regularly to ensure that it continues to support the business requirements of the enterprise. The process will be designed and developed based on Return on Investment (ROI) to the business. Process metrics will be focused on providing relevant information as opposed to merely presenting raw data.

People
  1. Statement: Roles and responsibilities for the process must be clearly defined and appropriately staffed with people having the required skills and training. Upper management to the staff and business customers of IT must clearly and regularly communicate the mission, goals, scope and importance of the process. All IT staff (direct and indirect users of the process) shall be trained at the appropriate level to enable them to support the process.

  2. Rationale: It is imperative that people working in, supporting or interacting with the process in any manner understand what they are supposed to do. Without that understanding Performance Engineering will not be successful.

Process
  1. Statement: The Process Owner must approve modifications to the Performance Engineering process. The design of the process must include appropriate interfaces with other processes to facilitate data sharing, escalation and workflow. The process must be capable of providing data to support real-time requirements as well as historical/trending data for overall process improvement initiatives. The process must be fully documented, published and accessible to the various stakeholders of the process. The process will be reviewed on a periodic basis in order to ensure it continues to support organizational goals and objectives (continuous improvement). The process must include Inputs, Outputs, Controls, Metrics, Activities, Tasks, Roles and Responsibilities, Tool and Data requirements along with documented process flows. The process will be kept straight forward, rational, and easy to understand.

  2. Rationale: The process must meet operational and business requirements.

Technology and Tools
  1. Statement: All tools selected must conform to the enterprise architectural standards and direction. Existing in-house tools and technology will be used wherever possible, new tools will only be entertained if they satisfy a business need that cannot be met by current in-house tools. The selection of supporting tools must be process driven and based on the requirements of the business. Selected tools must provide ease of deployment, customization and use. The selected tools must support heterogeneous platforms. Automated workflow, notification and escalation will be deployed wherever possible to minimize delays, ensure consistency, reduce manual intervention and ensure appropriate parties are made aware of issues requiring their attention.
    The tools used by this process are the following:

    • Enterprise Systems Management (ESM)

    • Change Management System (CMS)

  2. Rationale: Technology and tools should be used to augment the process capabilities, not become an end themselves.

Tailoring Guidelines

  1. The tailoring guidelines identify the allowable variations of the IT organization’s standard process as needed for adjustments (adding, deleting, modifying) relative to specific operational or functional needs of another organization. Process tailoring is about roles and procedures, not the standard process or major activities defined in this process. All tailoring request, with supporting rationale, must be submitted in writing to and approved by the Performance Engineering owner.

Training

  1. Process training involves training all stakeholders about key processes that are crucial for an organization to deliver business objectives. Training provides clarity to employees on a set of procedures that needs to be carried out as part of the process and the best possible way to do them. List below the training resources available for this process:

    • Design Specification Report Training

    • Performance Engineering Training

Performance Engineering Procedure

  1. Procedure

PE 1.0: Performance Requirements

  1. Support the Development of Useful and Meaningful Performance Requirements – Exit Milestone 2 - Requirements

Performance Requirements Activities
  1. ID Description Role RACI
    PE 1.1 Meet with stakeholders to discuss and understand the future vision and the conceptual system solution. Meetings occur to analyze and obtain an understanding of the future vision and the conceptual system solution. Performance Engineer R
    PE 1.2 Initiate discussion with stakeholders to consider performance engineering. Discussions take place to better understand the existing resources; historical data if available; models of existing systems; and, how predictions can be made. Performance Engineer R
    PE 1.3 Derive non-functional performance requirements. Stakeholders understand and approve non-functional performance requirements that are documented and stored in the organization’s document repository. Performance Engineer R,A
    PE 1.4 Address performance, capacity, reliability, and availability requirements including inter-site connections; individual components and site connections. Document agreed upon performance, capacity, reliability, and availability requirements following project’s Requirements Management process. Performance Engineer R,A
Performance Requirements Flow Diagram
  1. Figure 2.120.5-2

    This is an Image: 65262002.gif

    Please click here for the text description of the image.

PE 2.0: Logical Design

  1. Define Logical Design Interfaces and Data Flow – Exit Milestone 3 – Logical Design

Logical Design Activities
  1. ID Description Role RACI
    PE 2.1 Analyze available workload data. Identify peak periods and volumes. Workload data is reviewed and analyzed and peak periods and volumes are identified and documented. Agreed upon data are maintained using the project’s Version Control procedures. Performance Engineer A
    PE 2.2 Analyze interfaces to other systems and determine if the interfaced systems have the capacity to handle solution’s computing requirements during peak periods. Interfaces to other systems are reviewed and analyzed; agreed upon information is understood and documented; and documents are maintained using the project’s Version Control procedures. Performance Engineer A
    PE 2.3 Assist project team with deriving capacity and performance system requirements from customer requirements. Contribute to developing capacity and performance system requirements and document agreed upon requirements. Agreed upon requirements are maintained using the project’s Version Control procedures. Performance Engineer A
    PE 2.4 Develop initial PEM based on workload characteristics (including data object size and peak volume), determining impact on IT infrastructure components such as platforms, network, storage, and databases, if required. The PEM is used to help determine impacts on IRS IT infrastructure. Once the model is developed, agreed upon, and documented, it is then maintained using the project’s Version Control procedures. Performance Engineer R,A
    PE 2.5 Use analytical models, simulations, and/or measurement data (e.g., benchmarks, prototypes) as necessary to size the hardware needed for the test environments. The stakeholders understand and agree upon models, simulations, and measurement data used to determine the test environments. Performance Engineer R,A
    PE 2.6 Update PEM based on results of performance analysis, if required. Understand and agree upon the results of the performance analysis, then update PEM and maintained using the project’s Version Control procedures. Performance Engineer R,A
    PE 2.7 Assist in development of performance test plan. Complete and submit approved contributions to the performance test plan. Performance Engineer A
    PE 2.8 Ensure that the requirements are testable. Analyze test activities and events and make recommendations where appropriate. Performance Engineer A
    PE 2.9 Identify what metrics are to be measured, what data to collect, and how data will be analyzed. Provide a listing of metrics to be measured and the data to be collected and ensure stakeholders understand the process. Performance Engineer R,A
Logical Design Flow Diagram
  1. Figure 2.120.5-3

    This is an Image: 65262003.gif

    Please click here for the text description of the image.

PE 3.0: Physical Design

  1. Ensure the Logical Design is Transformed into a Physical Design – Exit Milestone 4a – Physical Design

Physical Design Activities
  1. ID Description Role RACI
    PE 3.1 Revise PEM, if required, to reflect logical design. Map architecture and components to logical design. Ensure stakeholders understand and agree upon the logical design, update PEM to reflect logical design, then map architecture and components to logical design, document results, and maintained using the project’s Version Control procedures. Performance Engineer R,A
    PE 3.2 Determine the impact on each component and which components are shared with other systems. Stakeholders on the impact of each component must reach a consensus. Performance Engineer A
    PE 3.3 Determine capacity and the ability to meet expected growth demands. Analyze available workload data. Identify peak periods and volumes. A consensus must be reached on capacity, its ability to meet expected growth demands, what workload data is available, and when the peak periods and volumes occur. Performance Engineer A
    PE 3.4 Decompose component level requirements for performance. Split up one performance component into smaller ones and allocate them to various performance functions, so that when each function performs its task, the entire component will be completed. This ensures that requirements are implemented correctly. Performance Engineer R,A
    PE 3.5 Use PEM, if required, to size Production hardware, providing justification for hardware purchases. The PEM will assist in evaluation and acceptance of hardware purchases. Performance Engineer R,A
    PE 3.6 Assist with updates to the performance test plan for test metrics, test data, test environment, test scripts, test procedures, load testing, and data to be collected. Contribute to updating the performance test components and make recommendations as required. Performance Engineer A
Physical Design Flow Diagram
  1. Figure 2.120.5-4

    This is an Image: 65262004.gif

    Please click here for the text description of the image.

PE 4.0: Implement the Physical Design

  1. Implement the Physical Design and Test and Deploy Application Software Components on the Host Platform – Exit Milestone 4b – Development and Test

Implement the Physical Design Activities
  1. ID Description Role RACI
    PE 4.1 Assist with performance testing in the TEST environment. Determine how a system performs in terms of responsiveness and stability under a particular workload. The system also performs to investigate, measure, validate, or verify other attributes of a system, such as scalability, reliability, and resource usage. Performance Engineer A
    PE 4.2 Perform load test on hardware. Conduct load test to understand the behavior of the system under a specific expected load. Performance Engineer A
    PE 4.3 Measure and collect data on response time; throughput; CPU utilization; memory utilization; disk I/O; bandwidth utilization. Metrics and criteria are used to determine what parts of the system or workload causes the system to perform well or perform poorly. Performance Engineer A
    PE 4.4 Verify PEM, if required, with TEST environment results. Ensure PEM, if required, is a realistic model based on Test environment results. Performance Engineer R,A
    PE 4.5 Assist Project with performance testing during FIT environment testing. Conduct performance testing during the FIT environment test. Results are maintained using the project’s Version Control procedures. Performance Engineer A
    PE 4.6 Assess system performance and tune system for optimal performance. Analyze data and consolidate and share results. Make a tuning change and retest if required for system improvement. Results are maintained using the project’s Version Control procedures. Performance Engineer A
    PE 4.7 Verify that performance is acceptable. Ensure performance results meet customer performance requirements. Performance Engineer A
    PE 4.8 Verify that Service Level Agreements (SLAs) are satisfied. Ensure that respective IRS offices, organizations, and stakeholders agree upon SLAs. Performance Engineer A
    PE 4.9 Verify and update PEM with FIT results. Ensure FIT results meet expected project requirements and update PEM as required. Performance Engineer R,A
    PE 4.10 Finalize the PEM, including documentation. Final PEM and associated documentation are updated and results are maintained using the project’s Version Control procedures. Performance Engineer R,A
Implement the Physical Design Flow Diagram
  1. Figure 2.120.5-5

    This is an Image: 65262005.gif

    Please click here for the text description of the image.

PE 5.0: Operations and Maintenance

  1. Transition to Operations and Maintenance – Exit Milestone 5 – Operations and Maintenance

Operations and Maintenance Activities
  1. ID Description Role RACI
    PE 5.1 Assist with verifying that monitoring and data collection are configured properly on deployed solution. Ensure system is correctly configured, meets system requirements, and executes correctly in the production environment. Performance Engineer A
    PE 5.2 Assist with identifying performance problems. Ensure any performance problems in the production environment are identified, documented, and escalated for resolution if required. Performance Engineer A
    PE 5.3 Assist in performing root cause analysis to resolve performance issues. Performing a root cause analysis will help to resolve any performance issues in the production environment. Performance Engineer A
    PE 5.4 Assist in tuning system for optimal performance. Make a tuning change to the system if required for optimal performance. Retest if required for system improvement. Results are maintained using the project’s Version Control procedures. Performance Engineer A
Operations and Maintenance Flow Diagram
  1. Figure 2.120.5-6

    This is an Image: 65262006.gif

    Please click here for the text description of the image.

Exhibits

  1. Exhibits

Exhibit A: Acronyms

  1. Acronyms

    Acronym Definition
    ACIO Assistant Chief Information Officer
    BSR Business Service Report
    CMS Change Management System
    COH Computer Operator’s Handbook
    CTO Chief Technology Officer
    DSR Design Specification Report
    ELC Enterprise Life Cycle
    EOps Enterprise Operations
    EOTR End Of Test Report
    ES Enterprise Services
    ESM Enterprise Systems Management
    GEL Government Equipment List
    ICD Interface Control Document
    IPM Integrated Project Management
    IRS Internal Revenue Service
    IT Information Technology
    PAL Process Asset Library
    PD Process Description
    PE Performance Engineering
    PEM Performance Engineering Model
    PMP Project Management Plan
    RACI Responsible, Accountable, Consulted, and Informed
    ROI Return on Investment
    SE Solution Engineering
    STP System Test Plan

Exhibit B: Glossary

  1. Glossary

    Term Definition
    Artifact A work product created by a process or procedure step.
    Business System Report A report that provides an alternative to preparation of a separate BSCR, BSAR and BSRR for projects or releases where a single, integrated document will not introduce significant risk with regard to definition of system scope or architecture. The BSR documents the vision or concept, architecture and requirements analysis that form the basis for subsequent business solution design, development, integration, and testing
    Computer Operator Handbook The Computer Operator Handbook (COH) provides instructions to the system operator for the proper execution and validation of the technical architecture and the on–line processing specifications for Selection and Workload Classification of the solution. It does this by supplementing standard operational instructions with other information that may assist in the understanding and maintenance of Selection and Workload Classification.
    Design Specification Report The Design Specification Report (DSR) provides explicit information about the requirements for a system and how the system is to be put together.
    Final Integration Test The Final Integration Test (FIT) is a test conducted to determine if the performance requirements of a specification or solution are met.
    Performance Engineer Manages the various Performance Engineering activities that need to be conducted to support a project. Key responsibilities include: capturing and analyzing performance data to forecast potential capacity issues; assisting with identifying what metrics to capture; adding to or scaling up to meet capacity and performance objectives; ensuring satisfactory accomplishment of all performance engineering activities; defining resource consumption relationships in terms of functional workloads for the information technology (IT) infrastructure; developing test cases; ensuring performance tests are administered; collecting and analyzing data; ensuring performance issues are identified and addressed; and, generating testing reports.
    Performance Engineering Performance Engineering is a collection of techniques and methodologies that provides reliable prediction, measurement, and validation of the performance of applications on a variety of computing platforms at the IRS. It encompasses the set of roles, activities, best practices, tools, and deliverables applied at every phase of the Enterprise Life Cycle which ensures that a solution will be designed, implemented, and operationally supported to meet the non–functional performance requirements defined for the solution. Performance Engineering is the subset of Systems Engineering which aims to ensure that a project's system solution enables the project to comply with the specified performance and operational requirements without incurring unanticipated cost or delay.
    Performance Engineering Model A Performance Engineering Model provides objective or subjective results used as input into the Enterprise Life Cycle.
    Performance Test Plan The Performance Test Plan covers a wide range of engineering or functional evaluations where a material, product, or system is not specified by detailed material or component specifications rather, emphasis is on the final measurable performance characteristics. Testing can be a qualitative or quantitative process.
    RACI The RACI model is based on the principle that people act in one of four ways when executing a task. It accounts for the fact that more than one role may be active in performing a specific task while clearly defining specific responsibilities for that role. While many roles may be involved in a task only one is Accountable for the results. The actions are: R Responsible for the action (may do the task) A Accountable for the action (including approval) C Required to be Consulted on the action I Required to be Informed of the action If a task does not have an Accountable role indicated then the Responsible role is assumed to be accountable for the task.
    Tool Job aid for a specific purpose, e.g., Checklist, template, application.
    Unified Work Request A Unified Work Request (UWR) is a request for MITS services, which results in new or modified requirements for a business solution.