tag:blogger.com,1999:blog-76015769758662086972024-02-08T07:17:32.736-08:00Defining Requirements - Service V Model approach using ITILVJ Reddyhttp://www.blogger.com/profile/13243896358482876742noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-7601576975866208697.post-29655865404027869122015-02-01T07:54:00.004-08:002015-02-01T07:54:59.212-08:00<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
<span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Service V Model is a concept that is raised in the Service Transition volume of the new ITIL 2011 guidance and publication. The Service V Model is a unique concept that provides a path to follow with regard to defining the requirements for a service package, designing the package, building and then testing the package. The model provides baseline points along the path that are used a checkpoints to ensure that what is being designed, built and delivered is actually what was required. Each step on the path also has specifically named outputs that should be visible.</span></span></div>
<div style="text-align: justify;">
<span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;"><br />The V-model approach is traditionally associated with the waterfall lifecycle, but is, in fact, just as applicable to other lifecycles, including iterative lifecycles, such as prototyping, RAD approaches. Within each cycle of the iterative development, the V-model concepts of establishing acceptance requirements against the requirements and design can apply, with each iterative design being considered for the degree of integrity and competence that would justify release to the customer for trial and assessment. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of<br />testing. During each phase of software development thought is already given to the corresponding tests. For instance, during the definition of the Service Requirements, the corresponding Acceptance tests are already written and signed off.</span></span></div>
<div style="text-align: justify;">
<span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;"><br />The advantage of the V-model is that by writing the tests at the time of specification errors in the specifications can be detected in an earlier phase, avoiding costly reworks later on. Additionally, testing happens at different levels, first component testing, then package testing, system testing etc. again leading to early detection of errors.</span></span></div>
<div style="text-align: justify;">
<span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;"><br /></span></span></div>
<div style="text-align: justify;">
<span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Using techniques such as the Service V model for Service Validation and Testing provides a framework to help organize the levels of Configuration Items that are needed and the associated testing and validation activities within and across stages of the change. The Service V Model is a concept of establishing acceptance requirements against the various levels of requirements that apply in order to justify release to the customer for trial and assessment. The left hand side represents the specification of the service requirements down to the detailed Service Design. The right hand side focuses on the validation and test activities that are performed against the specifications defined on the left hand side, and there is direct involvement by the equivalent party on the right hand side. It shows that service validation and acceptance test planning should start with the definition of the high level requirements. It also describes that the person/group or sign off on the requirements on the left side should be involved on the right side to accept that the requirements have been met. The actual tests required at each level should reflect the approach to risk and level of confidence that is required for the service change being transitioned. There are many frameworks and sources of guidance focused specifically on testing e.g. Test Management Approach (TMAP) that provide more details about the specific types of testing activities that can be performed. These normally include:</span></span></div>
<ul style="text-align: left;">
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Usability testing</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Accessibility testing</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Process and procedure testing</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Knowledge transfer and capability testing</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Performance, capacity and resilience testing</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Volume, stress, load and scalability testing</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Availability, backup and recovery testing</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Security testing</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Logistics, deployment and migration testing</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Build, packaging and distribution testing</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Operability and maintainability testing.</span></span></li>
</ul>
<div style="text-align: justify;">
<span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;"><i><b>Test Strategy</b></i></span></span></div>
<div style="text-align: justify;">
<span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;"><br />A test strategy describes the overall approach to organizing testing and validation, including the allocation of the enabling resources required. It may apply to the whole organization, a set of services or a single service. The typical contents of a test strategy document include:</span></span></div>
<ul style="text-align: left;">
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">The purpose, goals and objectives of service testing and validation</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Scope and organizations</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Applicable standards, legal and regulatory requirements</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Service Management policies, processes and practices applicable to testing</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Test models used</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Test process activities (planning and estimation, documentation, control, execution etc)</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Test metrics</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Service Provider interfaces</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Test criteria</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Roles and responsibilities</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Environment requirements</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Deliverables</span></span></li>
</ul>
<div style="text-align: justify;">
<span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;"><i><b>Test Models</b></i></span></span></div>
<div style="text-align: justify;">
<span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;"><br />A test model describes a test plan, the scope of a test and the test scripts that define how each element will be tested. It ensures that testing is a repeatable process and that the defined deliverables are achieved. Test models should be structured so that:</span></span></div>
<ol style="text-align: left;">
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">There is traceability to the initial design requirements and criteria</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">All activities can be measured and audited</span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">That test elements can be reused or changed</span></span></li>
</ol>
<div style="text-align: justify;">
<span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">Service V Model is an excellent example of a test model used according to the different levels of testing and validation that apply.</span></span></div>
<div style="text-align: justify;">
<span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;"><br /><i><b>Why should one use Service V Model?</b></i> </span></span></div>
<ul style="text-align: justify;">
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">All of your very beautiful plans become ugly at some point. So you need reliable and proved standards to well manage the deployment of your applications or new and changed services. </span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">In order words, you can use the same standards again and again; it can be applied in the same way across different suppliers and/or clients you may have. It is easy to fit and explain to suppliers and clients. </span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">The Service V-Model helps to mitigate risks when implementing something new in your infrastructure. So you can have fewer issues caused by unpredictable risks. </span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">It helps the team to document the customer’s requirements in a standard format; it helps to understand what your customers really want; and it helps you in estimating and funding for your business case. </span></span></li>
<li><span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">The Service V-Model helps managing the customer’s expectations. If some of your clients requirements are changed after you have already started your design and build; you have tools to negotiate and tell your clients how long a ‘Test’ will take to place or how long it will be delayed.</span></span></li>
</ul>
<span style="font-size: x-small;"><span style="font-family: Verdana,sans-serif;">__________________________________________________________________________</span></span><br />
<br />
<div style="text-align: justify;">
<span style="font-size: xx-small;"><span style="font-family: Verdana,sans-serif;"><span>Author - <a href="http://www.iimtcs.in/lead-trainer-profile" target="_blank">Vijayakumar Reddy</a>, CTO & Lead Trainer, A2A IMTCS Pvt. LTD.</span></span></span></div>
<div style="text-align: left;">
<span style="font-size: xx-small;"><span style="font-family: Verdana,sans-serif;">
<span>
</span></span></span></div>
<div style="text-align: justify;">
<span style="font-size: xx-small;"><span style="font-family: Verdana,sans-serif;"><span><br /></span></span></span></div>
<div style="text-align: left;">
<span style="font-size: xx-small;"><span style="font-family: Verdana,sans-serif;">
<span>
</span></span></span></div>
<div style="text-align: justify;">
<span style="font-size: xx-small;"><span style="font-family: Verdana,sans-serif;"><span>
© Copyright 2014 A2A -
IMTCS. All rights reserved. <a href="http://www.iimtcs.in/" target="_blank">www.iimtcs.in</a>
</span></span></span>
</div>
<div style="text-align: left;">
<span style="font-size: xx-small;"><span style="font-family: Verdana,sans-serif;">
<span>
</span></span></span></div>
<div style="text-align: justify;">
<span style="font-size: xx-small;"><span style="font-family: Verdana,sans-serif;"><span>
The Swirl logo is a trade
mark of AXELOS Limited. </span></span></span></div>
<div style="text-align: left;">
<span style="font-size: xx-small;"><span style="font-family: Verdana,sans-serif;">
<span>
</span></span></span></div>
<div style="text-align: justify;">
<span style="font-size: xx-small;"><span style="font-family: Verdana,sans-serif;"><span><span style="color: white;"><span style="color: black;">ITIL® is a Registered
Trade Mark of AXELOS Limited. <a href="http://www.axelos.com/">www.axelos.com</a></span></span></span></span></span></div>
<ul style="text-align: justify;">
</ul>
</div>
VJ Reddyhttp://www.blogger.com/profile/13243896358482876742noreply@blogger.com0