Risky Business July 15, 2009
Posted by ccollins in Database, Essays, Opinion, Software Engineering.Tags: development, engineering, estimation, project management, risk, risk assessment, software, software project management
3 comments
Project Management Porn
Anecdotally, I had always known that Software Engineers are terrible at estimation. I had never realised exactly how bad we are.
Some rules of thumb which seem to pop up now and again, is to take your engineers best estimates, and double them. Then you’re actually in the ball park.
(more…)
The Life and Times of E-mail. April 10, 2009
Posted by ccollins in Essays, Opinion.Tags: email, spam, technology
add a comment
BBC News reports that a recently published Microsoft study found that more than 97% of email sent is spam. Seeing this, I can’t help but feel that email is becoming a victim of it’s own success. With a signal to noise ratio like this, one as to wonder how long it can be before email becomes ignored as a mainstream communications channel?
Masters Thesis October 19, 2008
Posted by ccollins in Capacity Management, Change Management, Essays, ITIL, Incident Management, Opinion, Problem Management, Software Engineering.add a comment
In this paper we discuss approaches to Incident and Problem management within the context of IT Service Management, and its de facto standard the Information Technology Infrastructure Library (ITIL). We show how the Problem Management process attempts to diagnose problem root causes by applying various analysis techniques to historical incident data.
We propose a new categorisation mechanism. We break the data free from its hierarchical categorisation scheme through the use of a free form tagging system. By allowing all system users to categorise incidents using their own terms, we show that while individuals may differ, the aggregate meta data produced for each incident stabilises.
Further, by the application of PageRank analysis to the relationships between tags and incidents, we hope to show useful and interesting correlations. While these may or may not be indicative of a causal relationship, they are nonetheless, new facts about the system under scrutiny.
We conclude by showing the system shows some merit, assuming a certain set of minimum system requirements. If these requirements can be met, then this approach, can become another tool in the system administrators’ arsenal of system analysis approaches.
Design Patterns June 16, 2008
Posted by ccollins in Essays, Software Engineering.Tags: Design Patterns, Gang of Four, Iterator, Object Oriented Analysis, Object Oriented Design, Software Engineering
add a comment
Introduction to Design Patterns
Within each engineering discipline, engineers have found that when analysing problems, similar types of sub-problems would tend to recur from time to time. Having had experience from previous project work, they knew that a similar solutions to those problems could be reused. This became the basis for design patterns.
(more…)
Unified Process vs Agile Processes June 11, 2008
Posted by ccollins in Essays, Software Engineering.Tags: agile, SDLC, Software Engineering, unified process
3 comments
Introduction to the Unified Process
The traditional view of system implementation is seen as a series of steps toward implementation, covering areas such as analysis, design, construction, documentation, handover, etc. Hay (1997) gives a good undertaking of the traditional approach stating:
A Brief History of XML March 3, 2008
Posted by ccollins in Database, Essays, History, Languages, SOA, Software Engineering, Web Services.Tags: XML
1 comment so far
Evolution of XML
Extensible Markup Languages (XML) history begins with the development of Standardised Generalised Markup Language (SGML) by Charles Goldfarb, along with Ed Mosher and Ray Lorie in the 1970s while working at IBM (Anderson, 2004). SGML despite the name is not a mark-up language in it’s own right, but is a language used to specify mark-up languages. The purpose of SGML was to create vocabularies which could be used to mark up documents with structural tags. It was imagined at the time, that certain machine readable documents should remain machine readable for perhaps decades.
Introduction to the Zachman Framework February 16, 2008
Posted by ccollins in Essays, Software Engineering.Tags: Enterprise Architecture, Zachman Framework
1 comment so far
Traditional Architectural Approaches.
The traditional view of system implementation is seen as a series of steps toward implementation, covering areas such as analysis, design, construction, documentation, handover, etc. Hay (1997) gives a good undertaking of the traditional approach stating:
Many methodologies are organized around the “system development life cycle”, an organization of the steps required to develop systems. This is expressed as consisting of:
- Strategy – The planning of an organization’s overall systems development effort.
- Analysis – The detailed definition of requirements for a particular area of the business.
- Design – The specific application of technology to the requirements defined during analysis.
- Construction – The actual construction of the system.
- Documentation – Preparation of the user manuals, reference manuals, etc. to describe the system.
- Transition – The implementation of the system, so as to make it part of the infrastructure of the organization.
- Production – The ongoing monitoring of the system to ensure that it continues to meet the needs of the organization.
Notice that each of these steps addresses issues of data and function. Data and functions are typically addressed as separate topics, although ideally, they are addressed cooperatively.
Most methodologies portray the system development life cycle in terms approximating these. Some go so far as to give it the acronym “SDLC.” (more…)
Implementing Business Processes December 13, 2007
Posted by ccollins in Essays, How To, ITIL, Software Engineering.Tags: BPR, Business Process Reengineering, How To
6 comments
Introduction to Business Process Engineering
Business Process Engineering (BPR) began life in the early 1990s. Barothy, Peterhans, & Bauknecht (1995) give a good introduction to the state of Business Process Reengineering at the time, stating:
Over the last few years we have observed the emergence of a new field or phenomenon in MIS practice and research: Business Process Reengineering (BPR). Since the publication of Michael Hammer’s article “Reengineering Works: Don’t Automate, Obliterate” in 1990, reengineering became a new and hot “buzzword” in management. Despite a lack of clear understanding organisations of today cling to it as the ultimate panacea in order to realise major improvements in productivity, quality, time and profitability. They also see reengineering as a way to adapt their business to faster changing environment and as a new paradigm in the deployment of information technology (IT). In order to sell services, consulting companies never tire of glorifying success stories like the reengineering of Ford’s accounts payable, or Mutual Benefit Life’s insurance applications process both resulting in “order of magnitude” improvements. But companies also learn the hard way that the radical redesign of business processes, by fundamentally rethinking the way business is done, bears major risks, is a highly complex change task, and may easily end in failure.
Adapting ITIL to Distributed Web Applications December 6, 2007
Posted by ccollins in Capacity Management, Change Management, Distributed Computing, Essays, ITIL, Incident Management, Opinion, Problem Management, Release Management, SOA, Software Engineering, Web Services, middleware.Tags: Capacity Management, Change Management, Distributed Computing, Incident Management, ITIL, middleware, Problem Management, Release Management, SOA, Web Services
12 comments
Introduction to ITIL
The Information Technology Infrastructure Library version 1 (ITIL) was initially published by the Office of Government Commerce in the year 2000. ITIL is a broad framework of best practices which enterprises are using to manage their IT operations. This quickly grew to over 30 volumes within the library, so when ITIL version 2 came to be released a concerted effort to consolidate the processes described into logical sets was attempted. ITIL v3 continues in this vein by consolidating into five core titles:
- Service Strategy
- Service Design
- Service Transition
- Service Operation
- Continual Service Improvement. (more…)
Current Trends in SOA December 6, 2007
Posted by ccollins in Essays, Opinion, Software Engineering.Tags: Distributed Computing, middleware, Mobile Computing, Service Oriented Architecture, SOA, Ubiquitous Computing
add a comment
Introducing Middleware.
In many ways, humans have been integral to the operation of computer networks, since the dawn of the computer age. In the early 1980’s computers had moved beyond governmental, military and research institutions, and were becoming more common among corporations.
At this stage of their evolution, computer applications were stand-alone. The finance applications of the world lived inside mainframes, and interacted with humans via green screen terminals. The order management systems of the world interacted likewise. Humans were the network, as information could only flow between systems through human intermediaries. For example, a clerk would run a report on one system and re-key the results into the other.
Humans being intelligent, could enforce policies on the flow of information. They could decide what information was appropriate to flow between systems, how quickly it should flow, and how the flow should be achieved.
On the other hand, humans, being error prone, caused this flow of information to be slow, laborious and costly. One day while typing yet another report, a clerk dreamed of letting the computers talk to each other directly. Suddenly, the network revolution had begun.
While the idea was sound, the reality of facilitating this was difficult. Henning (2006) notes, that “persuading programs on different machines to talk to each other was a nightmare, especially if different hardware, operating systems, and programming languages were involved: programmers either used sockets and wrote an entire protocol stack themselves or their programs didn’t talk at all”. What was needed was some sort of automated intermediary between systems.
