Academic journal article Issues in Informing Science & Information Technology

Design, Development and Deployment Considerations When Applying Native XML Database Technology to the Programme Management Function of an SME

Academic journal article Issues in Informing Science & Information Technology

Design, Development and Deployment Considerations When Applying Native XML Database Technology to the Programme Management Function of an SME

Article excerpt

Background of the Problem

Readers who have worked for multiple software development organisations are likely to have observed that few use exactly the same mechanism for communicating or controlling information flows between their constituent parts; as such the coherency and effectiveness of the processes as a whole can vary. In some cases these variations can be stark and differences even occur between teams in the same organisation. Unfortunately the precise reasons are beyond the scope of this paper, but in general such fundamental differences as the maturity, size, cultural make-up, and geographical location of the organisation all influence or accentuate the differences. At the nub, is the human factor, where individuals attach varying degrees of usefulness to the processes. Unlike more mature industries such as manufacturing that have managed to converge and streamline many practices, the software industry with its spread across all the other industry verticals, gets pulled in all manner of directions. This is probably because of the different pressures each sector applies and the huge variety of platforms each sector uses to develop their software on (or for). Due to this wide range of variables it is perhaps quite understandable that anomalies exist and persist in the software development arena. However, it would be naive to think that there is one single development process or management mechanism, such as the programme management coordination tool (PMCT) considered here, that would solve the problems.

There are already many established and accredited methods for the management of workflows and business process engineering that would have an impact on the shape of a PMCT, and essentially this goes to the heart of what the investigation was addressing. Using different business processes, widely dispersed and/or ad-hoc tools in any management function immediately opens up the possibility of project failure as information gets lost in translation, or, essential activities disappear down the gaps between. Where materials or products are the end result, the absence of an element can usually be traced by auditing and inventory controls. By the same token the management of software needs to be controlled in the same way, if not tighter in many respects as the potential for a software component to be badly specified or to be implemented incorrectly is huge.

Total Quality Management (TQM) systems and software process improvement (SPI) frameworks such as TickIT (TickIT, 2000), SPICE (Software Process Improvement and Capability Determination) (Software Quality Institute, 1999), CMM (Capability Maturity Model) (Software Engineering Institute, n.d.), etc. are a few of the business processes that have allowed significant strides to be taken by many organisations in pursuit of quality assurance and all of these are already a widely recognised benchmarks for development activities. These and other accredited methods provide adopters with a sound business process or framework in which to develop their own approach towards meeting best practice so individual components do not weaken the quality chain.

Taking into consideration of the above mentioned, the issue of organisational maturity, the flexibility in the interpretation of such a process and often the pressure to short-circuit some step or other to meet a particular software delivery deadline, usually allows enough scope for the framework to be bent out of shape and become ineffective, with project developments lapsing back into a failing spiral. In the authors experience resistance to adoption and where accepted practices exist, such deviations occur frequently. These can and sometimes do lead to the processes only being followed in spirit and not adhered too as they should to be a real benefit. Recognition of this fact is not new, as Humphrey (1998) stated that "a careful examination of failed projects shows that they often fail for non-technical reasons. …

Search by... Author
Show... All Results Primary Sources Peer-reviewed

Oops!

An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.