Tag: Overview
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.
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
Wise Package Studio Overview and its advantage
created the topic: Wise Package Studio Overview and its advantage
Wise Package Studio Overview
[glow=red,2,300]Packaging and Virtualization[/glow]
Take advantage of the benefits of application virtualization by using Wise Package Studio 7 to create packages that configure virtual applications. You can also edit virtual packages using the Virtual Package Editor and manage them using Software Manager.
[glow=red,2,300]Take the Suspense Out of Patching[/glow]
Even “good,” tested patches can pose serious, hidden risks. Ensure your patches and applications are properly packaged, tested and prepared for deployment with Wise Package Studio
[glow=red,2,300]Quality Applications from Start to Finish[/glow]
Your organization relies on hundreds of applications essential for business to function. But are those applications truly prepared for introduction into your environment? Wise Package Studio, the starting point for software management, helps you successfully deploy reliable applications, migrate to .MSI and much more. Using a structured process called enterprise software packaging, Wise Package Studio guides you through application preparation in logical steps supported by exclusive technology.
Enterprise Management Server Manage projects, collaborate across teams and locations, and share project reports over the Web.
Package Analyze installation requirements, repackage or convert to .MSI and customize the application to meet organizational standards.
Conflict Management Manage application conflicts by identifying and resolving conflicts before they cause problems.
Quality Assurance Create a test plan, test in the production environment and validate applications.
Release Management Move finished packages to your distribution system using automated tools.
Wise Software Repository Share information and related resources with a centralized database that stores information about all applications, the standard operating environment (SOE) and related components.
Wise Package Studio Features
Wise pioneered the concept of software packaging and our years of experience show in dozens of technically advanced, industry-leading features only found in Wise Package Studio. With Wise Package Studio, you can easily migrate applications to Windows Installer (.MSI) and much more through exclusive quality assurance tools, project and data management, repackaging, customization, validation, and distribution system integration. In return you receive error-free, high-quality, reliable deployments that cut your packaging efforts by 50%.
Get a jumpstart on Microsoft Windows Vista™
We know that you’re probably starting to plan your migration to Vista. We’ve included the following enhancements to help you get Vista-ready:
* Check for the presence of Windows Vista on target machines
* Compatibility with Internet Explorer 7.0
* Minimize reboots using the Restart Manager Infrastructure in Vista
* Access control for digital signature support
* Validation for Vista logo standards
* Set logging options for the installation
[glow=red,2,300]64-bit support[/glow]
If you develop 64-bit applications, then you’ll need support for 64-bit installations.
Wise Package Studio can:
* Manage the 64-bit portion of the registry and file system
* Author a single .WSI project file that can create separate .MSIs for both the 32-bit and the 64-bit versions of an application
* Use the Release Settings page to specify which components to not install in the 32-bit or 64-bit version of the installation
[glow=red,2,300]Create, Edit, and Manage Packages for Virtual Applications[/glow]
Take advantage of the benefits of virtual applications powered by Altiris Software Virtualization Solution by using Wise Package Studio. Virtual applications eliminate the possibility of conflicts with other applications and the base operating system. You can also instantly activate, deactivate or reset them if corruption or errors occur. Wise Package Studio 7 now supports:
* SetupCapture captures applications into a Virtual Software Archive (.VSA) file. The resulting package will install your captured application into a virtual layer on PCs that are running Altiris Software Virtualization Solution.
* Edit a Virtual Software Archive package using the Virtual Package Editor. Add installation logic to the package to ensure it configures the target system correctly based on the virtual application’s requirements.
* Use Software Manager to import Virtual Software Archive packages into the Wise Software Repository. Manage them just as you would any other package.
[glow=red,2,300]Support for additional package formats[/glow]
Based on your requests, we’ve added support for more package formats. In addition to creating .MSIs and .EXE packages, you can also create packages for the following:
* Packages for virtual applications that support Altiris Software Virtualization Solution.
* New Linux Package Editor lets you create packages for Linux RedHat .RPM packages
* Enhanced Mobile Device Package Editor creates packages for a wide range of mobile devices, including the Windows Mobile .5.0 platform.
Learn more about other new features and enhancements in Version 7.
[glow=red,2,300]Patch Preparation and Testing[/glow]
Take the Suspense out of Patch Management
Now you can easily and quickly prepare patches for error-free deployments with Wise Package Studio, using a four-phase process. With Wise Package Studio you can:
* Quickly assess the impact the patch will have on the production environment
* Create a focused, efficient test plan based on patch impact assessment
* Perform lab-based functional testing and “test fly” the patch in production without risk
* Perform a risk assessment to see if the deployed patch installed as intended, and quickly remedy any problems
[glow=red,2,300]Distributed Computing[/glow]
Multiple packaging teams need fast, easy access to shared files and common packaging tasks. With distributed computing support, enterprise-level use of Wise Package Studio is much faster and efficient because common packaging tasks, such as compiling and importing, are run from the server.
Preflight Deployment
Risk-free “Real-world” Environment with Preflight Deployment
Preflight Deployment is a revolutionary new technology that allows you to determine—before deployment—if an application or patch will succeed or fail by testing it in your real-world environment. With Preflight Deployment, you can see why deployments fail on specific machines without disrupting end users or endangering your production environment. How is this accomplished?
* Preflight instrumentation takes the .MSI package to be tested and creates a “zero touch” package that tests appropriate conditions for the application
* Your existing distribution system is used to push out the package
* The zero touch package simulates the installation on the actual destination machine without making any changes to the machine, and then reports results back to a central server
* Preflight Analysis displays a variety of test reports, from high level analysis to detailed results for specific errors or specific PCs
[glow=red,2,300]Standard Operating Environment[/glow]
Improve Testing and Standardizing by Including the SOE
Now you can include your organization’s standard operating environment (SOE) as a protected entity within the Wise Software Repository. By storing your organization’s core desktop image in the repository, you can check for conflicts against it during the conflict management process. Applications conflicting with the SOE are highlighted, allowing packagers to easily modify the application to ensure conformance with organizational standards.
Wise Package Studio Flexible Solutions
[glow=red,2,300]Flexible Structure, Innovative Technology[/glow]
Wise Package Studio’s flexible, modular structure provides an extensive array of solutions for any organization. From the world’s largest enterprises to single-person packaging teams, Wise Package Studio allows you to purchase the functionality that best suits your organization. Do you want to add Quality Assurance capabilities to your team? It’s easy; just add the Quality Assurance module to Professional Edition. Looking for a way to share resources among teams, but you don’t need Quality Assurance? Simply add Enterprise Management Server to Professional Edition.
Professional Edition
Wise Package Studio Professional Edition is an advanced packaging solution providing core functionality for creating and customizing applications and patches and managing and eliminating application and patch conflicts. Professional Edition provides the starting point for adding extended functionality through the Quality Assurance module and Enterprise Management Server.
[glow=red,2,300]Quality Assurance
[/glow]
Wise Package Studio Quality Assurance provides everything you need to ensure your applications and patches deploy error-free. Quality Assurance provides a structured plan that tests packages in a real-world environment. Effective testing is essential for reducing the risk and impact of introducing new applications and patches into production.
[glow=red,2,300]Enterprise Management Server[/glow]
Wise Package Studio Enterprise Management Server provides a suite of sophisticated project management and collaboration capabilities that allow you to share and manage resources. Whether you manage a single packaging team or numerous teams across the globe, you can now effectively work together and streamline the packaging process.
[glow=red,2,300]Standard Edition[/glow]
Wise Package Studio Standard Edition is a stand-alone packaging tool designed for individuals who prefer an ad hoc approach to packaging. It provides basic packaging and validation functionality, helping organizations quickly and reliably package and migrate applications to the .MSI standard.
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 – 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.
Maven2 Step by Step Guide – Complete Introduction
Setting up the application frame
The Maven2 documentation is silent about how to set up web application skeletons. The standard archetypes allow you to create a simple standalone, a simple web application (no Java code), and a multi-module project. Presumably, the recommended approach to creating a standard web application (JSP and HTML code for the view, and Java code for the Model and Controller layers) is to create a multi-module project containing a single simple web application and one or more standalone applications for the Model and Controller. However, it is possible to make Maven2 work with a standard web application structure by adding some directories to the skeleton created by the standalone Maven archetype.
The Maven2 Getting started Guide has some commands for creating skeletons from standard Maven archetypes. To create the skeleton for an application my-app in the com.mycompany.app namespace using a standalone archetype, run this command:
1 |
$ mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app
|
To make a standard web application skeleton from this, add the following directories. The webapps directories is the root of the web applications context, and contains the WEB-INF directory. The resources subdirectory corresponds to the WEB-INF/classes directory for a web application or the conf/ or etc/ directory for a standalone, where all the properties files go. The test/resources/ directory is useful for storing test specific properties files.
1 2 3 4 |
my-app/src/main/webapps/
my-app/src/main/webapps/WEB-INF/
my-app/src/main/resources/
my-app/src/test/resources/
|
Finally, to make a web application out of the standard standalone application, change the value of project.packaging from jar to war in the pom.xml file.
Standard Maven2 Goals
Maven2 provides some standard goals which are similar to Ant targets found in most project’s build.xml files. This helps people familiar with Ant to make a quick transition to using Maven2. They are as follows:
1 2 3 4 5 6 |
mvn clean - cleans out all Maven2 generated files.
mvn compile - compiles the Java sources
mvn test-compile - compiles the Java JUnit test classes.
mvn test - runs all JUnit tests in the project.
mvn package - builds the JAR or WAR file for the project.
mvn install - installs the JAR or WAR file in the local Maven repository.
|
Most of these goals are configured in the super-POM, but if you want to build your application using Java 1.5 (who doesn’t these days), you will need some additional configuration in your pom.xml, in the project.build.plugins element in your pom.xml.
1 2 3 4 5 6 7 8 9 |
<!-- Java 1.5 compiler plugin -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
|
Generating IDE configuration files
Most people work with some kind of IDE, and the IDE must be told where to look for JAR files, Java code, test code, etc. Since this information is already specified in the pom.xml files, Maven2 can generate the IDE artefacts for a large number of popular IDEs in use, such as Eclipse, IDEA and Emacs JDEE. To generate the Eclipse artefacts for your project, run the following command:
1 |
$ mvn eclipse:eclipse
|
You also need to tell Eclipse where to find the your local Maven2 repository (under ~/.m2/repository by default). You can do this by setting a global environment variable M2_REPO in the IDE.
Running Jetty in place (webapps)
A nice touch is the Maven2 Jetty Plugin. This starts up a Jetty installation in place in your web application. This is a huge time-saver, since web application development is often an iterative cycle of changing code, deploying to application server, checking a web page and back. Having Jetty running on your web application source enables you to see your changes instantly (or after compiling with changes in Java code). To set it up, you will need to add the following configuration in project.build.plugins in your pom.xml file.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty6-plugin</artifactId>
<configuration>
<scanIntervalSeconds>10</scanIntervalSeconds>
</configuration>
<dependencies>
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-j2ee_1.4_spec</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
</plugin>
|
Then start up Jetty with the following command. You should be able to see your web application on your browser at http://localhost:8080/my-app.
1 |
$ mvn jetty6:run
|
Documentation: The project website
I think of documentation as a place to tell the world all about the cool things my project does. However, too many projects skimp on documentation, because of the effort in setting up the infrastructure in place to generate documentation. Maven2 has built in support for generating a project website with all the documentation for your project. Data entered into the pom.xml drives a lot of the reports, such as Mailing List, Issue Management, Source Repository, etc. Maven2 needs to be told which reports to generate in the project.reporting.plugins section of the pom.xml. Details about which pom.xml entries drive which report elements can be found in Resources[2].
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-project-info-reports-plugin</artifactId>
<reportSets>
<reportSet>
<reports>
<report>dependencies</report>
<report>project-team</report>
<report>mailing-list</report>
<report>cim</report>
<report>issue-tracking</report>
<!-- <report>license</report> -->
<report>scm</report>
</reports>
</reportSet>
</reportSets>
</plugin>
|
You can also create project documentation content, such as User Guides, etc, in a variety of formats, such as DocBook and APT (Almost Plain Text). APT is a wiki-like plain text format which I find very convenient. For FAQ entries, Maven2 supports the FML format.
To set up the project site, create the following directories.
1 2 3 4 5 |
my-app/src/site/apt/
my-app/src/site/fml/
my-app/src/site/resources/
my-app/src/site/resources/images/
my-app/src/site/site.xml
|
The apt subdirectory should contain the documentation in APT format. The fml subdirectory contains various FAQ source files. The resources subdirectory should contain files and documents that do not need any pre-processing. The files in the apt and fml subdirectory will be pre-processed by the APT and FML processor and be copied to the project site root directory as .html files. The files in the resources subdirectory (including the images/ subdirectory) will be copied to the project site docroot as is. The site.xml specifies the template for your site, ie what the left and right banners should contain, etc. The site.xml file will reference these HTML files.
To generate the project web site, run the following command. The website will be generated under my-app/target/site where you can view it with a browser using the file:// protocol.
1 |
$ mvn site
|
Javadocs
The Javadocs plugin needs to be configured explicitly in the project pom.xml in the project.reporting.plugins section.
1 2 3 4 5 6 7 8 9 10 11 12 |
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<links>
<link>http://java.sun.com/j2se/1.5.0/docs/api/</link>
<link>http://plexus.codehaus.org/ref/1.0-alpha-9/apidocs</link>
<link>http://jakarta.apache.org/commons/dbcp/apidocs/</link>
... other third party libs used by your project ...
</links>
</configuration>
</plugin>
|
If the Javadocs plugin has been configured, then mvn site will automatically generate the Javadocs. Otherwise, they can be generated separately using the command:
1 |
$ mvn javadoc:javadoc
|
Java Cross Reference (JXR)
Another cool plugin is the Code Cross Reference that is created using the JXR plugin. The project code is made displayable with line numbers and syntax highlighting, with links to related code. Almost like having an IDE running on the browser in read-only mode. Though not required for all projects, this is very useful to allow people to review your code without having to download it. To configure it, configure the plugin in the project.reporting.plugins section.
1 2 3 4 |
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jxr-plugin</artifactId>
</plugin>
|
Like the Javadocs goal, this will be run as part of mvn site as well, but can be run separately using the command:
1 |
mvn jxr:jxr
|
Code Style (Checkstyle)
I chose Checkstyle because I am familiar with it, but I think Maven2 supports other code style checkers too. I use the default Maven code style, since this is likely to become the most popular code style as more and more people embrace Maven2, but this setting can be overriden to use Sun’s code style or some other style preferred by your corporation. To configure it (with default Maven code style), we need the following configuration in project.reporting.plugins in the pom.xml file.
1 2 3 4 5 6 7 |
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<configuration>
<configLocation>config/maven_checks.xml</configLocation>
</configuration>
</plugin>
|
As before, once configured, the report is run as part of the mvn site command, but can be run separately using the command:
1 |
$ mvn checkstyle:checkstyle
|
Unit Test Coverage (Cobertura)
Clover is the most popular tool for checking on Unit test coverage, and Maven2 provides a plugin for that. However, Clover is commercial software and costs money. A free, open-source alternative is Cobertura. Maven2 provides a Cobertura plugin as well. To configure this plugin, add the following XML to project.reporting.plugins section in the pom.xml.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<!--
<executions>
<execution>
<id>clean</id>
<phase>clean</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
-->
</plugin>
|
The plugin can be run manually using the command:
1 |
$ mvn cobertura:cobertura
|
The plugin leaves a cobertura.ser file in the project root directory, which can be removed using mvn clean. There was a suggestion to automate this by creating an executions subelement under the plugin declaration, but I could not get it to work – the parser complained about invalid tags, so I commented it out (in the above XML snippet). If anyone knows what I did wrong, please let me know.
Deploying files to other locations
I dont know much about this, except that it involves using the Maven2 Wagon Plugin. The plugin supports a wide variety of transport formats. I will post more information about this as I find it. If anyone has some information about using Wagon, would appreciate your posting it here or pointing to links with the information.
So thats basically all I have for now. Hopefully, this article will help kickstart Maven2 adoption in your new projects. Personally, I have used Ant for over 6 years now, and I was justifiably sceptical about switching new development to Maven2. However, I have had good success with Maven2 so far, and I am quite impressed with its range of capabilities in terms of integration with other tools and the services it provides to the developer.
Resources
- The Maven 2 POM demystified – I have restructured my template pom.xml according to this article, and it helps a lot in understanding the POM.
- Get the most out of Maven2 site generation – Much useful information about what elements to populate to produce clear Maven2 project reports.
- The Maven2 Schema – Its hard to figure out what element goes where without examples. The XSD is very detailed and provides good information.
- Better Builds with Maven – if you haven’t already downloaded this free e-book, you should. This is the only book I know of which talks about Maven2, so if you are working with Maven2, you should definitely download and read it.
- Maven : A Developer’s Notebook – covers details of the FML format used for generating FAQ entries.
What is Information Technology Infrastructure Library (ITIL) ? – Complete Guide
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
———————————————————————————————————————————-
Introduction to CVS | Know ABout CVS | Quick Start Guide
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.
What is Apache Ant? – Apache ant Overview
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.
Perforce Basic Concepts | Perforce Overview | What is Perforce ?
Perforce Basic
connects to a Perforce server to move files between Perforce depots and yourworkspace, as shown below.
The precise definitions for these Perforce terms are as follows:• depot: a file repository on the Perforce server. It contains all existing versions of all files ever submitted to the server. There can be multiple depots on a single server. Theexamples in this guide show a single depot.• server: the program that executes the commands sent by client programs, maintains depot files, and tracks the state of workspaces.• workspace: folders on the client computer where you work on revisions of files that are managed by Perforce.
Introduction of p4win | p4win Overview | What is p4win?
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.