ASPE Software Testing and ITIL Training Program Proposal Prepared For:

ASPE Software Testing and ITIL Training Program 

Proposal Prepared For: 

Contact

Information

Jan Allred, IT Service Manager 

200 Taylor Street Fourth Floor 

Fort Worth, TX 76102‐7308  [email protected]  Ph: 817‐884‐2259 

Business

Information

114 Edinburgh South Drive, Ste 200 

Cary, NC 27511 

919‐816‐1750   

Texas DIR (CMBL) Vendor Name: ASPE Technology 

Texas DIR (CMBL) Vendor Number: 1680517025100   

Tarrant County Vendor Name: ASPE Technology 

Tarrant County Vendor Number:  0007009063   

DUNS: 12‐672‐0759 

EIN: 68‐0517025 

GSA: GS‐35F‐0571Y   

ASPE,

Inc.

POC

Alysia Barnes 

National Account Manager 

919‐816‐1721 (Direct Line)  [email protected]  www.aspe‐sdlc.com     

Introduction to ASPE, Inc.  ASPE‐SDLC is a training firm committed to providing you with the best skills, tools, and techniques to successfully  transform complex business challenges into strategic systems capabilities. We provide real‐world, unbiased, pragmatic  training and consulting on all aspects of the software development life cycle. Our catalog includes courses in Agile  Software Development, Project Management, Business Requirements & Analysis, and Software Testing.     Our courses incorporate real, hands‐on experience from real professionals in all of our training courses in order to  maximize the amount of knowledge and skills you acquire. Too often, students leave a course learning information, but  not being able to apply it to real‐world situations. Our goal is for you to be able to actualize the skills and tools you learn  in the course and having no doubt that you can apply them within your organization on a daily basis.    Training Experience  Each year ASPE trains more than 20,000 people across the globe in public classroom, live online, or onsite course  sessions. ASPE is based in Cary, NC, but our customers have the flexibility to decide where, when and how they want to  train. Not only do we have more than 2,000 sessions scheduled across 80 North American cities annually, ASPE provides  international onsite delivery, as well as live, instructor‐led online options for those who can’t make it to a scheduled  classroom session. It is no wonder with all the opportunities ASPE provides that 91 of the Fortune 100 companies have  trained with us.    Industry Recognitions 

ASPE Inc. is the only business to business trainer to be recognized by the IIBA as a Charter Endorsed Education 

Provider (EEP); the 9th organization endorsed, PMI as an REP (Registered Education Provider) since 2004 and a 

Scrum Alliance REP (Registered Education Provider); the 2nd organization endorsed.  This is a testimony to our 

quality and consistency as a provider of Software Development Lifecycle training.             Software Testing Curriculum    Beginner Level 

Fundamentals of Software Testing (14 PMI PDUs) ‐ This two day software testing training class provides an 

example‐driven introduction to the fundamentals of software testing. It's designed to look at both the low‐

level mechanics of software testing ‐ what testers do when they are at the keyboard as well as the high‐level 

aspects of testing process and context. After taking this course, students will be able to more easily identify 

and apply various test oracles, will have a number of tools for generating and structuring test ideas, should be 

comfortable interacting with a variety of applications and recording those interactions, and will have a better 

understanding of where their testing fits within the overall project context. 

Course Outline 

Section I. What to test and how to test it 

Testers follow the same basic process that scientists use, we follow the principles of experimentation and 

in your testing, you're making complex decisions about what to test and how to test it. Utilizing a combination 

of skills, tactics, practices and tools ‐ this section helps build a base that testers in any context (of any skill 

level) can apply to solve testing problems.    The basic test process  

 Modeling the testing space   Determining test coverage   Determining test oracles   Determining test procedures   Configuring the test system   Operating the test system   Observing the test system   Evaluating testing results   Reporting test results   The work products of a tester  

 Formal work products   Informal work products    Ephemeral work products    Quick Tests and Heuristics  

 Developing and applying heuristics   Software Attacks  

 Quick Tests    

Section II. Providing a context for testing  

While testers follow the same basic testing process, they do it in dramatically different project contexts. There 

are numerous approaches to how teams structure testing, what approaches they employ, and what tools they 

use. In the second section of the course, we look at different contexts where testers work and how those 

contexts change the testing that takes place. This is also where we tackle problems like test planning and 

management.  

 Approaches to Testing   Scripted testing  

 Scenarios, Checklists, Charters   Exploratory testing  

 Common Phases of Testing   Unit Testing 

 Integration Testing    System Testing    Regression Testing   Acceptance Testing    Alpha / Beta Testing  

 The V‐Model for software testing   Agile testing directions  

 Non‐Functional Testing 

 Usability and Accessibility 

 Security Testing  

 Internationalization and Localization   Maintainability and Supportability    Platform Specialization 

 Mobile and web 

 SOA 

 Package implementations (configuration and customization)    Data warehouse and business intelligence  

 Telephony and hardware   Managing Testing Projects 

 Understand your context   Develop a test strategy   Estimating the work   Developing a schedule   Negotiating scope   Execution and reporting   Bug tracking  

Intermediate Level 

Planning Effective Software Testing (13 PMI PDUs) ‐ This two day software testing training course will teach 

you how to do a complete job of planning your test activities. It will walk you through the test planning 

process, identify all of the inputs you will need and the things you should produce. It will give you guidance on 

how to plan for test case creation, defect tracking, status monitoring and progress reporting. This course will 

equip you with all the tools you need to create a test plan that will serve all your needs.   

Course Outline 

I. The Test Planning Process 

Test planning cannot be done in a vacuum. The test plan must integrate smoothly with all the other project 

plans and consider many variables, both within the testing group and throughout the rest of the organization.  

1. Understand how testing fits within the software development lifecycle 

2. Understand the role and use of a test plan 

3. See how the test plan relates to other plans (e.g. Project plan & Quality plan) 

4. List the inputs to test planning 

5. List the outputs from test planning 

6. Perform peer reviews of the test plan 

7. Obtain organizational commitment to the test plan 

8. Track progress against the test plan, report status and re‐plan   

II. Test Plan: Scope and Lifecycle 

What is and is not included in the testing activities can be the subject of many disagreements; therefore, the 

test plan must be explicit about the scope of the testing activities and the testing lifecycle.  

1. Identify the requirements against which the testing will be done 

2. Define the goals and objectives for testing 

4. Enumerate the phases and steps in the testing lifecycle 

5. Identify how the testing lifecycle integrates with the project lifecycle 

6. Define specific entry criteria ‐ how you know when testing can begin 

7. Define specific exit criteria ‐ how you know when testing is complete 

8. Identify testing services that will be purchased rather than done in‐house   

III. Test Plan: Traceability Matrix 

The only way to assure that the test plan covers all of the requirements and goals without unnecessary tests is 

to have a systematic way to map tests and test cases to those requirements and objectives. Including a 

traceability matrix with the test plan is the easiest way to satisfy this need.  

1. List every requirement and goal or objectives in one place 

2. List every test and test case in one place 

3. Map requirements to test cases 

4. Assure that every requirement has at least one test case 

5. Assure that every test case corresponds to at least one requirement 

6. Avoid overkill (or under emphasis) in testing 

7. Determine the impact of skipping test cases   

IV. Test Plan: Required Tests 

Before test cases can be identified, the system requirements and testing objectives must be used to compile a 

list of tests that will be required. This list of tests is the heart of the test plan.  

1. Identify tests for functional requirements 

2. Identify tests for performance requirements 

3. Identify tests for security and safety requirements 

4. Identify tests for usability, maintainability and other requirements 

5. Define objectives and success criteria for each test 

6. Document each test in the traceability matrix 

7. Use the traceability matrix to assure complete coverage   

V. Test Plan: Test Cases 

Actually writing test cases and preparing the related data consumes a significant amount of time. Therefore it 

is important to estimate and plan for these activities.  

1. Enumerate the test cases required to satisfy the objectives for each test 

2. Identify positive, negative, boundary and special test cases 

3. Define objectives and success criteria for each test case 

4. Document each test case in the traceability matrix 

5. Use the traceability matrix to assure complete coverage   

VI. Test Plan: Test Case Size Estimates 

In order to provide a basis for planning the effort, costs and other resources needed for testing, we must 

estimate the size of each test case and document this in the test plan. 

1. Test case description and instructions 

2. Input data and/or database records required by the test case 

4. Special resources required by the test case 

5. Execution time for the test case   

VII. Test Plan: Resources 

Resources to support testing go far beyond just the people who will do the testing. The test plan must account 

for all required resources.  

1. Identify the testing and test case development environment (e.g. hardware, operating systems, 

networks, software, databases) 

2. Specify any special systems (e.g. test automation, defect tracking) 

3. Enumerate knowledge and skills needed 

4. Plan for hiring, contracting and training   

VIII. Test Plan: Effort, Cost, Budget & Schedule 

Effort, cost, budget and schedule are usually the items we are asked to provide. But until all of the items in 

sections II through VII have been identified and estimated, we do not have the information we need to 

provide these things. These critical parts of the test plan can now be completed. 

1. Identify the activities required to produce and execute all of the test cases, track defects, retest and do 

all of the other tasks associated with the testing lifecycle 

2. Estimate the effort required based on the size estimates and identified activities 

3. Identify all costs (e.g. labor, equipment, software contracted work) 

4. Establish a schedule for all testing‐related activities 

5. Spread the costs across the schedule to produce a budget 

6. Validate budget and schedule against project constraints 

7. Resolve budget or schedule issues   

IX. Test Plan: Risks 

Testing activities have their own unique risks that may not be visible or pertinent to other stakeholders in the 

project. The testing group should engage in risk management to assure that those items are handled 

appropriately and included in the test plan. 

1. Brainstorm a testing‐related risk list 

2. Group and consolidate risks 

3. Quantify risk probability and impact 

4. Make risk tracking plans 

5. Make risk mitigation plans 

6. Make risk contingency plans   

X. Test Plan: Management, Tracking & Reporting 

The test plan must identify how the testing group will maintain control over the testing activities and assure 

that they are progressing as planned. It must also define how they will report status to other project 

stakeholders and take corrective actions when necessary.  

1. Identify measurements that will be used in tracking and managing the testing activities 

2. Determine how the data and reports that are generated by the testing process will be stored, managed 

3. Determine how often testing status will be checked and who will participate in status checking 

activities 

4. Identify triggers for corrective actions when the testing activities deviate from the plan 

5. Determine what must happen when the test plan must be updated 

6. Identify all individuals and groups that have a stake in the testing activities 

7. Determine how the stakeholders will be involved and kept informed about testing‐related activities   

Advanced Level 

Combination of Proactive User Acceptance & Risk Based Testing 

Proactive User Acceptance Testing – This one day intensive interactive seminar shows what users need to 

know to confidently make the best use of their time planning and conducting acceptance tests that catch 

more defects at the traditional tail‐end of development, while also contributing in appropriate ways to 

reducing the number of errors that get through the development process for them to catch in UAT. Exercises 

give practice using practical methods and techniques.    

Course Outline 

I. ROLE OF USER ACCEPTANCE TESTING   Why users may resist involvement   Making users confident about testing   Objectives, types, and scope of testing   Acceptance testing as user’s self‐defense   Why technical tests don’t catch all the errors   Essential elements of effective testing   CAT‐Scan Approach to find more errors   Proactive Testing Life Cycle model 

 Separate technical and acceptance test paths   Place of UAT in overall test structure 

 Making sure important tests are done first   Developer/tester/user test responsibilities   

II. DEFINING ACCEPTANCE CRITERIA 

 Defining acceptance test strategy up‐front Source and role of acceptance criteria   5 elements criteria should address 

 Functionality the user must demonstrate   How much, how often user must test   Determining system quality 

 Who should carry out acceptance tests   How acceptance tests should be performed   Added benefit, revealing requirements errors   

III. DESIGNING ACCEPTANCE TEST PLANS   Expanding the acceptance criteria   Allocating criteria to system design   Refining the design to catch oversights 

 Checklist of common problems to test   Equivalence classes and boundary values   Making quality factors (attributes) testable   Structural testing applicable to users   GUI features that always need to be tested   Defining requirements‐based tests 

 Constructing use cases 

 Cautions about use case pitfalls 

 One‐ and two‐column use case formats   Turning use cases into tests 

Consolidating tests into efficient test scripts   

IV. CARRYING OUT ACCEPTANCE TESTS   Differentiating test cases and test data   Traps that destroy value of acceptance tests   Warning about conversions 

 Documentation, training, Help tests   Configuration, installation, localization   Security, backup, recovery tests 

 Suitability of automating acceptance testing   Performance, stress, load testing 

 Issues on creating test conditions, data   Capturing results, determining correctness   User's defect tracking and metrics 

Risk Based Testing – While finding and fixing every defect before release is not a reasonable expectation, Risk‐

Based Testing (RBT) techniques helps teach how to find the worst defects and ensure that the most critical 

functionality is high quality. Testing is far more than finding defects so they can be fixed. Testing can be one of 

our most potent techniques for managing risk on software projects. In addition to being a great strategy for 

testing, this course gives a solid basis for ensuring that we have appropriate time and resources for testing, 

and for making a strong business case for more when additional allocations are called for.    

Course Outline  I. Understanding Risk 

We begin by leveling the playing field. We ensure that all class participants have an accurate understanding of 

risk and its constituent parts. This will be the foundation upon which we build the rest of the course. 

A. Definition of Risk 

B. Anatomy of a Risk 

C. Software Risks 

D. Testing and Software Risks 

Exercise: Understanding Software Risks – We will discuss several risks that are common in software and apply 

the concepts of this chapter to fully explore and understand them.   

There are four steps in fully implemented Risk‐Based Testing. In this overview, we will identify each step and 

discuss how they are related to each other. 

A. Step 1: Identify & Rank Software Risks 

B. Step 2: Risk‐Based Test Planning 

C. Step 3: Risk‐Based Test Design 

D. Step 4: Risk‐Based Test Management   

III. Step 1: Identify & Rank Software Risks 

Before we can use Risk as a driver for software testing, we must identify the software risks that are inherent to 

the project at hand. Then having identified them, we will determine their relative priorities. 

A. Identify Software Risks  

Exercise: Brainstorm Software Risks – For our Case Study project, we will brainstorm possible software risks 

using the techniques just discussed. For each risk, we will identify the vulnerability that may allow it, the 

trigger that may cause it, and the effect that it may have on the project or the users of the software product if 

it occurs. 

B. Evaluate Each Risk  

Exercise: Evaluate Each Risk – For each risk we just identified for our Case Study project, we will compute its 

priority by considering the probability that the vulnerability and trigger will coincide, and the severity of its 

impact if they do. 

C. Evaluate Each Test Suite  

Exercise: Evaluate Each Test Suite – For each Test Suite on our Case Study project, we will determine its 

importance in terms of Risk, and identify those test suites that should be split up to ensure appropriate 

testing.   

IV. Step 2: Risk‐Based Test Planning 

Risk‐Based Test Planning uses the risks inherent in the project as the basis for focusing testing effort and 

resources. Higher priority risks will receive more focus, while less risky parts of the product receive 

correspondingly less attention. 

A. Estimate Test Cases by Risk  

Exercise: Estimate Test Cases by Risk – For each Test Suite on our Case Study project, we will determine how 

many Test Cases must be executed to address the identified risks. 

B. Testing Resources Based on Risk 

C. Negotiate Testing Resources  

Exercise: Risk‐Based Testing Resources – For each Test Suite on our Case Study project, we will use the 

estimated number of Test Cases to produce ROM (Rough‐Order of Magnitude) estimates of effort (e.g. person‐

days) and calendar time to address the identified risks. We will also identify any special resources (people, 

equipment, etc) that are required. 

D. Risk‐Based Test Activity Planning  

Exercise: Risk‐Based Test Plan – We will use the principle of testing high‐risk items first and our ROMs (from 

the prior exercise) to prepare a Risk‐Based testing activity plan. Then we will compare that plan to the over‐all 

project schedule and identify points to be negotiated.   

Merely focusing appropriate effort on risky Test Suites does not go far enough. That time must be spent doing 

the right things. In this section, we will use our Risk analysis as the basis for designing the right Test Cases for 

each Test Suite. 

A. Traditional (Requirements‐Based) Test Design 

B. Designing Tests for Risks  

Exercise: Risks‐Based Test Design – For one of our riskier Test Suites, we will identify every Test Case that must 

be included to appropriately address all of the identified software risks. Then we will evaluate the entire Test 

Suite to ensure that it has indeed remained focused on the identified Software Risks.   

VI. Step 4: Risk‐Based Test Management 

Risks are moving targets. Planning our testing based on the risks that can be identified at the beginning of the 

project is an important first step. But that plan must stay focused on risks, even as those risks evolve. And the 

evolution of those software risks gives us important insights into the readiness of the software product for 

release. 

A. Risks Evolve 

B. Risk‐Based Testing Must Evolve 

C. Track Known Software Risks 

D. Brainstorm New Software Risks 

E. Adjust Risk‐Based Test Plans 

F. Rework Risk‐Based Test Designs 

G. Report of Software Risk Changes 

Exercise: Risk‐Based Test Management – We will use our initial risk assessment to compute the software 

product's Risk Index. (This Risk Index can be used to track the evolution of software risks throughout the 

project.)   

VII. Achieving Success with Risk‐Based Testing 

Gaining the biggest benefits of Risk‐Based Testing requires that testers not only embrace these principles in 

their own work, but also that they work with the rest of the software development organization to integrate 

risk‐based principles into the way software projects are conceived and managed. 

Discussion: Risk Based Testing – Each participant will identify the actions that need to be taken within their 

organization to take the greatest advantage of Risk‐Based Testing. 

Agile Testing ‐  The 2‐day program will introduce you to high speed methods, and explore their use so that you 

can immediately step from the classroom into the office with new found confidence. We will discuss 

transition, roles, methods and technologies that can be relied upon to deliver speed and optimum flexibility. 

You will start to feel a new sense of flexibility, confidence and enthusiasm (maybe for the first time in your 

entire development career).   Course Outline  I. Agile Testing  We will discuss the testing and it's role in software quality. Quality is the collective responsibility of the team from  business analyst to developer to tester to customer. Traditional waterfall "over‐the‐wall testing" can be inefficient and  frustrating. We will discuss typical challenges and pitfalls in this traditional approach and start to contrast how Agile  Teams test differently.  

 Poor Quality creates Drag 

 Integrating the Team into an Agile Testing mindset 

 Understand hard & soft constraints to adopting Agile Testing    Getting the Customer to participate in Quality decisions   

II. Testing Practices 

The benefits that various types of testing provide to the team will be reviewed. Additional discussion will focus on the  how and what to automate to shorten feedback cycles.   Testing Quadrants   Automation   Unit Tests   Integration Tests   Acceptance Tests   Functional Tests   

III. Quality Practices 

Understanding that getting feedback is as important as testing. We will discuss techniques that provide feedback on the  quality of software and the effectiveness of the process.    Pairing & Collaboration   Inspections   Reviews   Demos   

IV. Unit Testing & Test Driven Development (TDD)  

We will introduce Unit Testing and Test Driven Development. The benefits and process of TDD and how it can lead to  better overall design and simplicity and engage the Developer in the test processing will be discussed.   Unit Testing Principles   Test First vs. Test Last   Unit Testing Legacy Applications   TDD Rhythm: Red, Green, Refactor   TDD influence on Design   Supporting Continuous Refactoring     V. Continuous Integration  The concept of Continuous Integration and the CI Attitude will be discussed. Continuous Integration provides an  essential role in maintaining a continuous process for providing feedback to the team.   Discuss the Attitude of Continuous Integration    Benefits & Practices of Continuous Integration   Continuous Feedback    Continuous Builds   Continuous Inspections    Continuous Testing    Continuous Deployments    

VI. Acceptance Testing 

Acceptance Tests can provide an invaluable tool to support the creation higher quality software and continue to support  the team from story to story and sprint to sprint.   Acceptance Criteria   Writing Acceptance Tests   Acceptance Test Driven Development   Automating Acceptance Tests   Behavior Driven Development    

VII. Functional Testing Web Applications & Web Services  

As we develop a functioning application we can perform higher‐level and coarser grained functional tests. Functional  testing software, web applications and web services will be explored.    Functional Testing Applications    Testing Web Applications   Testing Web Services    

VIII. Hands‐on Critiquing the Product 

Everything can't be automated, nor should it. We will discuss manual technique that will help us critique the product  and provide valuable feedback. We will discuss when and how these testing techniques should be used effectively.   Exploratory Testing    Scenario Testing   Usability Testing   User Acceptance Testing    

IX. Using Tools to Test Complexity and Critique the Product  

Tools can be used to testing complex, critical attributes of the software. We will discuss when and tools should be used  to test the complex, critical qualities of software.   Performance & Load Testing    "ility" Testing   Security Testing    

X. High‐Speed Testing Techniques 

We'll introduce some techniques that can speed the testing process and provide faster feedback to the team and  customer.   Risk Based Testing    Pairwise Testing   Pareto Technique   

XI. Iterating to Testing Agility 

How do we ever get there? We will discuss pragmatic techniques to iterate your team and organization to Testing  Agility. We will discuss and craft a roadmap for your team and organization based off the practices and techniques  discussed.   Prioritize regularly    Realize Constraints   Challenge Constraints   Keep moving forward    Automate, Automate, Automate   Roadmap & Planning  

ITIL Training Courses   

Just as PMI has set the standards for Project Management around the world, ITIL is the most widely accepted 

approach to IT Service Management in the world. This three‐day course introduces the fundamentals of IT 

Service Management (ITSM) based on ITIL (2011) of the IT Infrastructure Library (ITIL). Originating in the UK, 

ITIL has been adopted for its proven ability to help IT departments cut costs and improve service. The purpose 

of the ITIL Foundation certificate is to understand ITIL terminology, structure, basic concepts and the core 

principles of IT Service Management best practices.   

Certified ‐ ITIL 2011 Foundations Training – 3 Day course which includes the exam which is administered on 

the third day of class. We guarantee a passing score. If you do not pass the ITIL certification exam on your first 

try within four weeks after your class has completed, we will provide you with a new exam voucher! If you fail 

the second time, you can attend another session free of charge!   

Course Outline 

I. Introduction to ITIL® and IT Service Management    History  

 ITIL Terms 

 The ITIL Service Lifecycle Model    Service Strategy Overview    Service Design Overview    Service Transition Overview    Service Operation Overview  

 Continual Service Improvement Overview    Service Life Cycle Key Links 

 Service Management Model 

Case Study: ITIL Life Cycle in the Case Study Organization   Exam Questions: ITIL & Service Management  

II. Continual Service Improvement  

 Purpose, Objectives, Scope and Value of Continual Service Improvement    ITIL Terms & Concepts 

 Service Management Functions    Service Desk  

 IT Operations Management    Technical Management   Application Management  

 Continual Service Improvement Key Concepts    The Deming Cycle 

 Continual Service Improvement Approach   Metrics 

 Continual Service Improvement Process  

Case Study: Apply Continual Service Improvement concepts to the Case Study Organization   Exam Questions: Continual Service Improvement  

III. Service Operation  

 Purpose, Objectives, Scope and Value of Service Operation   Processes 

 Incident Management  

 Purpose, Objectives, Scope, Basic Concepts    Incident Management Activities  

 Interfaces to other ITSM Processes   Problem Management Overview 

 Purpose, Objectives, Scope, Basic Concepts    Problem Management Activities  

 Interfaces to other ITSM Processes   Event Management Overview 

 Request Fulfillment Overview   Access Management Overview 

Case Study: Apply Service Operation concepts to the Case Study Organization   Exam Questions: Service Operation  

IV. Service Transition  

 Purpose, Objectives, Scope and Value of Service Transition   Processes  

 Transition Planning and Support Overview    Change Management  

 Purpose, Objectives, Scope, Basic Concepts    Change Management Key Activities  

 Interfaces to other ITSM Processes   Release and Deployment Management Overview   Service Asset and Configuration Management Overview   Knowledge Management Overview 

Case Study: Apply Service Transition concepts to the Case Study Organization   Exam Questions: Service Transition  

V. Service Design  

 Purpose, Objectives, Scope and Value of Service Design   Key Concepts  

 4 P's of Service Design    5 Service Design Aspects    Service Design Package    Processes  

 Design Coordination Overview  

 Service Catalog Management Overview   Service Level Management  

 Purpose, Objectives, Scope, Basic Concepts    Service Level Management Activities 

 Interfaces to other ITSM Processes   Supplier Management Overview 

 Capacity Management Overview   Availability Management Overview 

 IT Service Continuity Management Overview   Information Security Management Overview 

Case Study: Apply Service Design concepts to the Case Study Organization   Exam Questions: Service Design  

VI. Service Strategy  

 Purpose, Objectives, Scope and Value of Service Strategy   Processes  

 Service Portfolio Management Overview   Business Relationship Management Overview   Financial Management for IT Services Overview 

Case Study: Apply Service Strategy concepts to the Case Study Organization   Exam Questions: Service Strategy  

VII. Wrap‐Up and Review 

 The ITIL Service Lifecycle Model Review   Service Strategy Review  

 Service Design Review   Service Transition Review   Service Operation Review 

 Continual Service Improvement Review   

VIII. Course Recap 

 Mock Exam Prep 

 Mock Exam 

 Mock Exam Score 

 Exam Prep 

 Exam 

Non‐Certified ‐ ITIL 2011 Foundations Training – 2 Day course without exam   

Course Outline 

I. Introduction to ITIL® and IT Service Management    History  

 ITIL Terms 

 The ITIL Service Lifecycle Model    Service Strategy Overview    Service Design Overview  

 Service Transition Overview    Service Operation Overview  

 Continual Service Improvement Overview    Service Life Cycle Key Links 

 Service Management Model 

Case Study: ITIL Life Cycle in the Case Study Organization   Exam Questions: ITIL & Service Management  

II. Continual Service Improvement  

 Purpose, Objectives, Scope and Value of Continual Service Improvement    ITIL Terms & Concepts 

 Service Management Functions    Service Desk  

 IT Operations Management    Technical Management   Application Management  

 Continual Service Improvement Key Concepts    The Deming Cycle 

 Continual Service Improvement Approach   Metrics 

 Continual Service Improvement Process  

 The Seven‐Step Improvement Process Overview 

Case Study: Apply Continual Service Improvement concepts to the Case Study Organization   Exam Questions: Continual Service Improvement  

III. Service Operation  

 Purpose, Objectives, Scope and Value of Service Operation   Processes 

 Incident Management  

 Purpose, Objectives, Scope, Basic Concepts    Incident Management Activities  

 Interfaces to other ITSM Processes   Problem Management Overview 

 Purpose, Objectives, Scope, Basic Concepts    Problem Management Activities  

 Interfaces to other ITSM Processes   Event Management Overview 

 Request Fulfillment Overview   Access Management Overview 

Case Study: Apply Service Operation concepts to the Case Study Organization   Exam Questions: Service Operation  

IV. Service Transition  

 Processes  

 Transition Planning and Support Overview    Change Management  

 Purpose, Objectives, Scope, Basic Concepts    Change Management Key Activities  

 Interfaces to other ITSM Processes   Release and Deployment Management Overview   Service Asset and Configuration Management Overview   Knowledge Management Overview 

Case Study: Apply Service Transition concepts to the Case Study Organization   Exam Questions: Service Transition  

V. Service Design  

 Purpose, Objectives, Scope and Value of Service Design   Key Concepts  

 4 P's of Service Design    5 Service Design Aspects    Service Design Package    Processes  

 Design Coordination Overview  

 Service Catalog Management Overview   Service Level Management  

 Purpose, Objectives, Scope, Basic Concepts    Service Level Management Activities 

 Interfaces to other ITSM Processes   Supplier Management Overview 

 Capacity Management Overview   Availability Management Overview 

 IT Service Continuity Management Overview   Information Security Management Overview 

Case Study: Apply Service Design concepts to the Case Study Organization   Exam Questions: Service Design  

VI. Service Strategy  

 Purpose, Objectives, Scope and Value of Service Strategy   Processes  

 Service Portfolio Management Overview   Business Relationship Management Overview   Financial Management for IT Services Overview 

Case Study: Apply Service Strategy concepts to the Case Study Organization   Exam Questions: Service Strategy  

VII. Wrap‐Up and Review 

 Service Strategy Review    Service Design Review   Service Transition Review   Service Operation Review 

 Continual Service Improvement Review   

Pricing – Rates below includes all costs (instructor fee, travel & accommodations, course materials, etc).  This is an All‐ Inclusive flat rate.  Availability – We have instructors available for training beginning Monday, January 14, 2013 and  ending, August 31, 2013.  Please review attached instructor bios. 

Cost of Individual Courses   

Course  Training 

Days 

Price for up to 20  students 

Fundamentals of Software Testing  2  $8,750  

Planning Effective Software Testing   2  $8,750  

Combination of Proactive User

Acceptance Testing & Risk Based Testing  2  $8,750  

Agile Testing  2  $8,750 

Certified ‐ ITIL 2011 Foundations Training  3  $14,250  

Non‐Certified ‐ ITIL 2011 Foundations 

Training 

2  $9,750    

Additional 15% Discount:  For any (two) 2‐day sessions held back‐to‐back during the same week, ASPE will offer an 

additional 15% off the total rate.  For example: Fundamentals of Software Testing – First Session: Jan 28‐29: $8750 /  Second Session: Jan 30‐31: $8750. Total = $17500 – 15% discount = $14875. 

Estimated Project Total  

(without additional discount computed)   

Course  Based on # 

of Sessions 

Projected # of 

Students  Estimated Total 

Fundamentals of Software Testing  3‐4  60‐80 ppl  $26,250 ‐ $35,000 

Planning Effective Software Testing   3‐4  60‐80 ppl  $26,250 ‐$35,000 

Combination of Proactive User

Acceptance Testing & Risk Based Testing  3  60 ppl  $26,250 

Agile Testing  2  40 ppl  $17,500 

Non‐Certified ‐ ITIL 2011 Foundations 

Training OR Certified ‐ ITIL 2011 

Foundations Training 

3  60 ppl   $29,250 OR $42,750           $125,500 ‐ $156,500   

ASPE will present the course at the training facilities of the client.  As part of this agreement, ASPE will provide the  following services:  1. Qualified and experienced instructor  2. Course workbooks for each student   3. Course evaluation forms via Metrics That Matter online evaluation tool  4. All course related shipping and handling expenses   5. A course completion certificate with 7 PMI PDU’s per day 

6. A 100% pass guarantee ‐ We guarantee a passing score. If you do not pass the ITIL certification exam on your  first try within four weeks after your class has completed, we will provide you with a new exam voucher! If you  fail the second time, you can attend another session free of charge!

We ask that the client will provide:   A classroom learning environment    Refreshments for the attendees if desired   A projector, flip chart and white board   Clear directions to your classroom facility   A list of the attendee’s names, with titles, email addresses and mail addresses ten (10) days prior to the start of  the course   

Thank you for the opportunity to quote on this training.   

Alysia Barnes 

National Account Manager 

ASPE, Inc. 

919‐816‐1721 (Direct Line) 

919‐816‐1710 (Fax)