White PapersToday, maintaining a competitive edge while managing costs is the challenge that most organisations face. High up on the IT Directors‟ to do list is innovation in the way costs are managed and contained, while at the same time providing a dynamic and responsive IT service to the business.
It has long been recognised that a major area for improvements to efficiency is how processes within the Software Development Lifecycle (SDLC) are managed. The challenge, however, is to make the SDLC more efficient while increasing the quality of the deliverables.
Based upon the industry standard Test Maturity Model integrated (TMMi), Experimentus undertook a survey across the IT Industry to understand the maturity of companies Software Quality Management processes.
85 Tottenham Court Road, London, W1T 4TQ T: +44 (0)870 770 6099 F: +44 (0)870 770 6067 E: info@experimentus.com www.experimentus.com Test Maturity Model integrated (TMMi) Survey results How Mature Are Companies Software Quality Management Processes In Today s Market? March 2009 Listen Challen e Understand Inter ret Create Untitled Document 2 Copyright 2009 Experimentus Ltd Table of Contents Executive Summary .......................................................................................................................... 3 Notable Results ............................................................................................................................. 3 Areas for concern .......................................................................................................................... 3 Conclusion ..................................................................................................................................... 3 Background ....................................................................................................................................... 4 About TMMi ................................................................................................................................... 4 The Survey .................................................................................................................................... 5 Overall rating ..................................................................................................................................... 6 Experimentus Overall Comment .................................................................................................... 7 The Practice areas of TMMi Level 2 in detail ..................................................................................... 8 Test Policy and Strategy ................................................................................................................ 8 Test Design and Execution ............................................................................................................ 9 Test Planning .............................................................................................................................. 10 Test Environments ....................................................................................................................... 11 Test Monitoring and Control ......................................................................................................... 12 Conclusion ...................................................................................................................................... 14 Summary comment:..................................................................................................................... 14 Appendix 1 ...................................................................................................................................... 15 Background to the TMMi Model and the TMMi Foundation .......................................................... 15 Copyright 2009 Experimentus Ltd. This document and any information therein are confidential and copyright property of Experimentus Ltd and without infringement neither the whole nor any extract may be disclosed, loaned, copied or used for manufacturing, provision of services or other purposes whatsoever without prior written consent. No liability is accepted for loss or damages from any cause whatsoever from the use of the document. Experimentus Ltd retain the right to alter the document at any time unless a written statement to the contrary has been appended. Untitled Document 3 Copyright 2009 Experimentus Ltd Executive Summary Today, maintaining a competitive edge while managing costs is the challenge that most organisations face. High up on the IT Directors to do list is innovation in the way costs are managed and contained, while at the same time providing a dynamic and responsive IT service to the business. Bearing Point and HP in their 2008 IT CEO survey identified that the strategy most likely to be deployed to reduce costs and time to market is to Improve IT process efficiency . It has long been recognised that a major area for improvements to efficiency is how processes within the Software Development Lifecycle (SDLC) are managed. The challenge, however, is to make the SDLC more efficient while increasing the quality of the deliverables. Based upon the industry standard Test Maturity Model integrated (TMMi), Experimentus undertook a survey across the IT Industry to understand the maturity of companies Software Quality Management processes. Of the 100 plus companies, across 12 industry sectors who responded: 72.5% were at TMMi Level 1 heading for Level 2; meaning they are working in a chaotic, hero based way but starting to build project based processes. 27.5% were at TMMi Level 2 heading towards Level 3; meaning they have some established project based process and are moving towards implementing process at an organisational level. None of the respondents reached Level 3. Notable Results Interestingly, the Level 2 results suggest that although software testers believe they are good at designing tests and planning testing, they are not so good at setting goals, monitoring and managing the plans. They are also not very consistent with how they estimate for testing either. The big surprise was to see how well planned test environments were, and that for the later stages of testing (e.g. User Acceptance Testing), production like test environments appear to exist fairly consistently. Areas for concern The most consistent weakness was around the collection and use of metrics, with a significant amount of respondents working without metrics altogether and therefore unable to say with any degree of confidence where they are or what they have done. With over 100,000 qualified people through recognised examination boards, it is hard not to conclude that, despite being armed with the tools and knowledge to make an impact to the quality and cost of software delivery, no allowance is made to enable the skills learnt to be put into practice. With informed management, there is nothing stopping organisations benefitting from what the students have learnt through controlled management of change. After all, why invest in training and certification if they are then unable to put what they have learnt into practice. Conclusion The survey results reflect a view that Experimentus has had for a while, that too many organisations are prepared to continue to fund poor, long winded, unrepeatable and costly processes and yet won t seriously investigate making improvements that will bring about a significant increase in software quality together with considerable cost savings. The challenge is to make the SDLC more efficient while increasing the quality of the deliverables Untitled Document 4 Copyright 2009 Experimentus Ltd Background In mid 2008, the TMMi Foundation (www.tmmifoundation.org.uk) released Level 2 of 5 of the TMMi model, along with the requirements for organisations and individuals to have their assessment method for the TMMi Model reviewed and accredited. At the same time they also provided guidance on what is required to attain Accredited Assessor status. In September 2008, Experimentus became the first company to have an accredited assessment method, accredited Assessors and Lead Assessors in the UK. This release was a significant achievement for the TMMi Foundation, marking the beginning of an industry wide roadmap for implementing software quality management into application development. Their roots go back as far as 2004 when a small group of Quality Process Improvement enthusiasts from around Europe met for the first time and decided it would make sense to develop and support a single, non-commercial test improvement model. Since then, there has been a growing swell of supporters who acknowledge the positive difference the TMMi model has on the delivery of increased quality and reduced costs. After receiving their accreditation, Experimentus conducted a survey to understand the maturity of the Software Quality Processes across the IT industry. Over 100 respondents, from many different industries, completed the survey. This report details the results of the survey and provides an insight into the activities of the testing industry in a period when software testing is referred to as a profession. About TMMi In the same way as the CMMI (Capability Maturity Model) process model is split over 5 Levels, the following diagram depicts the 5 Levels of the TMMi model. Each maturity level of the model is made up of a series of components (see diagram below). At the top we have the Maturity Level which indicates an organisation, project or teams level of maturity. The Maturity Level is made up of a series of Process Areas, such as Testing Policy and Strategy. These are the process goals that need to be achieved to verify a Maturity Level has been reached. The TMMi Foundation, marked the beginning of an industry wide roadmap for implementing software quality management into application development Untitled Document 5 Copyright 2009 Experimentus Ltd Each Process Area contains Goals and Practices, which in turn provide the details required to implement the Process Area. So, for example, under the Testing Policy and Strategy Process Area there are the following Goals and supporting Practices: Goal - Establish a test policy Specific Practice 1.1 Define test goals Specific Practice 1.2 Define test policy Specific Practice 1.3 Distribute the test policy to stakeholders Each Process Area is looked at in terms not only of its existence but also its deployment and the effectiveness of that deployment. Please refer to Appendix 1 for more background to the TMMi model. The Survey The survey was designed to align major testing activities with Process Areas analysed in a TMMi assessment, with the purpose of providing a survey indicating the alignment of current testing practices to this industry standard. The survey took place during the last quarter of 2008 and closed in February 2009, with each respondent asked to review a series of statements and to answer the statement with one of following responses: Strongly agree that the process in question is in place and well established Slightly agree that the process in question existed but was not deployed successfully Slightly disagree that the process was in an embryonic stage Strongly disagree no process existed No opinion/Don t know For the purposes of this report, any person who answered with a No opinion/Don t know response has been removed from the graphs, so the total % will not always equal 100%. We would like to thank all of those who took the time to complete the survey and hope the report is useful in initially understanding how they compare to their peers. M a t u r i t yL e v e lP r o c e s sA r e a sc o n t a in sP r a c t i c e sc o n t a in sin d ic a t e sT e s t in g P r o c e s sc a p a b ilit yG o a lsa c h ie v e sI m p le m e n t a t io nd e s c r ib e sUntitled Document 6 Copyright 2009 Experimentus Ltd Overall rating The chart below shows the current maturity across all respondents. What does being in TMMi Level 1 mean? TMMi Level 1 reflects that there is little or no standardisation of process. The delivery of good testing and software quality management depends on people who know what they are doing (and they may all be doing something different and not able to understand each other s approach) and the classic hero culture of the 24 hour test team who are indispensible. The issues come when a system matter expert s knowledge is not accessible by others or they are no longer available. The impact to the business can be great, resulting not only in delays, but increased risks and costs, all of which have been well publicised. What does TMMi Level 2 mean? TMMi Level 2 reflects that for 27.5% of the surveyed respondents that they have some processes in place, in all of the five Process Areas that this level focuses on. These are: 1. Test Policy and Strategy 2. Test Design and Execution 3. Test Planning 4. Test Environments 5. Test Monitoring and Control The small percentage of people with Level 2 is surprising, considering the number of industry sectors in the survey who have mission critical applications. C u r r e n t M a t u r it y a c r o s s a ll r e s p o n d e n t sT M M i le v e l 17 2 .5 %T M M i le v e l 22 7 .5 %Untitled Document 7 Copyright 2009 Experimentus Ltd If we break the results down by industry we see that Financial Services and IT Support Services sectors had the most respondents, and the highest volume of Level 1 companies, whilst all Retail respondents were operating at Level 2. Experimentus Overall Comment In today s world of efficiency and competitive advantage, the ever increasing demand for reliability, performance and speed combined with better quality software delivery, demands that Level 1 is not sustainable for mission critical applications, without introducing major risks. We therefore need to be more efficient in how we manage software quality which subsequently affects costs and the ability to be flexible enough to meet the needs of the business. What is surprising is that Financial Services has Level 1 chaotic processes, and the Retail sector is all Level 2. We believe the significance of this shows the need in Retail to have quality and testing processes under control as any breakdown could be catastrophic. Whilst in Financial Services, breakdowns could be catastrophic, but there tends to be more of a mixture (in terms of numbers) in mission and non mission critical applications, and that appears to be reflected here. Untitled Document 8 Copyright 2009 Experimentus Ltd The Practice areas of TMMi Level 2 in detail Test Policy and Strategy This Process area looks at how well established the organisational view of Software testing is, specifically looking at the two key organisational test documents, Test Policy and Test Strategy and how they are deployed and understood. A test policy has been established and agreed by the stakeholders and is aligned to business quality policies. A Test Policy is the Executive sign-off that confirms the goals and objectives of testing within an organisation and ensures that the objectives of the testing area is aligned with the needs of the business and clearly understood and agreed by all. So if getting to market quickly is the business objective, then testing would be directed to enable speed to market. Matching test and business objectives makes sense in order to better serve the business Survey results explained: 25% of respondents are working in an environment which is governed by a Test Policy. Therefore 75% are working without any commitment from Executive Management that what they are doing is aligned to the needs of the business. Experimentus view: For any element of the Software Development Lifecycle it is key that Executive sponsorship for the Test Policy is obtained. It is surprising that 44% of respondents had a policy which was not successfully deployed. This demonstrates that perhaps, there needs to be better communication between test and the business. Effective policies sponsored by the business deliver efficiency and productivity savings. An organisation-wide or programme-wide test strategy has been established and deployed. The role of a Test Strategy is to define the detail of how testing will be implemented, either for an organisation, programme of work or project. At the organisational level it may be more of a framework of process and controls that projects can select from, dependant on risk and development approach. At the programme and project level it is used to specify how testing will be carried out, thus ensuring that at all levels of the organisation, a common, and more importantly, a reusable process is deployed. This ensures that each tester is able to work in a consistent repeatable manner, with any process improvements made being reflected throughout the targeted area. Survey Results explained: A third of respondents operate using an organisational or programme-wide test strategy. A significant amount (35%) of respondents indicated that they were starting the journey of developing an effective Test Strategy. St ro n g ly d is a g re eS lig h t ly d is a g re eS lig h t ly a g re eS t ro n g ly a g re e1 7 %1 3 %3 5 %3 3 %O r g a n is a tio n / p r o g r a m m e - w id e te s t s tr a t e g y h a s b e e n e s ta b lis h e d a n d d e p lo y e d Effective policies sponsored by the business deliver efficiency and productivity savings Untitled Document 9 Copyright 2009 Experimentus Ltd Experimentus view: With only a third of respondents operating with an effective Test Strategy, it begs the question, how effective is the testing, and what value is it really adding to the organisation? They are running tests, but are they focused on the objectives of the project, or just what the tester believes should be done? Working without a Test Strategy is like using a map in the dark, you might get to where you want to, but you will probably get lost on the way, take a lot longer and spend a lot more than you planned! These results are surprising as most testers will say they work to a strategy, but this doesn t seem to be qualified by the results, and for those who do, it is not clear where they get their focus, if they don t have any Test Policy. Test Design and Execution This Process area looks at the approach to the design of test, how well tests are executed against the software under test and how well defects are managed and tracked to a satisfactory solution. Test scripts are developed, documented and prioritised. Test scripts describe the tests that will be run to prove that the software under test meets its prioritising and documenting these scripts ensures that the risks of release are lower, while the quality of the delivery is high. Result: The results here reflect the view that most organisations (52%) do have a process for test design and execution. However a lot of these companies don t have a Test Policy or Test Strategy so this could indicate that although the process of test design is well embedded, or at least exists, it may not be focused on organisational goals. This in turn may mean that all of these developed tests scripts may be incorrectly focused. Experimentus view: It is good to see that software testers do document and prioritise their tests. A well documented test script adds real value as it will be reusable, efficient in its use of data and provides a key input to the defect fix process (by specifically indicating what activity led to the defect being identified). Good test scripting saves a lot of time and effort across the project both in terms of defect resolution (if the developer has a clear picture of the actions taken that found the defect they can respond a lot quicker with a solution), and by reducing the delays created if someone else has to, but can t understand enough to rerun the test. A Test Approach based on identified risks, is established and agreed upon. The Test Approach sits below the Test Strategy in the test documentation hierarchy, or can form part of the Test Strategy, and confirms the detail of how testing will actually be implemented e.g. templates as well as process. This enables a tactical approach to dealing with risks. most organisations (52%) do have a process for test design and execution. However a lot of these companies don t have a Test Policy or Test Strategy Working without a Test Strategy is like using a map in the dark Untitled Document 10 Copyright 2009 Experimentus Ltd Result: It has been said that without risk there would be no testing, so it is good to see so many people (35%) ensuring that their Test Approach is predominately based upon risk. The responses we received would indicate that the majority of respondents worked in companies where the Test Approach is well defined and implemented, or well defined but not quite fully rolled out, with only a small percentage not using risk to define their test approach. Experimentus view: Testing based upon risk forms the basis of efficient testing, and whilst the benefits of risk based testing are understood, the ability to maximise the efficiencies is perhaps a subject for further investigation in a follow-on survey. We are pleased to see application risks being identified and used in the software quality process so predominantly. Incidents found during testing are reported using an incident classification scheme and managed using a documented procedure. Incident classification relates to the process by which the priority and severity of defects is defined. The incident process governs how defects progress from identification through to classification. This enables strategies to be developed to reduce the amount of incidents and therefore re-work costs and time. Result: The results reflect that Incident Management is the most mature process within the testing lifecycle. The Experimentus view: Incident Management is the most intuitive process within the Testing Lifecycle, so there is no surprise that the results reflect that it is the most widely implemented process. Test Planning This Process area looks at the processes of the Test Plan development including estimating. A Test Plan is established and maintained as the basis for managing testing and communication to stakeholders. A Test Plan is the document that defines what the day to day activity on a testing project is. To be useful it needs to be updated as the project programme changes. It plays a large part in ensuring that testing starts and completes on time and that risks and any delays are identified early. Result: Over 54% of respondents were working to a plan, and at the same time keeping it up to date. Incident Management is the most intuitive process within the Testing Lifecycle Untitled Document 11 Copyright 2009 Experimentus Ltd The Experimentus view: For any test project to be successful it needs a good strong plan that matures with the project. It is good to see that in the majority of cases this occurs. What is worrying is that there is a significant volume of projects working without a plan, which would suggest that they have no clear view of what they are doing on a daily basis nor when they would finish! This adds significant risk to a project and may suggest why a lot of test projects fail to deliver. An approach to test estimation based on a repeatable process and/or historical data is in place. A mature organisation bases its estimation on the time, people and environments required to deliver the test project on a common repeatable process. This ensures that as actual post release data becomes known, the estimating data can be refined to provide more and more accurate estimates in the future. Result: Less than 17% use a repeatable estimating process, with over 30% not using a process at all. The Experimentus view: These responses would indicate that as an industry, Testing is very good at building a plan, but its basis (the estimating) is somewhat suspect and not repeatable. Most software testers that we meet complain that they never have enough time, and most Project Managers suggest too much time is given to testing. With a mature and repeatable estimating process the data will speak for itself and should resolve both of these issues. Test Environments This Process area looks at how well planned and implemented test environments are. Test environments are specified early and their availability is ensured on time in projects. Understanding the test environment requirements early enough in sufficient detail, enables costs to be built in early to a project plan, thus providing early visibility to the business. The details of any new environments should be provided by the technical architects with the test team deciding when it is needed and how it is to be delivered (phased or all together). Over time, this will ensure efficiency and accuracy of test environments with associated costs which have been planned for. Result: 40% of respondents get their test environments specified and delivered on time. The remaining 60% suffer from delays in delivery which from experience can be as much as 25% of the timescales. The Experimentus view: Test Environments is an area often blamed for a lot of delays in testing due to poor construction or generally not getting what is requested; however the responses don t seem to bear this out. This is excellent news as it shows real progress in this area from a few years ago when hundreds of thousands of hours were being lost waiting for a What is worrying is that there is a significant volume of projects working without a plan today thousands of man hours and pounds ( s) are wasted awaiting the right environment With a mature and repeatable estimating process the data will speak for itself Untitled Document 12 Copyright 2009 Experimentus Ltd fully working Test Environment. However, 40% is still low and means that today thousands of man hours and pounds ( s) are wasted awaiting the right environment. With the system management tools available today, this is such a simple issue to resolve and without a solution, adds the greatest risk to a successful delivery and biggest opportunity to have wasted time than any other area documented in this report. For later test stages (e.g. system or acceptance testing), the test environment is as real life as possible. For the later stages in testing, to ensure that the software will work in production, it is critical that the test environment replicates the production environment as far as software/hardware and configuration is concerned. It may be smaller than a production environment in terms of data, but not too small so it won t react in the same way. Increased risks in deployment are mitigated by understanding the relationship between this and the live environment. Result: The responses imply that testers are using Production like environments in over 50% of the projects. The Experimentus view: It is good to see that real life environments do exist. When the environment is not Life like there is an above average risk that when projects migrate to a Production environment the software will work but will result in defects due to the hardware and software configuration. Industry statistics indicate that 50% of all Production errors are found in the first 24 hours of release, with a large percentage being due to poor control of the configuration (or the test configuration not matching the Production one). Not only is this costly to repair but impacts the service and therefore has many far reaching implications to the day to day business, such as loss of revenues or wasted time for the users whilst awaiting fixes. Test Monitoring and Control This Process area is focussed on the collection and use of metrics to report progress and identify possible improvements to the process. A set of goal oriented test process performance indicators have been established and deployed. For testing to measure whether it is effective or not, it needs to set itself some performance indicators such as achieving a certain level of DDP (Defect Detection Percentage). You cannot manage what you don t measure. Result: Less than 30% of respondents had any defined goals. With the majority of respondents having no goals or measures regarding performance in place. St ro n g ly d is a g re eS lig h t ly d is a g re eS lig h t ly a g re eS t ro n g ly a g re e2 5 %1 7 %2 5 %2 9 %P e r fo r m a n c e in d ic a t o r s h a v e b e e n e s t a b lis h e d a n d d e p lo y e dLess than 30% of respondents had any goals defined. With the majority of respondents having no goals or measures regarding performance in place Untitled Document 13 Copyright 2009 Experimentus Ltd The Experimentus view: In our opinion, this is the worst result of the entire survey. It should be frightening for management to know that no goals have been defined for the 70% of the testers surveyed. This begs the comment that if testing wants to be considered as a profession, then the value testing adds needs to be clearly demonstrated to the business, through the use of performance indicators and goals achieved. Metrics are key, not only for management, but to ensure that testing, through the information provided and acted upon can provide a recognised valuable contribution to the business. Progress of testing is monitored against the Test Plan. We saw in Test Planning that it is important to keep the plan up to date. It is equally important to measure actual activity against planned activity. Any slippage can then be identified and managed before it creates any real issues. Result: 42% confirming that they do track actual against the plan, leaving 58% not quite knowing how well they are doing and whether they will deliver on time or not. The Experimentus view: Both of these results possibly reflect the black art view of testing measurement and metrics that most people have. However, if testers ever wish to be taken seriously, good metrics will be the thing that gets a test team noticed, in the same way that bad metrics get a test team ignored. Testing is about information provision; it has to provide accurate information to enable the stakeholders to make informed decisions. If Software Testers do not keep metrics as reflected above in a large percentage of cases confidence in their view of production readiness will be low as it will be completely subjective. Sometimes they will be lucky and software will work, but on other occasions when the Test organisation has said testing is complete, or is unable to show what is left to complete and so agrees to go live with no knowledge of the impact, the value add of spending up to 50% of the project costs on testing is lost when the product fails in Production. We saw with Heathrow Terminal 5 how decisions to cut back on testing were not validated with an understanding of the impact. Willie Walsh took the blame for this action, but in reality shouldn t the test team have been able to show beforehand how bad a decision the one he took was? Testing has to get a lot better at monitoring, controlling and reporting on what it does. St ro n g ly d is a g re eS lig h t ly d is a g re eS lig h t ly a g re eS t ro n g ly a g re e8 %1 3 %3 5 %4 2 %P r o g r e s s o f t e s t in g is m o n it o r e d a g a in s t t h e T e s t P la n Testing is about information provision; it has to provide accurate information to enable the stakeholders to make informed decisions Untitled Document 14 Copyright 2009 Experimentus Ltd Conclusion At a time when Software Testing wants to be seen as a profession and Software Testers want to be seen as valued members of their delivery teams, the results of this survey have highlighted two areas for serious consideration by test teams and their management. The first is around trust - given that over 100,000 people have qualifications gained through ISEB (Information Systems Examinations Board), and ISTQB (International Software Testing Qualifications Board), with the syllabi matching closely to the TMMi Foundations standards and methods, why is it that we appear unable to have some of the basics in place within the testing areas. What is stopping these basic practices from being implemented? Maybe focus is needed in ensuring the information learnt on courses is retained and practiced in the workplace through a controlled management of change. After all, why send them to be accredited if they cannot put into practice, best practice? The second is around demonstrating that Testing is a profession. In most professional disciplines, people are judged by their results and achievements. The survey indicated that more than 70% or respondents do not have metrics in place to monitor or manage testing goals. Metrics provide a valuable demonstration of results and achievements, which will help in raising their standing amongst their peers. If testing is serious about becoming a profession, it needs to get to grips with metrics to demonstrate its worth. Some interesting results were also revealed: it s the higher level tasks such as Test Policy, Test Strategy and the management and reporting of testing that Software Testers are not so good at. Maybe this is a direct result of software testers not getting the right training in management skills. A lot of the test managers we have met have had little or no formal training, in test or project management. The impacts of poorly managed projects are wide ranging, one example that comes to mind is the project that has been reporting good progress for 6 months, and the day before live suddenly says it is only 50% through testing. This actually happened on a project we were reviewing, the result was a 3 month delay to the go live date with major repercussions for the Project and Test Management team and additional cost of over 200k, as well as significant delays on projects that resources were due to move on to. This kind of situation is easy to fix with a little training and mentoring. There are some bright lights shining in there around test design; however, the key issue that this survey highlights is our lack of focus on goals, objectives and metrics. Resolving these areas will make a significant difference to the benefits Software Testers and Software testing provide to their organisations. Summary comment: The survey results reflect a view that Experimentus has had for a while, that too many organisations are prepared to continue to fund poor, long winded, not repeatable, costly processes but will not seriously investigate making improvements that will bring about a significant increase in software quality together with considerable cost savings. Metrics provide a valuable demonstration of results and achievements, which will help in raising their standing amongst their peers Untitled Document 15 Copyright 2009 Experimentus Ltd Appendix 1 Background to the TMMi Model and the TMMi Foundation The Test Maturity Model (TMMi) integrated has been developed to complement the existing CMMI (Capability Maturity Model) framework and to specifically deal in detail with software quality. It provides a structured presentation of maturity levels, allowing for standard TMMi assessments and certification, enabling a consistent deployment of the standards and the collection of industry metrics. TMMi has a rapidly growing uptake across Europe, Asia and the USA and owes its popularity to being the only independent test process measurement method. The independent TMMi Foundation initiative (www.tmmifoundation.org) has been established with the sole intent of developing the TMMi standard. The TMMi Foundation provides: A standard staged TMMi model that can be used in isolation or in support of other process improvement models. TMMi Assessment Method Application Requirements (TAMAR) for TMMi in accordance with ISO15504 and the process to certify commercial assessment methods against the standard model. Certification and training/examination process, procedures and standards for formal, public accreditation of Assessors and Lead Assessors and the on-going management. An independently managed data repository to support TMMi assessment method accreditation, assessor and assessment certification/validation and validated assessment data and certificates. Untitled Document 16 Copyright 2009 Experimentus Ltd LISTEN We actively listen to our clients enterprise computing issues and challenges, giving careful consideration to their individual requirements. CHALLENGE Focussed on consistently improving operational efficiencies and providing confidence to make risk-management decisions, we pioneer new ways to challenge our clients thinking. UNDERSTAND Our proven expertise and broad understanding is based on over 25 years of consultancy, analysis and testing of large enterprise applications. INTERPRET Our unique analytical approach and commitment ensures that our clients requirements are translated into first class deliverables with measurable results and productivity gains. CREATE We create superior quality solutions that deliver not only innovation, but help our clients to reduce cost, mitigate risk and enhance revenue. Experimentus Ltd 85 Tottenham Court Road London W1T 4TQ T:+44 (0)870 770 6099 info@experimentus.com www.experimentus.com
