XML Is the Here, the Now, and the Future

XML Is the Here, the Now, and the Future

XML is short for Extensible Markup Language, which is a specification developed by the World Wide Web Consortium (W3C). XML is a pared-down version of SGML, designed especially for Web documents. It allows designers to create their own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications and between organizations.

Following are three good reasons why you should master XML:

  • XML is seen as a universal, open, readable representation for software integration and data exchange. IBM, Microsoft, Oracle, and Sun have built XML into database authoring.
  • .NET and J2EE (Java 2 Platform, Enterprise Edition) depend heavily on XML.
    • All ASP.NET configuration files are based on XML.
    • XML provides serialization or deserialization, sending objects across a network in an understandable format.
    • XML offers SOAP Web Services communication.
    • XML offers temporary data storage.
  • MSBuild and the future project files of Visual Studio will be in XML format. ANT is also XML based.

Thus, if you want to learn one language that will cover many tools and technologies no matter what platform you are working on, that language is XML. The main difference in all these build tools is not so much the feature set but the syntax. I get tired of learning all the quirks of new languages, but I’m happy to learn XML because it’s here to stay and it’s fairly easy to learn.

Tagged : / / / / /

Some new terms of TFSC

  • Repository— The data store containing all files and folders in the TFSC database.
  • Mapping— An association of a repository path with a local working folder on the client computer.
  • Working folder— A directory on the client computer containing a local copy of some subset of the files and folders in a repository.
  • Workspace— A definition of an individual user’s copy of the files from the repository. The workspace contains a reference to the repository and a series of mappings that associate a repository path with a working folder on the user’s computer.
  • Change set— A set of modifications to one or more files/folders that is atomically applied to the repository at check-in.
  • Shelve— The operation of archiving all modifications in the current change set and replacing those files with original copies. The shelved files can be retrieved at a later time for development to be continued. This is my favorite feature.
Tagged : / / / / / / /

Important Configuration Definitions

  • Source code— Files written in high-level languages such as C# that need to be compiled (for example, foo.cs).
  • Source(s)— All the files involved in building a product (for example, C, CPP, VB, DOC, HTM, H, and CS). This term is used mostly as a catch-all phrase that is specific not only to source code files but to all the files that are stored in version tracking systems.
  • Codeline— A tree or branch of code that has a specific purpose, such as the mainline, release line, or hotfix line that grows collectively.
  • Mainline or trunk (“The Golden Tree”)— The main codeline of the product that contains the entire source code, document files, and anything else necessary to build and release the complete product.
  • Snapshot— A specific point in time in which the sources and build are captured and stored, usually on a release or build machine.
  • Milestone— A measurement of work items that includes a specified number of deliverables for a given project scheduled for a specified amount of time that are delivered, reviewed, and fixed to meet a high quality bar. The purpose of a milestone is to understand what is done, what is left to do, and how that fits with the given schedule and resources. To do this, the team must complete a portion of the project and review it to understand where the project is in the schedule and to reconcile what is not done with the rest of the schedule. A milestone is the best way to know how much time a portion of the project will take.
  • Code freeze— A period when the automatic updates and build processes are stopped to take the final check-ins at a milestone.
  • Public build— A build using the sources from the mainline or trunk.
  • Private build (also referred to as a sandbox build)— A build using a project component tree to build more specific pieces of the product. This is usually done prior to checking in the code to the mainline.
  • Branching— A superset of files off the mainline taken at a certain time (snapshot) that contains new developments for hotfixes or new versions. Each branch continues to grow independently or dependently on the mainline.
  • Forking— Cloning a source tree to allow controlled changes on one tree while allowing the other tree to grow at its own rate. The difference between forking and branching is that forking involves two trees, whereas branching involves just one. It is also important to note that forking or cloning makes a copy (snapshot) of the tree and does not share the history between the two trees, whereas branching does share the history.
  • Virtual Build Labs (VBLs)— A Virtual Build Lab is a build lab that is owned by a specific component or project team. The owner is responsible for propagating and integrating his code into the mainline or public build. Each VBL performs full builds and installable releases from the code in its source lines and the mainline. Although the term virtual is used in the name of the labs, don’t confuse it with Virtual PC or Virtual Machines because the labs are real physical rooms and computer boxes. It is not recommended that you use Virtual software for build machines except possibly for an occasional one-off or hotfix build. , “The Build Lab and Personnel.” There is usually a hierarchy of VBLs so that code “rolls up” to the mainline or trunk. For example, let’s say that you have a mainline, Project A is a branch off of the mainline, and Developer 1 has a branch off the project branch. Developer 1 has several branches off his branch, with each branch representing a different component of the product. If he wants to integrate one of his branches into main, he should first merge his changes with all the levels above the branch to make sure he gets all the changes. Alternatively, he can just roll the changes into main, which sits higher in the hierarchy. This will become clearer in the next couple of pages.
  • Reverse integration (RI)— The process of moving sources from one branch or tree to another that is higher in the VBL hierarchy.
  • Forward integration (FI)— The process of moving sources from one branch or tree to another that is lower in the VBL hierarchy.
  • Buddy build— A build performed on a machine other than the machine that the developer originally made changes on. This is done to validate the list of changed files so that there are no unintended consequences to the change in the mainline build.
Tagged : / / / / / / / /

More Important Build Definitions

I need to define some common build terms that are used throughout this article. It is also important for groups or teams to define these terms on a project-wide basis so that everyone is clear on what he is getting when a build is released.

  • Pre-build— Steps taken or tools run on code before the build is run to ensure zero build errors. Also involved are necessary steps to prepare the build and release machines for the daily build, such as checking for appropriate disk space.
  • Post-build— Includes scripts that are run to ensure that the proper build verification tests (BVTs) are run. This also includes security tests to make sure the correct code was built and nothing was fused into the build.
  • Clean build— Deleting all obj files, resource files, precompiled headers, generated import libraries, or other byproducts of the build process. I like to call this cleaning up the “build turds.” This is the first part of a clean build definition. Most of the time, build tools such as NMake.exe or DevEnv.exe handle this procedure automatically, but sometimes you have to specify the file extensions that need to be cleaned up. The second part of a clean build definition is rebuilding every component and every piece of code in a project. Basically the perfect clean build would be building on a build machine with the operating system and all build tools freshly installed.
  • Incremental build— The secret to getting out a daily build to the test team, regardless of circumstances, is to perform incremental builds instead of daily clean builds. This is also the best way that you can maintain quality and a known state of a build. An incremental build includes only the code of the source tree that has changed since the previous build. As you can guess, the build time needed for an incremental build is just a fraction of what a clean build takes.
  • Continuous integration build— This term is borrowed from the extreme programming (XP) practice. It means that software is built and tested several times per day as opposed to the more traditional daily builds. A typical setup is to perform a build every time a code check-in occurs.
  • Build break— In the simplest definition, a build break is when a compiler, linker, or other software development tool (such as a help file generator) outputs an error caused by the source code it was run against.
  • Build defect— This type of problem does not generate an error during the build process; however, something is checked into the source tree that breaks another component when the application is run. A build break is sometimes referred to or subclassed as a build defect.
  • Last known good (LKG) or internal developers workstation (IDW) builds— These terms are used as markers to indicate that the build has reached a certain quality assurance criterion and that it contains new high-priority fixes that are critical to the next baseline of the shipping code. The term LKG originated in the Visual Studio team, and IDW came from the Windows NT organization. LKG seems to be the more popular term at Microsoft.
Tagged : / / / / / / / /

Different Perforce Tools and Their Short Summary | Know About Different Perforce tools

different-perforce-tools

Different Perforce Tools and Their Short Summary

Clients
P4V: Visual Client – (Included in the P4V Installer)
Provides access to versioned files through a graphical interface and also includes tools for merging and visualizing code evolution.
P4Merge: Visual Merge Tool – (Included in the P4V Installer)
Provides graphical three-way merging and side-by-side file comparisons
P4: Command-Line Client – (Included in the Perforce Server Windows Installer)
(Included in the Perforce Server Windows Installer)
P4Web: Web Client – (Included in the P4Web Installer)
Provides convenient access to versioned files through popular web browsers

Server
P4D: Server – (Included in the Perforce Server Windows Installer)
Stores and manages access to versioned files, tracks user operations and records all activity in a centralized database.
P4P: Proxy Server – (Included in the Perforce Server Windows Installer)
A self-maintaining proxy server that caches versioned files remotely on distributed networks.

Plug-ins & Integrations
P4WSAD: Plug-in for Eclipse and WebSphere Studio
Access Perforce from within the Eclipse IDE and the Rational/WebSphere Studio WorkBench family of products
P4SCC: SCC Plug-in – (Included in the P4V Installer)
Enables you to perform Perforce operations from within IDEs that support the Microsoft SCC API including Visual Studio.
P4EXP: Plug-in for Windows Explorer – (Included in the P4V Installer)
Allows Windows users direct access to Perforce.
P4DTG: Defect Tracking Gateway – (Included in the P4DTG Installer)
Allows information to be shared between Perforce’s basic defect tracking system and external defect tracking systems.
P4GT: Plug-in for Graphical Tools
Provides seamless access to version control for files from within Adobe Photoshop, SoftImage XSI, Autodesk’s 3ds max, and Maya
P4OFC: Plug-in for Microsoft Office
Allows documents to be easily stored and managed in Perforce directly from Microsoft Word, Excel, PowerPoint and Project.

Tools & Utilities
P4Report: Reporting System
Supports leading tools such as Crystal Reports, Microsoft Access, and Microsoft Excel, or any reporting
tool that interfaces with an ODBC data source.
P4Thumb: Thumbnail Generator
Creates thumbnails of graphics files managed by Perforce and stores the thumbnails in the server for presentation in P4V.
P4FTP: FTP Plug-in
Allows FTP clients like Dreamweaver, Netscape, and Internet Explorer to access files in Perforce depots.’
Links to Download: http://www.perforce.com/perforce/downloads/platform.html

Good Video Tutorial Links
http://www.perforce.com/perforce/media_library/tutorials.html
http://www.perforce.com/perforce/demo/testdrive.html

Tagged : / / / / / / / / / / / / / / / / / /

How to Understand Epoch & Unix Timestamp | Epoch Converter

epoch-unix-timestamp

What is epoch time?

The Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z). Literally speaking the epoch is Unix time 0 (midnight 1/1/1970), but ‘epoch’ is often used as a synonym for ‘Unix time’. Many Unix systems store epoch dates as a signed 32-bit integer, which might cause problems on January 19, 2038 (known as the Year 2038 problem or Y2038).

Human readable time Seconds
1 hour 3600 seconds
1 day 86400 seconds
1 week 604800 seconds
1 month (30.44 days) 2629743 seconds
1 year (365.24 days) 31556926 seconds

How to get the current epoch time in …

Perl time
PHP time()
Ruby Time.now (or Time.new). To display the epoch: Time.now.to_i
Python import time first, then time.time()
Java long epoch = System.currentTimeMillis()/1000;
Microsoft .NET C# epoch = (DateTime.Now.ToUniversalTime().Ticks – 621355968000000000) / 10000000;
VBScript/ASP DateDiff(“s”, “01/01/1970 00:00:00”, Now())
R as.numeric(Sys.time())
Erlang calendar:datetime_to_gregorian_seconds(calendar:now_to_universal_time( now()))-719528*24*3600.
MySQL SELECT unix_timestamp(now()) More info (+ negative epochs)
PostgreSQL SELECT extract(epoch FROM now());
Oracle PL/SQL SELECT (SYSDATE – TO_DATE(’01/01/1970 00:00:00′, ‘MM-DD-YYYY HH24:MI:SS’)) *
24 * 60 * 60 FROM DUAL
SQL Server SELECT DATEDIFF(s, ‘1970-01-01 00:00:00’, GETUTCDATE())
JavaScript Math.round(new Date().getTime()/1000.0) getTime() returns time in milliseconds.
Tcl/Tk clock seconds
Unix/Linux Shell date +%s
PowerShell Get-Date -UFormat “%s” Produces: 1279152364.63599
Other OS’s Command line: perl -e “print time” (If Perl is installed on your system)

Convert from human readable date to epoch

Perl Use the Perl Epoch routines
PHP mktime(hour, minute, second, month, day, year) More info
Ruby Time.local(year, month, day, hour, minute, second, usec ) (or Time.gm for GMT/UTC input). To display add .to_i
Python import time first, then int(time.mktime(time.strptime(‘2000-01-01 12:34:00’, ‘%Y-%m-%d %H:%M:%S’))) – time.timezone
Java long epoch = new java.text.SimpleDateFormat (“MM/dd/yyyy HH:mm:ss”).parse(“01/01/1970 01:00:00”).getTime();
VBScript/ASP DateDiff(“s”, “01/01/1970 00:00:00”, time field) More info
C Use the C Epoch Converter routines
R as.numeric(as.POSIXct(“MM/dd/yyyy HH:mm:ss”, origin=”1970-01-01″))
MySQL SELECT unix_timestamp(time) Time format: YYYY-MM-DD HH:MM:SS or YYMMDD or YYYYMMDD
More on using Epoch timestamps with MySQL
PostgreSQL SELECT extract(epoch FROM date(‘2000-01-01 12:34’));
With timestamp: SELECT EXTRACT(EPOCH FROM TIMESTAMP WITH TIME ZONE ‘2001-02-16 20:38:40-08’);
With interval: SELECT EXTRACT(EPOCH FROM INTERVAL ‘5 days 3 hours’);
SQL Server SELECT DATEDIFF(s, ‘1970-01-01 00:00:00’, time field)
JavaScript Use the JavaScript Date object
Unix/Linux Shell date +%s -d”Jan 1, 1980 00:00:01″ Replace ‘-d’ with ‘-ud’ to input in GMT/UTC time.

Convert from epoch to human readable date

Perl Use the Perl Epoch routines
PHP date(output format, epoch); Output format example: ‘r’ = RFC 2822 date More info
Ruby Time.at(epoch)
Python import time first, then time.strftime(“%a, %d %b %Y %H:%M:%S +0000”, time.localtime(epoch)) Replace time.localtime with time.gmtime for GMT time. More info
Java String date = new java.text.SimpleDateFormat(“MM/dd/yyyy HH:mm:ss”).format(new java.util.Date (epoch*1000));
VBScript/ASP DateAdd(“s”, epoch, “01/01/1970 00:00:00”) More info
C Use the C Epoch Converter routines
R as.POSIXct(epoch, origin=”1970-01-01″)
MySQL from_unixtime(epoch, optional output format) The default output format is YYY-MM-DD HH:MM:SS more …
PostgreSQL PostgreSQL version 8.1 and higher: SELECT to_timestamp(epoch); More info Older versions: SELECT TIMESTAMP WITH TIME ZONE ‘epoch’ + epoch * INTERVAL ‘1 second’;
Oracle PL/SQL SELECT to_date(’01-JAN-1970′,’dd-mon-yyyy’)+(1326357743/60/60/24) from dual
Replace 1326357743 with epoch.
SQL Server DATEADD(s, epoch, ‘1970-01-01 00:00:00’)
Microsoft Excel =(A1 / 86400) + 25569 Format the result cell for date/time, the result will be in GMT time (A1 is the cell with the epoch number). For other time zones: =((A1 +/- time zone adjustment) / 86400) + 25569.
Crystal Reports DateAdd(“s”, {EpochTimeStampField}-14400, #1/1/1970 00:00:00#) -14400 used for Eastern Standard Time. See Time Zones.
JavaScript Use the JavaScript Date object
Tcl/Tk clock format 1325376000 More info
Unix/Linux Shell date -d @1190000000 Replace 1190000000 with your epoch, needs recent version of ‘date’. Replace ‘-d’ with ‘-ud’ for GMT/UTC time.
PowerShell Function get-epochDate ($epochDate) { [timezone]::CurrentTimeZone.ToLocalTime(([datetime]’1/1/1970′).AddSeconds($epochDate)) }, then use: get-epochDate 1279152364. Works for Windows PowerShell v1 and v2
Other OS’s Command line: perl -e “print scalar(localtime(epoch))” (If Perl is installed) Replace ‘localtime’ with ‘gmtime’ for GMT/UTC time.

Reference

http://www.epochconverter.com/

Tagged : / / / / / / / / / / / / / / /

Branching and Merging Best Practices | Branching and Merging Guide

branching-and-merging

Branching and Merging Practices

Tagged : / / / / / / / / / / / / / / / / /

Hybrid testing introduction, What is Hybrid testing?

hybrid-testing

Hybrid testing definition. testing. A combination of top-down testing with bottom-up testing of prioritized or available components

 

According to Wiki:

Hybrid testing is what most frameworks evolve into over time and multiple projects. The most successful automation frameworks generally accommodate both grammar and spelling as well as information input. This allows information given to be cross checked against existing and confirmed information. This helps to prevent false or misleading information being posted. It still however allows others to post new and relevant information to existing posts and so increases the usefulness and relevance of the site. This said, no system is perfect and it may not perform to this standard on all subjects all of the time but will improve with increasing input and increasing use.

According to Tutorialspoint:

We know that Integration Testing is a phase in software testing in which standalone modules are combined and tested as a single entity. During that phase, the interface and the communication between each one of those modules are tested. There are two popular approaches for Integration testing which is Top down Integration Testing and Bottom up Integration Testing.

In Hybrid Integration Testing, we exploit the advantages of Top-down and Bottom-up approaches. As the name suggests, we make use of both the Integration techniques.

Reference/Content Source: –

https://en.wikipedia.org/wiki/Hybrid_testing

https://www.tutorialspoint.com/software_testing_dictionary/hybrid_integration_testing.htm

Tagged : / / / / / / / / / /

Website Typography

website-typography

Below is a list with arrows. To use this style create a list in the following format:

    • ….
    • ….

  • Quisque ultrices etiam, class nec velit vestibulum sit congue pulvinar, mattis penatibus proin odio placerat ante.

To use this style create a list in the following format:

    • ….
    • ….

  • Quisque ultrices etiam, class nec velit vestibulum sit congue pulvinar, mattis penatibus proin odio placerat ante.

Below is a list with circle. To use this style create a list in the following format:

    • ….
    • ….

  • Quisque ultrices etiam, class nec velit vestibulum sit congue pulvinar, mattis penatibus proin odio placerat ante.

 

Alert box

This is a sample pin note. Use Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer urna. Aenean tristique. Fusce a neque. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.

Info box

This is a sample pin note. Use Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer urna. Aenean tristique. Fusce a neque. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.

Download box

This is a sample pin note. Use Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer urna. Aenean tristique. Fusce a neque. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.

Code
#subheader h1 {
float: left;
margin-top: 28px;
background: url(../images/logo.gif) no-repeat;
width: 335px;
height: 58px;
text-indent: -9999px;
}

 

Tagged : / / / / / / / / / / / / /

What is Information Technology Infrastructure Library (ITIL) ? – Complete Guide

information-technology-infrastructure-library-itil/

Introduction

The Information Technology Infrastructure Library (ITIL) is a set of concepts and practices for managing Information Technology (IT) services (ITSM), IT development and IT operations.

Purpose

ITIL stresses service quality and focuses on how IT services can be efficiently and cost-effectively provided and supported. In the ITIL framework, the business units within an organization who commission and pay for IT services (e.g. Human Resources, Accounting), are considered to be “customers” of IT services. The IT organization is considered to be a service provider for the customers.

It primarily focuses on what processes are needed to ensure high quality IT services; however, ITIL does not provide specific, detailed descriptions about how the processes should be implemented, as they will be different in each organization. In other words, ITIL tells an organization what to do, not how to do it.

The ITIL framework is typically implemented in stages, with additional processes added in a continuous service improvement program.

Benefits
Organizations can benefit in several important ways from ITIL:

· IT services become more customer-focused

· The quality and cost of IT services are better managed

· The IT organization develops a clearer structure and becomes more efficient

· IT changes are easier to manage

· There is a uniform frame of reference for internal communication about IT

· IT procedures are standardized and integrated

· Demonstrable and auditable performance measurements are defined

Processes

ITIL is a series of books that outline a comprehensive and consistent set of process-based best practices for IT Service Management, promoting the ultimate achievement of IT Service Management goals. IT Service Management (ITSM) is the process of managing IT services to effectively and efficiently meet the needs of the customer.

Versions

In 2001, version 2 of ITIL was released. The Service Support and Service Delivery books were redeveloped into more concise usable volumes and consequently became the core focus of ITIL. Over the following few years it became, by far, the most widely used IT service management best practice approach in the world.

In May 2007 version 3 of ITIL was published. This adopted more of a lifecycle approach to service management, with greater emphasis on IT business integration.

Where ITIL V2 outlined what should be done to improve processes, ITIL V3 explains clearly how you should go about doing it.

ITIL V2 Explained

The Service Management section of ITIL V2 consists of eleven disciplines and is divided into two sections as follows:

Service Support:

• Configuration Management

• Service Desk

• Incident Management

• Problem Management

• Change Management

• Release Management

Service Delivery:

• Availability Management

• IT Services Continuity Management

• Capacity Management

• Financial Management

• Service Level Management

Here are the details of Service support components.

1. Configuration Management

Objectives:

• Providing information on the IT infrastructure

o To all other processes

o IT Management

• Enabling control of the infrastructure by monitoring and maintaining information

on:

o All the resources needed to deliver services

o Configuration Item (CI) status and history

o Configuration Item relationships

Tasks:

• Identification and naming

• Management information

• Verification

• Control

• Status Accounting

Asset: Component of a business process like people, accommodation, computer systems,

paper records, fax machines, etc.

Configuration Management Database: A database, which contains all relevant details of

each Configuration Item (CI) and details of the important relationships between CIs.

A Configuration Item (CI):

• Is needed to deliver a service

• Is uniquely identifiable

• Is subject to change

• Can be managed

A Configuration Item (CI) has:

• a Category

• Relationships

• Attributes

• a Status

Variant: A Configuration Item (CI) that has the same basic functionality as another

Configuration Item (CI) but is different in some small way (ex: has more memory)

Baseline: A snapshot of the state of a Configuration Item and any component or related

Configuration Items, frozen in time for a particular purpose (such as the ability to return a

service to a trusted state if a change goes wrong)

Configuration Management supports all other processes!

Scope vs. Detail

Relationships – Common Types:

• Is a component of

• Is a copy of

• Relates to

• Relates with

• Is used by

2. Service Desk

Objectives:

• To be the primary point of call for all:

o Calls

o Questions

o Requests

o Complaints

o Remarks

• To restore the service as quickly as possible

• To manage the incident life-cycle (coordinating resolution)

• To support business activities

• To generate reports, to communicate and to promote

Different Desks

• Call Center: Handling large call volumes of telephone-based transactions.

• Help Desk: To manage, coordinate, and resolve Incidents as quickly as possible.

• Service Desk: Allowing business processes to be integrated into the Service

Management infrastructure. It not only handles Incidents, Problems and questions,

but also provides an interface for other activities.

Service Desk Essentials:

• Single point of contact / Restore service ASAP

• Tasks: Customer Interface, Business Support, Incident Control & Management

Information

• Concentrates on incident lifecycle management

• Incident: Unexpected disruption to agreed service

• Priority determined by business impact and urgency

• Correct assessment of priorities enables the deployment of manpower and other

resources to be in the best interests of the customer

• Escalation and referral

3. Incident Management

Objectives:

• To restore normal service as quickly as possible

• Minimize the adverse impact on business operations

• Ensuring that the best possible levels of service quality and availability are

maintained according to SLAs.

Incident: Any event which is not part of the standard operation of a service and which

causes or may cause an interruption to or a reduction in the quality of that service.

Work-Around: Method of avoiding an Incident or Problem.

Service Request: Every Incident not being a failure in the IT Infrastructure.

Problem: The unknown root cause of one or more incidents.

Known Error: A condition that exists after the successful diagnosis of the root cause of a

problem when it is confirmed that a CI (Configuration Item) is at fault.

Impact on the business + Urgency / Effect upon business deadlines = Priority

Category: Classification of a group of Incidents (Application, Hardware, etc.)

Escalation (Vertical Escalation): escalates up the management chain.

Referral (Horizontal Escalation): escalates to a different knowledge group. Routing.

Incident Life-Cycle

• Accept Service Event, Register and Consult the CMDB

• Classification

• Solve

• Closure

Reporting is VERY important.

• Daily reviews of individual Incident and Problem status against service levels

• Weekly management reviews

• Monthly management reviews

• Proactive service reports

4. Problem Management

Objectives:

• Stabilizing IT services through:

o Minimizing the consequences of incidents

o Removal of the root causes of incidents

o Prevention of incidents and problems

o Prevent recurrence of Incidents related to errors

• Improving productive use of resources

Tasks:

• Problem Control

• Error Control (including raising RfCs – Request for Change)

• Proactive Prevention

• Identifying Trends

• Management Information

• Posit Implementation Review (PIR)

Goal is to get from reactive or proactive. Stop problems from occurring / recurring.

Inputs:

• Incident details

• Configuration details

• Defined work-arounds

Outputs:

• Known Errors

• Requests for Change

• Updated Problem Records including work-arounds and/or solutions

• Response to Incident Management from Matching Management Information

Problem Control

• Identification

• Classification

• Assign Resources

• Investigation and Diagnosis

• Establish Known Error

Error Control

• Error Identification and Recording

• Error Assessment

• Recording Error / Resolution (Send out RfC)

• Error Closure

Known Error: An Incident or Problem for which the root cause is known and for which a

temporary Work-around or a permanent alternative has been identified.

Proactive Problem Management:

• Trend Analysis

• Targeting Support Action

• Providing Information to the Organization

Known Errors resulting from Development should be made known to the Helpdesk.

Reporting is also key for Problem Management.

5. Change Management

Objective: To implement approved changes efficiently, cost-effectively and with minimal

risk to the existing and to the new IT infrastructure. Only approved changes made, risk

and cost minimized.

Change Management Tasks:

• Filtering Changes

• Managing Change Process

• Managing Changes

• Chairing CAB and CAB/EC

• Review and Closure

• Management Information

Inputs:

• Requests for Change (RfC)

• CMDB

• Forward Schedule of Changes (FSC)

Outputs:

• Forward Schedule of Changes (FSC)

• Requests for Change (RFC)

• CAB minutes and actions

• Change management reports

Impact of change:

• Category 1

o Little impact on current services. The Change Manager is entitled to

authorize this RfC.

• Category 2

o Clear impact on services. The RfC must be discussed in the Change

Advisory Board. The Change Manager requests advice on authorization

and planning.

• Category 3

o Significant impact on the services and the business. Considerable

manpower and/or resources needed. The RfC will have to be submitted to

the board level (CAB/EC – Change Advisory Board / Executive

Committee)

Priority Setting:

• Urgent

o Change necessary now (otherwise severe business impact)

• High

o Change needed as soon as possible (potentially damaging)

• Medium

o Change will solve irritating errors or missing functionality (can be

scheduled)

• Low

o Change leads to minor improvements

A change backout plan must always be possible.

Change management always ends with a review of the change.

Change: The addition, modification, or removal of approved, supported or baselined

hardware, network, software, application, environment, system, desktop build or

associated documentation.

Request for Change: Form or screen, used to record details of a request for a change to

any CI within an infrastructure or to procedures and items associated with the

infrastructure.

Forward Schedule of Changes (FSC): Schedule that contains details of all the Changes

approved for implementation and their proposed implementation dates.

Change Management Process

1. Request for a Change

2. Registration and Classification

3. Monitoring and Planning

4. Approve

5. Build & Test

6. Authorize Implementation

7. Implementation

8. Evaluate

6. Release Management

Objectives:

• Safeguard all software and related items

• Ensure that only tested / correct version of authorized software are in use

• Ensure that only tested / correct version of authorized hardware are in use

• Right software, right time, right place

• Right hardware, right time, right place

Tasks:

• Define the release policies

• Control of the Definitive Software Library (DSL)

• Control of the Definitive Hardware Storage (DHS)

• Distribute Software and Associated CIs

• Carry out S/W audits (using CMDB)

• Manage the software releases

• Oversee build of the software releases

Releases are done under the control of Change Management.

DSL : Definitive Software Library. Reliable versions of software in a single logical

location. However, software may be physically stored at different locations.

Release Policy:

• Release Unit

• Full / Package / Delta Releases

• Numbering

• Frequency

• Emergency Change

Version Control:

• Development

• Testing

• Live

• Archive

Process:

• Software Control and Distribution (operational)

• Change Management (control)

• Configuration Management (control and administration)

Only process which creates its own policy.

Here are the details of Service Delivery components.

1. Availability Management

Objectives:

• To predict, plan for and manage the availability of services by ensuring that:

o All services are underpinned by sufficient, reliable and properly

maintained CIs

o Where CIs are not supported internally there are appropriate contractual

agreements with third party suppliers

o Changes are proposed to prevent future loss of service availability

• Only then can IT organizations be certain of delivering the levels of availability

agreed with customers in SLAs.

Aspects of Availability:

• Reliability

• Maintainability: Maintenance you do yourself, as a company

• Resilience: Redundancy

• Serviceability: Maintenance done by someone else

Availability Information is stored in an Availability Database (ADB). This information is

used to create the Availability Plan. SLAs provide an input to this process.

Unavailability Lifecycle

MTTR: Mean Time to Repair (Downtime) – Time period that elapses between the

detection of an Incident and it’s Restoration. Includes: Incident, Detection, Diagnosis,

Repair, Recovery, Restoration.

MTBF: Mean Time Between Failures (Uptime) – Time period that elapses between

Restoration and a new Incident.

MTBSI: Mean Time Between System Incidents – Time period that elapses between two

incidents. MTTR + MTBF.

“An IT service is not available to a customer if the functions that customer requires at

that particular location cannot be used although the agreed conditions under which the IT

service is supplied are being met”

Simplistic Availability Calculation:

Agreed Service Hours – Downtime 100

—————————————— X —-

Agreed Service Hours 1

2. IT Service Continuity Management

Why plan?

• Increases Business dependency on IT

• Reduced cost and time of recovery

• Cost to customer relationship

• Survival

Many businesses fail within a year of suffering a major IT disaster.

Business Impact Analysis:

Risk Analysis:

• Value of Assets

• Threats

• Vulnerabilities

Risk Management:

• Countermeasures

• Planning for potential disasters

• Managing a disaster

Risk Analysis: Based on the CCTA Computer Risk Analysis and Management

Methodology (CRAMM)

Options:

1. Do nothing

2. Manual workarounds

3. Reciprocal arrangements

4. Gradual Recovery (cold standby)

5. Intermediate Recovery (warm standby)

6. Immediate Recovery (hot standby)

Cold start = accommodation. Environmental controls; power and communications

Hot start = cold start + computing equipment and software

7 Sections of the Plan:

1. Administration

2. The IT Infrastructure

3. IT Infrastructure management & Operating procedures

4. Personnel

5. Security

6. Contingency site

7. Return to normal

Test and Review:

• Initially then every 6 to 12 months and after each disaster

• Test it under realistic circumstances

• Move / protect any live services first

• Review and change the plan

• All changes made via the CAB – Change Advisory Board

Contingency Plan:

• Assists in fast, controlled recovery

• Must be given wide but controlled access

• Contents (incl. Admin, Infrastructure, People, Return to normal)

• Options (incl. Cold & Hot Start)

• Must be tested regularly – without impacting the live service

3. Capacity Management

Objective:

To determine the right, cost justifiable, capacity of IT resources such that the Service

Levels agreed with the business are achieved at the right time.

Objectives:

• Demand Management

o Business Capacity Management

• Workload Management

o Service Capacity Management

• Resource Management

o Resource Capacity Management

While doing the above, also need to do:

• Performance Management

o Internal and External Financial Data

o Usage Data

o SLM Data / Response Times

CDB – Capacity Data Base – Contains all Metrics, etc. Used to create a Capacity

Management Plan. Performance Management Data populates the CDB.

Essentials:

• From Customer Demands to Resources

• Demand Management

• Workload Management

• Performance Management

• Capacity Planning

• Defining Thresholds and Monitoring

Application Sizing: To estimate the resource requirements to support a proposed

application change to ensure that it meets its required service levels.

Modeling:

• Trend Analysis

• Analytical Modeling

• Simulation Modeling

• Baseline Models

• Used to Answer the “What If… “ questions

• Data for Modeling comes from the CDB

4. Financial Management

Objectives:

To provide information about and control over the costs of delivering IT services that

support customers business needs.

Costing is a must!

Input cost units recommended by ITIL:

• Equipment Cost Units (ECU)

• Organization Cost Units (OCU)

• Transfer Cost Units (TCU)

• Accommodation Cost Units (ACU)

• Software Cost Units (SCU)

Equipment = hardware

Organization = staff

Transfer = costs which IT incurs acting as an agent for the customer, they do not appear

as a cost against the IT department’s budget

Accommodation = buildings

Software = software

Different Cost Types:

• Fixed – unaffected by the level of usage

• Variable – varying according to the level of usage

• Direct – usage specific to one service

• Indirect or Overhead – usage not specific to one service

• Capital – not diminished by usage

• Revenue or running – diminish with usage

Charging Objectives:

• Recover from customers the full costs of the IT services provided

• Ensure that customers are aware of the costs they impose on IT

• Ensure that providers have an incentive to deliver and agreed quality and quantity

of economic and effective services

Charging and Pricing Options:

Charging:

• No Charging – IT treated as support center

• Notional Charging – IT treated as cost center

• Actual Charging

Pricing:

• Recover of Costs – IT treated as a service center

• Cost Price Plus – IT treated as a profit center

• Market Prices – IT treated as a profit center

Support and Cost centers used “soft charging” in which no money changes hands; service and profit centers use “hard costing” in which money is transferred between bank

accounts

Profit centers focus on the value of the IT service to the customer

Good Financial Management minimizes the risks in decision making

Three Main Processes:

Budgeting: The process of predicting and controlling the spending of money within the

enterprise and consists of periodic negotiation cycle to set budgets (usually annual) and

the day-to-day monitoring of the current budgets. Key influence on strategic and tactical

plans.

IT Accounting: The set of processes that enable the IT organization to fully account for

the way its money is spent (particularly the ability to identify costs by customer, by

service, by activity).

Charging: The set of processes required to bill a customer for the services applied to

them. To achieve this requires sound IT Accounting, to a level of detail determined by

the requirements of the analysis, billing, and reporting procedures.

5. Service Level Management

Balance between the Demand for IT services and the Supply of IT services by knowing

the requirements of the business and knowing the capabilities of IT.

Objectives:

• Business-like relationship between customer and supplier

• Improved specification and understanding of service requirements

• Greater flexibility and responsiveness in service provision

• Balance customer demands and cost of services provision

• Measurable service levels

• Quality improvement (continuous review)

• Objective conflict resolution

Tasks:

• Service Catalog

• Service Level Requirements

• Service Level Agreement

• Operational Level Agreements (OLA) and Contracts

• Service Specsheet

• Service Quality Plan

• Monitor, Review and Report

• Service Improvement Programs

• Customer Relationship Management

Minimum Requirements for an Agreement:

• Period

• Service Description

• Throughput

• Availability

• Response Times

• Signature

Other Possible Clauses:

• Contingency arrangements

• Review procedures

• Change procedures

• Support services

• Customer responsibilities

• Housekeeping

• Inputs and Outputs

• Changes

Ideally contracts are based on targets in the SLA

SLAs must be monitored regularly and reviewed regularly

• Monitor to see if service is being delivered to specification

• Review to see if service specification is still appropriate

Overview of the ITIL v3 library

Five volumes comprise the ITIL v3, published in May 2007:

1. ITIL Service Strategy

2. ITIL Service Design

3. ITIL Service Transition

4. ITIL Service Operation

5. ITIL Continual Service Improvement

Service Strategy

As the center and origin point of the ITIL Service Lifecycle, the ITIL Service Strategy volume provides guidance on clarification and prioritization of service-provider investments in services. More generally, Service Strategy focuses on helping IT organizations improve and develop over the long term. In both cases, Service Strategy relies largely upon a market-driven approach. Key topics covered include service value definition, business-case development, service assets, market analysis, and service provider types. List of covered processes:

  • Service Portfolio Management
  • Demand Management
  • IT Financial Management
  • Supplier Management

Service Design

The ITIL Service Design volume provides good-practice guidance on the design of IT services, processes, and other aspects of the service management effort. Significantly, design within ITIL is understood to encompass all elements relevant to technology service delivery, rather than focusing solely on design of the technology itself. As such, Service Design addresses how a planned service solution interacts with the larger business and technical environments, service management systems required to support the service, processes which interact with the service, technology, and architecture required to support the service, and the supply chain required to support the planned service. Within ITIL v2, design work for an IT service is aggregated into a single Service Design Package (SDP). Service Design Packages, along with other information about services, are managed within the service catalogs. List of covered processes:

  • Service Catalogue Management
  • Service Level Management
  • Risk Management
  • Capacity Management
  • Availability Management
  • IT Service Continuity Management
  • Information Security Management
  • Compliance Management
  • IT Architecture Management
  • Supplier Management

Service Transition

Service transition, as described by the ITIL Service Transition volume, relates to the delivery of services required by a business into live/operational use, and often encompasses the “project” side of IT rather than “BAU”. This area also covers topics such as managing changes to the “BAU” environment.

List of processes:

  • Service Asset and Configuration Management
  • Service Validation and Testing
  • Evaluation
  • Release Management
  • Change Management
  • Knowledge Management

Service Operation

Best practice for achieving the delivery of agreed levels of services both to end-users and the customers (where “customers” refer to those individuals who pay for the service and negotiate the SLAs). Service operation, as described in the ITIL Service Operation volume, is the part of the lifecycle where the services and value is actually directly delivered. Also the monitoring of problems and balance between service reliability and cost etc are considered. The functions include technical management, application management, operations management and Service Desk as well as, responsibilities for staff engaging in Service Operation.

List of processes:

  • Event Management
  • Incident Management
  • Problem Management
  • Request Fulfillment
  • Access Management

Continual Service Improvement (CSI)

Aligning and realigning IT services to changing business needs (because standstill implies decline).

Continual Service Improvement, defined in the ITIL Continual Service Improvement volume, aims to align and realign IT Services to changing business needs by identifying and implementing improvements to the IT services that support the Business Processes. The perspective of CSI on improvement is the business perspective of service quality, even though CSI aims to improve process effectiveness, efficiency and cost effectiveness of the IT processes through the whole lifecycle. To manage improvement, CSI should clearly define what should be controlled and measured.

CSI needs to be treated just like any other service practice. There needs to be upfront planning, training and awareness, ongoing scheduling, roles created, ownership assigned, and activities identified to be successful. CSI must be planned and scheduled as process with defined activities, inputs, outputs, roles and reporting.

List of processes:

  • Service Level Management
  • Service Measurement and Reporting
  • Continual Service Improvement

———————————————————————————————————————————-

Tagged : / / / / / / / / / / / / / / /