INTRODUCTION: HACKERS V HUMAN WAVES
The apocryphal image of the software geeky programmer-hacker has tracked that of software engineering from the dawn of computing. The late-night hacker is the anti-thesis of management and control and coexists uneasily with the image of professional engineering. It is noteworthy that hacking culture in software, the valuing of artful hacks and elegant code predates corporate attempts to formalize software design and development in the computer industry with ‘human waves’ of engineer-programmers working on hulking great mainframes (Kidder, 1981, Levy, 2001).Organisational structures and methodologies address the challenge of scaling software production, to cope with the demands of increasing scope and size; from small stand-alone programs to highly complex time sharing distributed systems. The software industry has flourished, establishing growing ecosystems of applications and services that have in turn demanded attempts to structure the software engineering process. Software engineering took as its paradigm, aspirationally at least, manufacturing’s process control model (Buxton and Randell, 1970, Naur and Randell, 1969, Shaw, 1996).
In the earlier discussion I suggested that life cycles were concerned with initiating, developing and concluding high-tech projects by managing time, scope, cost and quality. Design methods and techniques are tools for structuring and carrying out design work, using a particular technology or programming environment for example.
How should we organise and govern operational capabilities for many development projects in the wider organization? The question of scale arises however when the number of projects, products and teams exceeds some point. One response is for an organization to adopt an overarching management framework for governance, to structure its organizational capability (e.g. RUP, ISO9001, CMMI ). Consider the case for a single organization running a number of development projects each of which in may turn employ (potentially) different life cycle models and various design methods as needed even within the same project.
Organizational frameworks like RUP and CMMI, influenced by waterfall/SDLC, have gained acceptance where organizational scale, complexity or relatively static but demanding requirements govern the marketplace, for example in enterprise architectures where an industry model-driven architecture applies (Boehm, 2006).
STRUCTURED PROCESS PERSPECTIVE
Systems for managing software development have remained a topic of sustained interest and critique since the genesis of the burgeoning software industry. From humble origins in linear or staged development models (Boehm, 1988, Brooks Jr., 1995 (1987), Royce, 1970) we now encounter a diverse array of software management methods, systems, lifecycles and frameworks. Software process standards trace their genealogy directly from military standards established to manage defence contractors and their outputs in terms of product quality and documentation. The history and interrelations between these standard approaches is complex, international, political and intertwined, touching as it does on issues of national importance (defence systems software quality), commercial interest (licensing and intellectual property rights), academic and professional integrity (knowledge, identity, workplace organisation, prestige, etc). For a detailed history refer to Sheard's quagmire of standards (Sheard, 2001).
The argument for software design and development projects is usually cast in terms of a crisis; a crisis of codebase growth, of code complexity, of excessive rework, of costly repair programmes, of unmanaged and potentially unmanageable work where milestones and baselines would constantly slip or simply weren’t met. Process frameworks claim to address the challenge by defining the appropriate and necessary management structures for organisational systems supporting software production. Numerous templates and examples of suitable standard operating procedures (SOPs) or practices are offered. Organisations either adopt the standard form or adapt or replace them with their own versions, satisfying their own needs while anticipating that even if adapted the general form and organisation of the process framework remains constant so that the firm can benefit from ‘certification’ to the relevant standard.
The CMM (Capability Maturity Model) and ISO (International Organization for Standardization) series of quality frameworks have emerged as significant determinants in the trend towards framework unity rather than the quagmire of competing standards. The interrelations between the ‘standard’ approaches, for example ITIL, CMMI, RUP, and ISO9001 will be discussed briefly, to explore their shape and intent.
Notes: CMMI is the Capability Maturity Model Integration, TickIT is one of several software focused elaborations of the ISO9001 standard environment for quality management, RUP is the Rational Unified Process which grew out the object oriented move in software development. SEI is the Software Engineering Institute at Carnegie Mellon. RUP is the Rational Unified Process™, a trademark of the Rational Software Corporation. RUP's iconic figure is the humpback diagram: an activity/time representation of well executed projects. These are characterised by these typical curves, in appearance like surfacing humpback whales. A typical entire generic structure for a process framework would include several hundred policy documents, processes and procedures for use by an organisation.
THE CAPABILITY MATURITY MODEL INTEGRATION (CMMI)
The CMM is offered as a solution to the challenges of orderly software design and production. The solution was adopted and claimed proven in the cases of Motorola, Ericsson, the NASA-SEL, HP and Raytheon among others. The intent of the CMM is to force employees to focus on finding design and code faults much earlier in the development process. Evidently the organisations adopting CMM demonstrated the benefits of the process through large reductions in the costs spent re-working software once it had entered the field. The CMM approach also facilitated cost reduction by putatively increasing productivity and improving cost predictability.CMMI (the CMM ‘Integration’) is described as a framework for ‘improving processes for better products’ (CMMI Product Team, 2006). Like ISO9001 the CMMI is an encompassing approach to marshalling and managing the resources of an organisation to attain (even predict) a range of expected results whenever the organisation embarks on a new project (ibid). The CMMI is considered by many to be the software industry’s best hope for a unified, integrative, adaptive, general purpose framework for software and high tech development (Sheard, 2001). CMMI enjoys a high degree of compatibility with other approaches (e.g. ISO), and is inclusive of diverse methods and lifecycles employed in real firms and organisations (Royce, 2002). However the proliferation of different ‘standard’ process models, even within the same family as happened with CMM, confuses and diverts attention from their common goals ‘improving processes for better products’. CMMI’s support (or absence of antagonism) for innovative practice is therefore an important requirement, enabling behaviours and techniques which may be more or less aligned with facets of a governing framework.
THE ARCHITECTURE OF CMMI
At the heart of the CMM’s process maturity framework is the requirement to establish demonstrable behaviour originating in key process areas. Key processes constitute (or define) what process maturity actually is, and key processes (their description and actual practice) are what enables process capability. Process capability is evidenced by process maturity and capability is in turn a predictor for process performance. Refer to CMM's Process Performance Indicators for an overview of the a maturity framework.
CMM levels.
The CMM architecture defines a measure of organisational maturity that could be applied (potentially) to any kind of production environment. Curtis asks CMM users to identify the cost drivers of their software products and operational processes. Self-assessment involves comparing the definitions and requirements of the CMM Architecture against the internal Product Development Process. The self assessment exercise points at which the organization already satisfies the requirements or definitions at levels 1, 2, 3, 4 & 5.
UNDERLYING THEORY OF CMMi
The capability maturity model commences by assuming an organisation to be an unknown quantity, at the very least any organisation may be thought to start in a raw state. At the entry point, Level 1 organisations work in an ad hoc way, inconsistently, using undisciplined processes. The move to level 2 is characterised by management addressing team and project processes. Management imposes discipline and stabilises behaviour by establishing defined processes and tracking outcomes. The next stage (level 3) replicates successful project and team processes throughout the entire organisation. A uniform global infrastructure of systems and subsystems that interface seamlessly to deliver the organisation’s output. The expectation of organisational uniformity is undoubtedly one of the most challenging and complex aspects of any organisational change project but once achieved the focus of level 4 and level 5 transitions then reverses, shifting the focus back to teams again (level 4) and then once more to individuals (level 5).
At the highest level of CMM organisational processes and change control became internalised within each individual, in a real sense they ‘are CMM.’ Trust then increases as all stakeholders recognise the benefits of reduced process variation (fewer failures and project overruns) until eventually everyone takes individual responsibility to continuously improve their own personal process. The CMM approach is not a quick fix; indeed it is neither quick nor can it be simply applied to fix an organisation as if it was a simple recipe for success. Groups and individuals need the time, resources and commitment to invest in developing their own solutions to the problems they face.
The CMM architecture is a typology of organisational caricatures, from the remedial clustered at level 1 through the most refined at level 5. Any organisation may exhibit features from all levels, for example, an overall level 1 organisation may still evince genuine attempts to introduce level 4 and 5 processes and behaviour. However in the main the CMM levels are presented as a developmental path; organisations evolve from level 1 to 5 with the benefit of management vision and commitment.
Criticisms of CMM assessment point to its very generality and comprehensiveness which may confuse its users. The situation is complicated further if the user organisation is involved in software production internally, while configuring and using externally supplied software and services. Promoters of the CMM approach take pains to contrast it and prove its superiority against other Software Process Improvement (SPI) systems including IDEAL, ISO9000-3, ISO-SPICE. It is notable unfortunately that CMM, as with other SPI change programmes, is costly in terms of resource and focus, and further that SPIs often fail to fully achieve their objectives. SPI adoption is never a simple application of a particular suite of documented systems and formalised interaction.
RUP Project Flow: The emblematic image of the RUP is the ‘humpback whale’ diagram, a representation of activity effort and transition over the entire lifetime of a product from development and delivery through to the maintenance process.
RUP Project of Projects: The RUP employs the idea of four main phases (inception, elaboration, construction and transition) each of which can be subdivided into a number of iterations (e.g. construction #1, construction #2, …). Evidence of progress can be measured for a project in terms of information sets which are delivered in each phase and accumulate over the entire lifetime of the project.
RUP Information Sets: The RUP Project Model is based on iterations. Each iteration is a time-box made up of different coordinated activities that begin with agreed inputs and end with the delivery of a range of outputs that resolve or address all inputs. The combined outputs comprise a product release. As the iteration progresses the project builds up a fuller set of documentation or ‘information sets’ that describe and control the product.
In a sense the product release is the information set a set of artifacts, artifacts that are not wholly defined as the software but does eventually include the software itself.
UNPACKING THE PHASE/ITERATION
At the most granular level the work of an iteration encapsulates the core activities of the SDLC. The business activities carried out in each phase are distinctive and can be characterized loosely as: planning and requirements for inception; design and coding for elaboration; design, coding and test for construction; deployment and coding for transition. Iterations can be thought of as miniature waterfall development models and a phase may be made up of many iterations. The conclusion of each phase is determined when “the defined objectives have been met, the defined artefacts have been completed and the various models have been updated.” (Rational Software Corporation, 1999) The major elements of the entire Rational Unified Process include a range of document types (requirements, designs, plans etc.).
CHALLENGES OF THE RUP
RUP phases are in turn somewhat like a larger aggregate waterfall model but like Boehm’s spiral model of software development (Boehm, 1988) the RUP provides for numerous check points and milestones against which the progress of product development can be assessed.
The RUP was always developed as a commercial package to be used with Rational Software Corporation’s supporting software design and management tool suite. The implication is that the full benefits of the approach occur when using the full Rational Enterprise Suite of products.
PDCA learning cycle of an ISO9001 Quality Management System: ISO 9001’s PDCA approach is employed to enable organisational action, it is ISO9001's central metaphor for engaging in a process of managing organisational performance. PDCA is a cycle of analysis, decision-making, actions, and verification through feedback. The Plan-Do-Check-Act (PDCA) cycle represents the underlying 'theory' for ISO’s perspective on production and in this case software quality systems.
The plan-do-check-act (PDCA) cycle was popularised in the quality industry by W. Edwards Deming. PDCA establishes an imperative to monitor and so surveillance becomes characteristic of its on-going cyclic activities of continual process performance improvement. ISO9001 is likened to a generic organisational template that must be tailored to accommodate the specific circumstances of an industry and firm. Various QMS offerings conform with ISO9001, for example TickIT is a specialised variant of the core ISO standard; produced by the UK Board of Trade to address the field of software development. In this case prior compliance with the ISO standard is a necessary precursor stage to employing TickIT. Adoption of the 'Deming Cycle' as it has become known, is claimed to lead towards a 'Deming chain reaction', a cascading effect where improving quality improves productivity and decreases costs, after which market dynamics lead to decreasing prices. Increasing market size is followed by growth in the firm’s business thus producing exceptional returns on investment.
UNDERLYING THEORY OF CMMi
The capability maturity model commences by assuming an organisation to be an unknown quantity, at the very least any organisation may be thought to start in a raw state. At the entry point, Level 1 organisations work in an ad hoc way, inconsistently, using undisciplined processes. The move to level 2 is characterised by management addressing team and project processes. Management imposes discipline and stabilises behaviour by establishing defined processes and tracking outcomes. The next stage (level 3) replicates successful project and team processes throughout the entire organisation. A uniform global infrastructure of systems and subsystems that interface seamlessly to deliver the organisation’s output. The expectation of organisational uniformity is undoubtedly one of the most challenging and complex aspects of any organisational change project but once achieved the focus of level 4 and level 5 transitions then reverses, shifting the focus back to teams again (level 4) and then once more to individuals (level 5).
At the highest level of CMM organisational processes and change control became internalised within each individual, in a real sense they ‘are CMM.’ Trust then increases as all stakeholders recognise the benefits of reduced process variation (fewer failures and project overruns) until eventually everyone takes individual responsibility to continuously improve their own personal process. The CMM approach is not a quick fix; indeed it is neither quick nor can it be simply applied to fix an organisation as if it was a simple recipe for success. Groups and individuals need the time, resources and commitment to invest in developing their own solutions to the problems they face.
The CMM architecture is a typology of organisational caricatures, from the remedial clustered at level 1 through the most refined at level 5. Any organisation may exhibit features from all levels, for example, an overall level 1 organisation may still evince genuine attempts to introduce level 4 and 5 processes and behaviour. However in the main the CMM levels are presented as a developmental path; organisations evolve from level 1 to 5 with the benefit of management vision and commitment.
Criticisms of CMM assessment point to its very generality and comprehensiveness which may confuse its users. The situation is complicated further if the user organisation is involved in software production internally, while configuring and using externally supplied software and services. Promoters of the CMM approach take pains to contrast it and prove its superiority against other Software Process Improvement (SPI) systems including IDEAL, ISO9000-3, ISO-SPICE. It is notable unfortunately that CMM, as with other SPI change programmes, is costly in terms of resource and focus, and further that SPIs often fail to fully achieve their objectives. SPI adoption is never a simple application of a particular suite of documented systems and formalised interaction.
THE RATIONAL UNIFIED PROCESS
The following presents an overview of the Rational Unified Process™ (RUP) (Rational Software Corporation, 1999, Rational Software Corporation, 1998). The RUP has been hugely successful in large-scale firms (e.g. Ericsson, IBM) where the use of RUP style systems and processes has been a key success factor in bringing complex IT production systems under control. RUP compliments a suite of software tools Rational’s ClearCase, Purify, and Coverage so the adoption of RUP can leverage benefits from these ‘best in class’ tools to support organisational goals.RUP Project Flow: The emblematic image of the RUP is the ‘humpback whale’ diagram, a representation of activity effort and transition over the entire lifetime of a product from development and delivery through to the maintenance process.
RUP Project of Projects: The RUP employs the idea of four main phases (inception, elaboration, construction and transition) each of which can be subdivided into a number of iterations (e.g. construction #1, construction #2, …). Evidence of progress can be measured for a project in terms of information sets which are delivered in each phase and accumulate over the entire lifetime of the project.
RUP Information Sets: The RUP Project Model is based on iterations. Each iteration is a time-box made up of different coordinated activities that begin with agreed inputs and end with the delivery of a range of outputs that resolve or address all inputs. The combined outputs comprise a product release. As the iteration progresses the project builds up a fuller set of documentation or ‘information sets’ that describe and control the product.
In a sense the product release is the information set a set of artifacts, artifacts that are not wholly defined as the software but does eventually include the software itself.
UNPACKING THE PHASE/ITERATION
At the most granular level the work of an iteration encapsulates the core activities of the SDLC. The business activities carried out in each phase are distinctive and can be characterized loosely as: planning and requirements for inception; design and coding for elaboration; design, coding and test for construction; deployment and coding for transition. Iterations can be thought of as miniature waterfall development models and a phase may be made up of many iterations. The conclusion of each phase is determined when “the defined objectives have been met, the defined artefacts have been completed and the various models have been updated.” (Rational Software Corporation, 1999) The major elements of the entire Rational Unified Process include a range of document types (requirements, designs, plans etc.).
CHALLENGES OF THE RUP
RUP phases are in turn somewhat like a larger aggregate waterfall model but like Boehm’s spiral model of software development (Boehm, 1988) the RUP provides for numerous check points and milestones against which the progress of product development can be assessed.
The RUP was always developed as a commercial package to be used with Rational Software Corporation’s supporting software design and management tool suite. The implication is that the full benefits of the approach occur when using the full Rational Enterprise Suite of products.
Overall, the RUP is an approach to risk minimising software product develop, delivery and maintenance. It is a flexible yet rigorous way to plan, staff, design, develop, test and release software in uncertain or challenging commercial environments. One of the RUP's limitations is that its full benefits seem only to be available with the proprietary offering; when the organisation employs the complete set of commercial tools, methodologies and processes provided in the Rational Enterprise Suite of products. Like the CMMI, the RUP is proprietary and essentially closed to all but the largest organisations who are prepared to invest significant resources in their adoption and further development. |
THE ISO 9001 PROCESS MODEL
The ISO 9001 quality management system (ISO, 2005) is another internationally recognised framework for managing and improving an organisation’s standard operating procedures (SOPs). It is an open-ended approach applied in industries as diverse as healthcare, food manufacturing, logistics and software development. The system achieves two goals; capturing an organisation’s processes or SOPs through formal documentation, and establishing a process for refining both those processes and the ‘process of managing the processes.PDCA learning cycle of an ISO9001 Quality Management System: ISO 9001’s PDCA approach is employed to enable organisational action, it is ISO9001's central metaphor for engaging in a process of managing organisational performance. PDCA is a cycle of analysis, decision-making, actions, and verification through feedback. The Plan-Do-Check-Act (PDCA) cycle represents the underlying 'theory' for ISO’s perspective on production and in this case software quality systems.
The plan-do-check-act (PDCA) cycle was popularised in the quality industry by W. Edwards Deming. PDCA establishes an imperative to monitor and so surveillance becomes characteristic of its on-going cyclic activities of continual process performance improvement. ISO9001 is likened to a generic organisational template that must be tailored to accommodate the specific circumstances of an industry and firm. Various QMS offerings conform with ISO9001, for example TickIT is a specialised variant of the core ISO standard; produced by the UK Board of Trade to address the field of software development. In this case prior compliance with the ISO standard is a necessary precursor stage to employing TickIT. Adoption of the 'Deming Cycle' as it has become known, is claimed to lead towards a 'Deming chain reaction', a cascading effect where improving quality improves productivity and decreases costs, after which market dynamics lead to decreasing prices. Increasing market size is followed by growth in the firm’s business thus producing exceptional returns on investment.
EXAMPLE:SPI initiatives are fraught, uncertain and risky projects. SPI is above all a 'cultural discipline'. Transforming organisational culture requires strong leadership, management and employee buy-in, the understanding of customers, time to learn from mistakes and the determination to persist. Organisational change involves tranformation of the inside of the organisation, its outputs and interactions with the outside world.
ISO9001 For Success in Software Development and Support (FSSDS) - (Sanders and Curran, 1994)
Let’s look at one ISO 9001 compliant framework for software development, developed by the Centre for Software Engineering at Dublin City University (Sanders and Curran, 1994). This is an approach that can enable successful compliance with the ISO 9001-3 standard; the precursors to ISO 9001:2000 which combined ISO 9001:1994, ISO 9002:1994, and ISO 9003:1994. Software Process Improvement (SPI) initiatives challenge an As-IS situation in terms of the costs of poor quality product (high defects, poor feature matches, excessive effort spent fixing and maintaining etc). SPI initiatives offer a remedy in the form of best practice, concrete processes and procedures. The FSSDS approach comes with a full suite of document templates for planning, design, reports, and procedures. In addition the FSSDS provides a listing of clearly documented key practices and relates them to associated policy, process or procedure documents (The entire generic structure includes 276 policies, processes and procedures for use by an organisation.) Finally the whole framework is cross-referenced against the relevant sections of ISO 9001 demonstrating that the FSSDS satisfies the requirements of ISO 9001 QMSs.
The stage-gate life cycle element: The FSSDS was designed to address the distinctive environment for software development and maintenance by emphasizing early defect detection and prevention. It attains this by institutionalising gating on all activity transitions. Each phase of the lifecycle is modeled on an input-output system. In essence, the stage-gate mechanism reverts the organisation of software development to a traditional waterfall/SDLC style where each project enters and transitions between separate phases over the project lifetime.
ISO style culture change model for introducing a QMS: The FSSDS approach to implementing an ISO9001 compliant quality management system (QMS) for software development and maintenance is predicated on two main aspects: a carefully managed cultural change programme, and clear control of the inputs and outputs of defined lifecycle activities
The cultural change programme employs the PDCA model directly and the key to a successful cultural change programme is the clear demonstration of managerial leadership with top management buy-in. Introduction of SPI process change is managed through the establishment of an SPI committee. This group becomes responsible for developing, implementing, reviewing and evaluating the structures and systems of the QMS (e.g. policies, processes & procedures). Once commenced the quality programme should become self-sustaining as evidenced by regular internal audits, management reviews and incremental (documented) improvements of technical aspects of the QMS itself.
