Introduction of Apache Ant

Apache Ant is a software tool for automating software build processes. It is similar to Make but is implemented using the Java language, requires the Java platform, and is best suited to building Java projects.

The most immediately noticeable difference between Ant and Make is that Ant uses XML to describe the build process and its dependencies, whereas Make has its Makefile format. By default the XML file is named build.xml.

Ant is an Apache project. It is open source software, and is released under the Apache Software License.

Tagged : / / / / / / / /

Agile Software Development Methodology

What is Agile Software Development Methodology?

Agile development practices increase the velocity at which software teams deliver customer value by improving everyone’s visibility into project features, quality and status.

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.
Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

General Definition
There are many specific agile development methods. Most promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.

Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing.




This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.[1] Multiple iterations may be required to release a product or new features.

Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration’s requirements.

Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc.

Most agile teams work in a single open office (called bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams.

No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals.

Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. This standing face-to-face communication prevents problems from being hidden.

Specific tools and techniques such as continuous integration, automated or xUnit test, pair programming, test driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance project agility.



Some of the principles behind the Agile Manifesto are:

* Customer satisfaction by rapid, continuous delivery of useful software
* Working software is delivered frequently (weeks rather than months)
* Working software is the principal measure of progress
* Even late changes in requirements are welcomed
* Close, daily cooperation between business people and developers
* Face-to-face conversation is the best form of communication (co-location)
* Projects are built around motivated individuals, who should be trusted
* Continuous attention to technical excellence and good design
* Simplicity
* Self-organizing teams
* Regular adaptation to changing circumstances


Tagged : / / / / / /

Introducing Team Foundation Build 2010 | TFS 2010 Training

Introducing Team Foundation Build 2010
  • Introduction
  • Build Automation
  • Flickr’s Continuous Deployment
  • Why Automate the Build?
  • Team Build Overview
  • Demo: Team Build Overview
  • Machines, Controllers, and Agents
  • Build System Topologies
  • Build Agent Software Installation
  • New in 20102
  • Build Status and Notification
  • Demo: Build Alerts
  • Demo: Build Notification Application4m 44s
  • The End Game
  • Summary
The Build Environment
  • Introduction
  • Installation and Configuration
  • Topology and Restrictions
  • Installing the Build Service
  • Demo: Installing the Build Service
  • Demo: Configuring Controller and Agents
  • Demo: Creating the Build Drop folder
  • Demo: Installing a Test Agent Instance
  • Installing and Configuration Summary
  • Demo: Creating and Running a Simple Build
  • Demo: Managing Build Artifacts
  • Summary
Simple Build Automation
  • Introduction
  • Build Definitions Options
  • Demo: General Options
  • Demo: Trigger Options
  • Demo: Workspace Mapping
  • Demo: Build Defaults Options
  • Demo: Process Options
  • Demo: Private or Buddy Builds
  • Gated Check In
  • Demo: Gated Check In
  • Build Reports
  • Summary
Working with Build Process Templates (Scripts)
  • Introduction
  • Build Process Templates
  • Demo: Hello World
  • Demo: Execution Scope
  • Demo: Build Script Arguments
  • Demo: Build Script Variables
  • Demo: InvokeProcess Activity
Migrating from TFS 2008 
  • Introduction
  • Overview
  • Build Automation in TFS 2008
  • Demo: Using the Upgrade Script4
  • Demo: Calling MSBuild from 2010 Build3
  • Demo: Custom MSBuild Tasks4
  • Summary
Tagged : / / / / / / / / / / / /

Software Development with Team Foundation Server 2015

  • Understanding the Feature Path from TFS 2013
  • Introduction
  • Overview
  • TFS 2013 Update Timeline
  • Agile Tools
  • Demo: Agile Tools
  • Git
  • Demo: Git Improvements
  • Demo: Git CodeLens
  • Demo: Pull Requests
  • Testing
  • Demo: Testing Features
  • Summary
Installing and Configuring TFS 2015
  • Introduction
  • Install Options
  • TFS Pre-upgrade Tool
  • Demo: Pre-upgrade Process
  • Upgrading to TFS 2015
  • Demo: Upgrade from TFS 2013 to TFS 2015 Update2
  • Demo: Verify the Upgrade
  • Demo: Project Rename
  • Summary
Working with New Kanban Board Features
  • Introduction
  • Portfolio Management
  • Demo: Epics
  • Demo: Features
  • Product Backlog
  • Demo: Product Backlog
  • Kanban
  • Demo: Kanban Board Intro
  • Demo: Kanban Columns
  • Demo: Kanban Swimlanes
  • Demo: Kanban – Working with Tasks
  • Customizations
  • Demo: Customizing the Cumulative Flow Diagram
  • Demo: Customizing Working Days
  • Demo: Customizing Bugs on the Backlog
  • Productivity
  • Demo: Creating Work Item Templates
  • Demo: Quick Search
  • Sprint Planning
  • Demo: Capacity Planning
  • Demo: Sprint Planning
  • Demo: Sprint Progress
  • Tracking Work
  • Demo: Charts and Alerts
  • Dashboards
  • Demo: Working with Dashboards
  • Summary
Working with New Version Control Features
  • Introduction
  • Version Control Enhancements
  • Demo: Git Branching Enhancements
  • Demo: Working with Git Branches
  • Git Rebase
  • Demo: Git Rebase
  • Git Branch Policies
  • Demo: Configure Branch Policies
  • Demo: Create a Pull Request
  • Demo: Resolve Branch Policy Issues
  • Quick Code Edit
  • Demo: Quick Code Edit
  • Summary
Building Software
  • Introduction
  • Build Agent
  • Demo: Configure a Build Agent
  • Demo: Build Capabilities
  • Build Definition
  • Demo: Create a Build Definition
  • Running a Build
  • Demo: Running a Build
  • Build Customization
  • Demo: Customize a Build and View Test Results
  • Demo: Customize with Build Steps
  • Demo: Multiple Configurations and Parallel Builds
  • Demo: Build Triggers – Continuous Integration and Pull Requests
  • Demo: Capabilities and Demands
  • Demo: Build Definition History
  • Demo: Build Definition Templates
  • Summary
Testing Software
  • Introduction
  • Test Hub1
  • Demo: Create a Test Plan
  • Demo: Create Test Suites
  • Demo: Create Test Cases
  • Demo: Create Test Cases from the Grid View
  • Demo: Shared Steps
  • Demo: Test Parameters
  • Demo: Shared Parameters
  • Demo: Running Tests
  • Demo: Test Run Analysis
  • Demo: Export Test Plans
  • Exploratory Testing Extension
  • Demo: Install Exploratory Testing Extension
  • Demo: Exploratory Testing
  • Demo: Exploratory Testing Results
  • Kanban Integration
  • Demo: Creating Test Cases from the Kanban Board
  • Summary
Integrating with TFS 2015
  • Introduction
  • Marketplace
  • Demo: Installing Marketplace Extensions
  • Demo: Working with Extensions
  • Demo: Manage Extensions
  • Creating Extensions
  • Demo: Create an Extension
  • Demo: Packaging Extensions
  • Demo: Install an Extension
  • TFS 2015 API
  • Demo: TFS 2015 API
  • Service Hooks
  • Demo: Service Hooks
  • Summary
Tagged : / / / / / / / / / / /

Introduction of Windows Internal | Windows Internal Overview | Windows Internal Quick Guide

Windows Resource Kits
The Microsoft® Windows Resource Kit Tools are a set of tools to help administrators streamline management tasks such as troubleshooting operating system issues, managing Active Directory®, configuring networking and security features, and automating application deployment.

Task and Responsibilities

  • Deployment
  • System administration scripting
  • Directory services
  • Networking and internetworking
  • Internet services
  • Custom and automated installations
  • Registry
  • Security
  • Policy-based administration
  • Server management
  • Clustering and load balancing
  • Performance management
  • Troubleshooting

About the Windows Server 2003 Resource Kit
Once you have download and installed the resource kit (very easy process), you are pretty much set up, now all you need to do it work with each tool so you know what they can do, and that’s the intention of this article series.

After the installation, go to Start => All Programs => Windows Resource Kit Tools => Command Shell

Download –

If you do a dir, you will see the directory listing for all the files listed here. Each file has a brief description of what it does:

Clearmem.exe: Clear Memory
Compress.exe: Compress Files
Confdisk.exe: Disk Configuration Tool
Consume.exe: Memory Consumers Tool
Dh.exe: Display Heap
Delprof.exe: User Profile Deletion Utility
Diskuse.exe: User Disk Usage Tool
Gpmonitor.exe: Group Policy Monitor
Instsrv.exe: Service Installer
Memmonitor.exe: Memory Monitor
Vrfydsk.exe: Verify Disk

Reference –

What is Windows Service?
Windows Service applications run for a long time and are mostly used in server environments therefore they are usually called long-running applications. Capability to create windows service is one of the powerful features of .net.

Windows Service applications do not have any user interface or they do not produce any visual output. Services can run in the background while a user is performing or executing any other task in the foreground. If any user messages are generated, they are written to the Windows Event Log.

Windows Services are controlled by the Service Control Manager that helps to start, stop or pause the windows service, as needed.

Examples of windows services include task scheduling, running message queues, file indexing, plug and play device detection etc.

In the source code, Windows Service extends the System.ServiceProcess.Service class.

All Windows Services that are built in .NET need to extend this class. Visual studio includes the following methods by default, which are overridden by the service when it is created.
Dispose – clean up any managed and unmanaged resources
OnStart – control the service startup
OnStop – control the service stoppage

How to create Windows Service?

  • Select a new project from File menu.
  • Expand “Visual Basic” tab and select “Windows”.
  • Then select Windows Service in it and specify the name of the service.
  • Then right click on the form and select Add Installer.
  • Project Installer gets added.
  • Select ServiceInstaller1, go to properties and set DisplayName, ServiceName and set StartType as Automatic.
  • Then select ServiceProcessInstaller1 and set Account property as LocalSystem.

Windows troubleshooting For Build Issues

  • OS Environment issues
  • Application Configuration settings
  • OS Memory Utilization
  • Disk I/O activies
  • Services running
  • Network issues

The Windows Chkdsk (check disk) utility can find and fix common problems with disks and storage devices.

Disk Cleanup utility
The Disk Cleanup utility is a simple tool in Windows XP and Windows Vista that can remove temporary files from your PC, thus freeing up hard disk space.

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

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


Different Perforce Tools and Their Short Summary

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

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:

Good Video Tutorial Links

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

Perforce Replication – What is Perforce Replication ?


Perforce Replication

Replication is the duplication of server data from one Perforce Server to another Perforce Server, ideally in real time. You can use replication to:

  • A replica server can function as an up-to-date warm standby system, to be used if the master server fails. Such a replica server requires that both server metadata and versioned files are replicated.
  • Reduce load and downtime on a primary server by Long-running queries and reports, builds, and checkpoints can be run against a replica server, reducing lock contention.
  • Perforce administrators can configure the Perforce Broker to redirect commands to read-only replica servers to balance load efficiently across an arbitrary number of replica servers.


  • For checkpoints and some reporting tasks, only metadata needs to be replicated.
  • For reporting and builds, replica servers will need access to both metadata and versioned files.
  • With the 2010.2 release, the Perforce Server now replication between Perforce servers of both metadata and versioned files.


  • Replication is unidrectional, and replica servers are intended for read-only purposes
  • Bidirectional replication is not supported, because any changes made to a replica server can be overwritten by changes made to the master Perforce server.

System Requirement:

  • All replica servers must be at the same release level as the master server. Prefebalily 2010.2 to use both command (p4 pull and p4 replicate).
  • All replica servers must have the same Unicode setting as the master server.
  • All replica servers must be hosted on a filesystem with the same case-sensitivity behavior as the master server’s filesystem.
  • All replica servers must be hosted on a filesystem with the same case-sensitivity behavior as the master server’s filesystem
  • p4 replicate and p4 pull (when replicating metadata) do not read compressed journals. Therefore, the master server must not compress rotated journals until the replica server has fetched all journal records from older journals
  • The master and replica servers must have the same time zone setting.

Issues 1: The master and replica servers must have the same time zone setting

Today I was just going through P4 replication features with the correspondence of Disaster recovery(Replication), as well as bbalance load efficiently using p4 broker and p4 replica.

We can have cross-geo Disaster recovery(Replication) setup as soon as, we have same time zone setting in both (master and replica) server.  Replica server is unidirectional (read-only) so making same time zone in two difference location would not make any difference since all development activities will be happening though master servers/proxies only.

I learned that if we go replication with cross geo then we will not be able to take advantage of balance load efficiently as follows.

  • We will not be able to take advantage of using replica server to reduce load and downtime on a primary server by Long-running queries, builds, and checkpoints in distributed geo environment.
  • Perforce Broker to redirect commands to read-only replica servers to balance load efficiently across an arbitrary number of replica servers will not be having any advantage due to long distance and command will take more time to process in distributed geo environment.

Issues 2: p4 replicate and p4 pull (when replicating metadata) do not read compressed journals. Therefore, the master server must not compress rotated journals until the replica server has fetched all journal records from older journals

The replication process is designed to have as little latency as possible between the replica and the master; the compression/decompression of the journal
and manipulation of compressed data introduces additional delay and complexity which in turn increases the potential difference between the state of the master and the replica.

To Setup Replication
p4d -r $P4ROOT “-cset replica1#startup.1=p4 pull -i 2”

p4d -r $P4ROOT “-cset replica1#startup.1=p4 pull -u -i 2”

To unset Replication
p4d -r $P4ROOT "-cunset  replica1#startup.1"
To list all server configuration variables, 

use –cshow:

p4d -r $P4ROOT -cshow

This blog work still in progress…Still in Progress…


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

Hybrid testing introduction, What is 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: –

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

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



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.


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.

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


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.


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


• Providing information on the IT infrastructure

o To all other processes

o IT Management

• Enabling control of the infrastructure by monitoring and maintaining information


o All the resources needed to deliver services

o Configuration Item (CI) status and history

o Configuration Item relationships


• 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


• 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


• 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


• 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


• 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


• 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.


• Incident details

• Configuration details

• Defined work-arounds


• 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


• Requests for Change (RfC)


• Forward Schedule of Changes (FSC)


• 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


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


• 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


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


• 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


• 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


• 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


• 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)


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


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.


• 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.


• 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.


• 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


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:


• No Charging – IT treated as support center

• Notional Charging – IT treated as cost center

• Actual Charging


• 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


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


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.


• 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


• 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 : / / / / / / / / / / / / / / /