• HTML
• CSS

When Your Start JavaScript then before should requiring knowledge of HTML & CSS. After that, you can use JavaScript.

What is JavaScript ?

JavaScript is the programming language of HTML and the Web. It makes web page dynamic. It is an interpreted programming language with object-oriented capabilities

JavaScript History

1995 by Brendan Eich (NetScape)
• Mocha
• LiveScript
• JavaScript
• ECMAScript

Tools

Where You use Javascript means editor

• Notepad
• Notepad ++
• Any Text Editor

JavaScript and Java Same?

The post An introduction to JavaScript Programming Language. appeared first on scmGalaxy.

HTML provides a way of displaying Web pages with text and images or multimedia content. HTML is not a programming language, but a markup language. An HTML file is a text file containing small markup tags. The markup tags tell the Web browser, such as Mozila Firefox or Google Chrome, how to display the page. An HTML file must have an htm or html file extension. HTML stands for HyperText Markup Language.

HTML pages are of two types:

Static Pages – Static pages, as the name indicates, comprise static content (text or images). So you can only see the contents of a web page without being able to have any interaction with it.

Dynamic Pages – Dynamic pages are those where the content of the web page depend on user input. So interaction with the user is required in order to display the web page. For example, consider a web page which requires a number to be entered from the user in order to find out if it is even or odd. When the user enters the number and clicks on the appropriate button, the number is sent to the web server, which in turn returns the result to the user in an HTML page.

The post An Introduction To HTML. How many types of pages in html? appeared first on scmGalaxy.

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.

The post Introduction of Apache Ant appeared first on scmGalaxy.

The post Continuous Delivery appeared first on scmGalaxy.

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

BROAD DEFINITION: 
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.

Specification

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

Reference: http://en.wikipedia.org/wiki/Agile_software_development

The post Agile Software Development Methodology appeared first on scmGalaxy.

• 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

• 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

• 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

• Introduction
• Build Process Templates
• Demo: Hello World
• Demo: Execution Scope
• Demo: Build Script Arguments
• Demo: Build Script Variables
• Demo: InvokeProcess Activity
  Summary

• Introduction
• Overview
• Build Automation in TFS 2008
• Demo: Using the Upgrade Script4
• Demo: Calling MSBuild from 2010 Build3
• Demo: Custom MSBuild Tasks4
• Summary

The post Introducing Team Foundation Build 2010 | TFS 2010 Training appeared first on scmGalaxy.

• 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

• 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

• 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

• 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

• 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

• 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

• 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

The post Software Development with Team Foundation Server 2015 appeared first on scmGalaxy.

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 – http://www.microsoft.com/en-us/download/confirmation.aspx?id=17657

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 – http://www.windowsnetworking.com/articles-tutorials/windows-2003/Windows-Server-2003-Resource-Kit.html

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

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

The post Introduction of Windows Internal | Windows Internal Overview | Windows Internal Quick Guide appeared first on scmGalaxy.

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

The post Different Perforce Tools and Their Short Summary | Know About Different Perforce tools appeared first on scmGalaxy.

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.

NOTES:

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

Limitation:

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

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

But
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…

Reference

http://www.perforce.com/perforce/r10.2/manuals/p4sag/10_replication.html
http://www.perforce.com/perforce/doc.current/manuals/cmdref/pull.html
http://www.perforce.com/perforce/doc.current/manuals/cmdref/configure.html#1040665
http://www.perforce.com/perforce/doc.current/manuals/cmdref/replicate.html#1046521
http://kb.perforce.com/article/1099
http://kb.perforce.com/article/1352/accessing-server-configuration-variables
http://kb.perforce.com/article/1099
http://www.perforce.com/perforce/r10.2/manuals/p4sag/10_replication.html

The post Perforce Replication – What is Perforce Replication ? appeared first on scmGalaxy.

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

The post Hybrid testing introduction, What is Hybrid testing? appeared first on scmGalaxy.

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

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

The post What is Information Technology Infrastructure Library (ITIL) ? – Complete Guide appeared first on scmGalaxy.

Power Point PPT: Introduction To Software Configuration Management

The post Power Point PPT: Introduction To Software Configuration Management appeared first on scmGalaxy.

Introduction of RFT(Rational Functional Testing)

Functional Tester is available in two integrated development environments and two scripting languages.
Functional Tester, Java Scripting uses the Java language and the IBM® Rational® Software Delivery Platform.
Functional Tester, VB.NET Scripting uses the VB.NET language and the Microsoft® Visual Studio .NET development environment.
Use Functional Tester to:

• Perform full functional testing. Record and play back scripts that navigate through your application and test the state of objects through verification points.
• Create and edit simple and easy-to-read, object-oriented test scripts. In addition to automatically recording test scripts, Functional Tester contains wizards for generating code, for example, for automatically creating a verification point. Functional Tester’s test scripts are implemented in your choice of Java or VB.NET.

Object Based Testing
The object-oriented recording technology in Functional Tester lets you generate scripts quickly by recording applications against the application-under-test. Functional Tester uses object-oriented technology to identify objects by their internal object properties, not by screen coordinates. If the location or text of an object changes, Functional Tester can still find it on playback.
The object testing technology in Functional Tester enables you to test any object in the application-under-test, including the object’s properties and data. You can test objects in Java, VB.NET, Windows®, and Web-based applications, whether they are visible or hidden in the interface.
When you record a script, Functional Tester automatically creates a test object map for the application-under-test. The Functional Tester test object map lists the test objects available in the application, whether they are currently displayed or not. You can also create a new test object map, either by pasing it on an existing map or by adding objects as required. The object map provides a quick way to add objects to a script. Since the test object map contains recognition properties for each object, you can easily update the recognition information in one central location. Any scripts that use this test object map also share the updated information.

Verification points
During recording you can insert verification points into the script to confirm the state of an object across builds of the application-under-test. The verification point captures object information (based on the type of verification point) and stores it in a baseline data file. The information in this file becomes the baseline of the expected state of the object during subsequent builds. Functional Tester has an object properties verification point and five data verification points (menu hierarchy, table, text, tree hierarchy, and list). You can use the Verification Point Comparator to analyze differences across builds and update the baseline file.

Platform-independent
Functional Tester features platform-independent and browser-independent test playback. For example, you can record a script on Windows and play it back on Linux®. You can record a script using Firefox, Mozilla, Internet Explorer or Netscape. Because the script contains no references to the browser used during recording, you can play back the script using any of the supported versions of Firefox, Mozilla, Internet Explorer or Netscape.

Integrated with Rational TestManager
Functional Tester is integrated with Rational TestManager, which enables you to record and play back a Functional Tester script from TestManager and make use of TestManager features, such as the Log. If you have TestManager installed, you can use these integrated features. See Understanding Functional Tester integrations for information.

Integrated with Rational ClearQuest
Functional Tester is also integrated with Rational ClearQuest® Test Manager, which enables you to play back a functional test script from ClearQuest TestManager, generate logs, and track defects. If you have ClearQuest Test Manager installed, you can use these integrated features.

The post Introduction of RFT(Rational Functional Testing) appeared first on scmGalaxy.

Introduction to CVS

CVS is a version control system, an important component of Source Configuration Management (SCM). Using it, you can record the history of sources files, and documents. It fills a similar role to the free software RCS, PRCS, and Aegis packages.
CVS is a production quality system in wide use around the world, including many free software projects.
While CVS stores individual file history in the same format as RCS, it offers the following significant advantages over RCS:

• It can run scripts which you can supply to log CVS operations or enforce site-specific polices.
• Client/server CVS enables developers scattered by geography or slow modems to function as a single team. The version history is stored on a single central server and the client machines have a copy of all the files that the developers are working on. Therefore, the network between the client and the server must be up to perform CVS operations (such as checkins or updates) but need not be up to edit or manipulate the current versions of the files. Clients can perform all the same operations which are available locally.
• In cases where several developers or teams want to each maintain their own version of the files, because of geography and/or policy, CVS’s vendor branches can import a version from another team (even if they don’t use CVS), and then CVS can merge the changes from the vendor branch with the latest files if that is what is desired.
• Unreserved checkouts, allowing more than one developer to work on the same files at the same time.
• CVS provides a flexible modules database that provides a symbolic mapping of names to components of a larger software distribution. It applies names to collections of directories and files. A single command can manipulate the entire collection.
• CVS servers run on most unix variants, and clients for Windows NT/95, OS/2 and VMS are also available. CVS will also operate in what is sometimes called server mode against local repositories on Windows 95/NT.

The post Introduction to CVS | Know ABout CVS | Quick Start Guide appeared first on scmGalaxy.

What is an apache ant?
Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make’s wrinkles.

Why another build tool when there is already make, gnumake, nmake, jam, and others?
Because all those tools have limitations that Ant’s original author couldn’t live with when developing software across multiple platforms.
Make-like tools are inherently shell-based — they evaluate a set of dependencies, and then execute commands not unlike what you would issue in a shell. This means that you can easily extend these tools by using or writing any program for the OS that you are working on. However, this also means that you limit yourself to the OS, or at least the OS type such as UNIX, that you are working on.
Makefiles are inherently evil as well. Anybody who has worked on them for any time has run into the dreaded tab problem. “Is my command not executing because I have a space in front of my tab!!!” said the original author of Ant way too many times.
Tools like Jam took care of this to a great degree, but still have yet another format to use and remember.
Ant is different. Instead of a model where it is extended with shell-based commands, Ant is extended using Java classes. Instead of writing shell commands, the configuration files are XML-based, calling out a target tree where various tasks get executed. Each task is run by an object that implements a particular Task interface.
Granted, this removes some of the expressive power that is inherent by being able to construct a shell command such as `find . -name foo -exec rm {}`, but it gives you the ability to be cross platform — to work anywhere and everywhere. And hey, if you really need to execute a shell command, Ant has an task that allows different commands to be executed based on the OS that it is executing on.

The post What is Apache Ant? – Apache ant Overview appeared first on scmGalaxy.

P4Win is a Windows-Explorer-style program that helps you manage files that are stored in the Perforce software configuration management system. Using P4Win, you can view files, check them in and out, compare them, and handle conflicts that arise in team development settings. P4Win is highly configurable, and you can add custom tools to the P4Win menu to perform specialized tasks.This guide helps you get started with P4Win, and tells you how to perform the basic tasks you’re likely to want to do on the first day you start working with P4Win. For details about using P4Win, refer to its online help system: from the P4Win Help menu, choose the Help Topics menu item, or press the F1 key.

The post Introduction of p4win | p4win Overview | What is p4win? appeared first on scmGalaxy.