New Entrepreneur-in-Residence at UCD

Majella Murphy has taken up the Entrepreneur-in-Residence role for 2015-2016 at UCD's Michael Smurfit Graduate School of Business. Her role is to support all students with an interest in Innovation and Entrepreneurship, whether considering entrepreneurship as a career path, if working on a new business idea, or to research entrepreneurship in Ireland and Dublin particularly.
Drop in times (Room S209a) Monday mornings 9am-12.30pm or by appointment (majella.murphy@ucd.ie or 01-716 8819).

Majella will be organising a series of events including entrepreneurial journey talks, panel discussions on controversial topics, an entrepreneurship competition and an ecosystem open evening.

When would you expect creativity to occur in a project?

Q: When would you expect creativity to occur in a project?
The class provided different responses, captured in these archetypal timelines...

Seminar: "Outsourcing: cases and harnessing disruptive technology"

"Outsourcing: cases and harnessing disruptive technology".

Open invitation, all welcome.

Peter Smyth discusses sourcing theory and practice from the perspective of a services development and delivery firm. Presenting cases and the impact of harnessing disruptive technology; the implications of cloud for sourcing suppliers and clients. Followed by questions and discussion.

When/where: Wed 25th November 5-6pm in lecture theatre C302, UCD Smurfit.

Peter Smyth is Head of Managed Services, Version1. Version1 was established in Dublin, Ireland in 1996 by CEO Justin Keating and John Mullen. It has grown through organic growth and strategic acquisition to be a market leader in IT services in the UK and Ireland. - See more at: http://www.version1.com/About-Version-1/History

Version1, a Dublin native. (image source www.Version1.com)

UCD CITO, a seminar by Gitte Tjørnehøj. From Claudio Ciborra's "Drift" to "managing drifting digital development"

Open invitation, all welcome. A seminar by Gitte Tjørnehøj. From Ciborra's "Drift" to "managing drifting digital development" Tue 4pm MH201 UCD Smurfit

"Drift in practice - or how to manage drifting digital development"

When: Tuesday 24 November, 4-5pm (click here to download the event in iCal format)

Where: Room MH201, UCD Michael Smurfit Graduate School of Business, Blackrock.

Abstract

Practitioners and researchers agree that we have to change our way of managing technology in organisations and the development of technology itself – but few offer answers that depart from the overarching rational paradigms of the past. Taking inspiration from Ciborra’s approach we direct our attention away from organisational frameworks and structure, and focus instead on learning from those who 'do' - through happenings and artful coping in practice. We suggest that there is much yet to learn by studying improvisation and coping in action.

This talk gives an example of research into improvisational practice in a small IT firm as they strive to implement CMMI (one of these overarching frameworks). We analyse instances, when and how they improvised, and how they learnt from these occasions. This is not a success story but just an ordinary "day at work" with some successes and some failures.

The cover of Ciborra's "The Labyrinths of Information" (2002)

References:

The Labyrinths of Information: Challenging the Wisdom of Systems, Claudio Ciborra (2002)

From Control to Drift: The Dynamics of Corporate Information Infrastructures, Claudio Ciborra (2001)

About the speaker:
Gitte Tjørnehøj is an assistant professor in Information Systems Management and Programme Director for the Masters in IT Management at Aalborg University (Denmark). Gitte researches socio-material innovation, IT enabled innovation, distributed systems development, software processes, and project management.

How to get to the seminar:
A Google maps reference with room location and suggested parking zones.
https://www.google.com/maps/d/u/0/edit?mid=zI3tiisSQK_k.kqOUvhH4ARXE

Monument Valley, inside view

Making money from an App. The inside view, monument-valley-in-numbers. The peaks are nice but nicer still the (very) long tails. http://ow.ly/HKpDa 

Source: http://blog.monumentvalleygame.com/blog/2015/1/15/monument-valley-in-numbers

Leaders of Tomorrow competition 2015 open for applications...

Leaders of Tomorrow competition now open (p.s. UCD Smurfit MSc Digital Innovation / iBusiness - Innovation through ICT students won 2014)

See www.accenture.com (image source montage from Accenture)

The Leaders of Tomorrow competition is hosted and sponsored by Accenture, the NDRC and the Irish Times. 

2nd December 2015 - Applications Deadline
See https://www.accenture.com/ie-en/Careers/leaders-of-tomorrow-award.aspx

NDRC Catalyser Open Evening

NDRC Catalyser is an early stage startup investment programme. They are hosting an Open Evening in the NDRC on Monday, 9 November 2015 from 18:00 to 19:30.

www.ndrc.ie (link)

The NDRC is located in The Digital Hub, Crane Street, near the Guinness Storehouse complex at St. James's Gate, Dublin 8.

Cohn stirs the Estimation pot again...

Mike Cohn, the author of Agile Estimation, writes that, much of the time, his teams don't actually need to estimate at all. Huh?
Well, read through the piece, see if you get where he is coming from on this point. Would you go along with him?

[image of a mountain goat from Mountain Goat Software]

See Cohn's blog at www.mountaingoatsoftware.com (link).

Phase 2 of the DIT Hothouse / IADT Media Cube New Frontiers programme is now open for applicants

The New Frontiers Programme is aimed at supporting the establishment and growth of technology or knowledge intensive ventures that have the potential to trade internationally and create employment in Ireland. DIT Hothouse deliver the 3-phased programme in partnership with IADT.

Phase 1 lasts approximately two months and is part-time in nature – typically entailing two evening sessions per week. The programme facilitators will introduce the group to relevant startup strategies, challenge each participant’s business idea and encourage participants to prove some degree of market validation of their proposed product or service.

Phase 2 includes funding support for each participant, subject to assessment of performance and progress. Phase 2 participants, who must be working full-time on their venture, engage in a series of interactive workshops addressing all aspects of the startup process.

Phase 3 is a full-time period of flexible support, helping successful participants towards investment and expansion. Participants have access to hotdesk space within the DIT Hothouse incubation centre during Phase 3.

Phase 2 of the programme is now open for applications.

Link to application site/form

IADT's "Blue Cube"

@MediaCubeIADT @DITHothouse @InventDCU #StartupProgrammes #EI_NewFrontiers #Hothouse #StartupIreland #StartupDublin

Thinking about starting up a venture?

Step 1.
Read through and apply if possible the steps in Cowan's book.

Step 2.
Look for external supports. The following are currently taking place and may drive, inspire and motivate you to progress your business idea...

• The Leaders of Tomorrow competition is hosted and sponsored by Accenture, the NDRC and the Irish Times. The competition is now open for entries. 
• https://www.accenture.com/ie-en/Careers/leaders-of-tomorrow-award.aspx

• NDRC Catalyser is an early stage investment programme. They are hosting an Open Evening in the NDRC on Monday, 9 November 2015 from 18:00 to 19:30.
• http://bit.ly/1RdPzlz

• UCD Innovation have a programme for startups, they focus on undergraduate and postgraduate proposals.
• http://www.ucd.ie/innovation/students/ucdstartupstars/

• UCD Innovation's main site includes a wealth of related information.
• http://www.ucd.ie/innovation/

• Other institutions in Dublin have similar inclusive programmes. Former colleagues of mine have been through and strongly recommend the DIT Hothouse / IADT Media Cube New Frontiers programme.  
• http://www.dit.ie/hothouse/startinganewbusiness/hothousestart-upincubationcentre/

• Phase 2 of the DIT Hothouse / IADT Media Cube New Frontiers programme is now open for applicants
• http://bit.ly/1p7H0vO

• Enterprise Ireland also hosts the New Frontiers Entrepreneur Development Programme
• http://bit.ly/19ypK9c

Accenture Digi-Workshop and Guest Lecture

Vicky Godolphin, Head of Digital, Accenture Ireland, presented the guest lecture Tuesday (27 Oct) from 5-6pm in room MH201, Blackrock.

Handover to Vicky Godolphin on Design Led Change #accenturegrads @Accenture_Irl 

"design thinking is central to shaping customer and user experience"

Another version of Damian Newman's design squiggle

And the "Design Wiggle"?

Vicky suggested to follow up: Fjord's era of living services "liquid customer expectations"…

Vicky's talk addressed projects Accenture is involved with in the Digital space, focusing in particular on the concern and need for ID/UX/UI in digital systems (ID is 'interaction design', UX is 'user experience', and UI 'user interface')

From 4-5pm Accenture presented graduate recruitment opportunities and meet with interested students.

Conor on the industries Accenture concentrate on and A's specialisms

Declan's journey; career paths, flexibility and growth within the organisation

@ucddi for Digital Innovation

As part of the newly changed programme title, MSc Digital Innovation, we will use the @ucddi Twitter account for items of public interest and mindshare for the student body.

Do please @ucddi for items on your own Twitter feed you think would be of interest to Digital Innovation.

Embrace Change !?$!

Software professionals involved in the development and delivery of business critical systems are increasingly referring to Agile methods to describe a rigorous process centric suite of practices optimised for adapting to uncertain or changing business needs. The term "extreme programming" was coined and popularised by Kent Beck in the late 1990s to characterise an apposite (and opposite) approach to writing software. IT describes a radical departure in our understanding of how to organise software engineering (Beck, 1999). The 'turn to agility' followed extreme programming as a broad umbrella label for Kent's XP and other approaches that took on this contrary mantel of refocusing software developers back on towards the core values and practices of computer programming in all its many forms (Kruchten, 2007).

Figure: Tracking the rise of popularity of the use of the terms "Extreme Programming" and "Agile Development".

How much of this is hype and how much a radical return to professional practice remains to be seen (Kruchten, 2007).

REFERENCES:
1. Beck, K. (1999) Embracing Change with Extreme Programming.
2. Kruchten, P. (2007) Voyage in the Agile Memeplex

The Rise of Agility

The move to agility involves refocusing on practices and discourse. An introduction to the principles and moves in methods termed ‘agile.’ A review of Extreme Programming (XP), the Agile Manifesto, and Scrum.

"We need to make our software development economically more valuable by spending money more slowly, earning revenue more quickly, and increasing the probable productive lifespan of our project. But most of all we need to increase the options for business decisions."
(Beck, 2000)

AGILE PRACTICE
Towards the end of the 90’s and early 2000’s saw the emergence of so-called Agile or improvisational models, including Extreme programming (Beck, 2000), Agile Development (Highsmith, 2002) and derivative approaches like Lean Software Development (Poppendieck and Poppendieck, 2003). In 1999 Eric Raymond (Raymond, 1999) posited that there were two diametrically opposite strategies evident for organising and engaging in design work; the Cathedral way and the Bazaar way. The then current radical movements in the software industry centred on Open Source software, extreme programming (Beck, 2000) and agile methodologies (Highsmith, 2002), were all characterized by frequent iterations, dynamic planning, intensive testing and making releases available regularly. The Open Source and Agile movements represented the Bazaar way for software development. The use of strict lifecycle models or organisational control frameworks (e.g. CMMI, RUP, ISO9001 style frameworks) was emblematic of the Cathedral way of software development.

From Scrapbook Photos

Figure: Manifesto for Agile Software Development (source: agilemanifesto.org)

Agile methods have since completely transformed practitioner understanding of how to organise software and high-tech development. These practitioner-oriented methods assume software development occurs in response to early, frequent, feedback. This in turn requires management commitment to allow and enable plans to evolve continuously. Agile methods have so successfully capture the development imagination that the CMMI and RUP (among others) have attempted to incorporate ‘Agility’ within their own meta-narratives.

THE AGILE MANIFESTO
In 2001 a group of developers gathered in the Lodge at the Snowbird ski resort in the Wasatch mountains of Utah. Inspired perhaps by Richard Stallmans's GNU manifesto (www.gnu.org 1985) or Mitch Kapor's Software Design Manifesto in 1990 (for an extract see hci.stanford.edu), Seventeen of them put their names to the "Manifesto for Agile Software Development" (agilemanifesto.org). The 'Manifesto' had two significant effects, it launched the 'Agile' turn in software development by offering a broad sketch of principles and a vision for the values of software development. It also played within an industry 'meme' of emancipation, inspired by other idealistic manifestos written for the software industry and beyond. Some of these interventions were intended for industry mindshare or commercial gain, others ironic or humorous (soa-manifesto.org, www.waterfallmanifesto.org, www.halfarsedagilemanifesto.org, failmanifesto.org, manifesto.softwarecraftsmanship.org, www.relisoft.com, Library Software Manifesto).

From Scrapbook Photos

Figure: Principles of Agile Software (source: agilemanifesto.org)

EXTREME PROGRAMMING
In 1999 Kent Beck introduced the world to the idea of Extreme Programming (XP) (Beck, 1999). He presented an interesting and compelling vision of the process of programming that appeared to offer substantial, almost radical, benefits if adopted or adapted into organisations.
Beck’s paper and subsequent book (Beck, 1999; Beck, 2000) provided explanations and actual cases and generated such interest that it has since taken on the appearance of a 'movement' in among professional software engineers. Such is the respect with which it is held that management and teams should take XP evaluation seriously, if only to establish a position on it on a principled basis. The culture of XP is based on the following four values: Communication, Simplicity, Feedback and Courage. In practical terms the challenges that XP address are characterised in terms of the traditional variables of project management: Cost, Time, Quality and Scope. These aspects describe the mind-set and the degrees of freedom you operate within when you work XP.

Distinguishing Characteristics of XP
The defining features of XP were set out by Beck as follows:
To learn from early tangible feedback from short development and delivery cycles; that is to develop and release often.
Incremental planning is therefore essential if learning from early release is to be fed back into the development cycle. The software development project or plan therefore needs to evolve continuously.
The schedule should be flexible to enable the team to implement new ideas, measure their cost and test their benefit, and then reset the schedule.
All tests should be written before coding. One way of understanding this is that tests are written as code is written and changed as code is changed.
All tests need to be automated and run as often as possible. What this means is that all the tests can be run 'at will' but at the very least with each build of the software.
Communication must become the very heart of development; communication can be many things but is perhaps the key practice of XP.
Design therefore needs to be reviewed continuously. XP rejects the idea that design is a one-shot up-front “design phase” that ceases prior to coding, nor is there a place for one-dimensional roles like analyst, architect or test engineer. Everyone does some design and the design is continuously evolving.
Finally, all coding needs to be collaborative. Collaborative coding implies that code is subjected to continuous to peer review and contributions through XP's emblematic process 'pair programming'. The consequence of this that responsibility is also shared. No one 'owns' the code yet everyone 'owns' the code.

XP'S FOUR VALUES
Communication Is done through source, test and code, in comments and other artifacts. It r requires real commitment, and can be in-your-face at times; it can be uncomfortable, unsettling. Communication requires engagement in all spheres, written, verbal, non-verbal, in-code, on walls. Kent's catchcry to 'embrace change' can be read as 'embrace conflict' too.

Simplicity is as aesthetic appreciation of what code and the design becomes. As a philosophical principle for design it can be used like a knife to continuously pare the program to necessary essentials. Simplicity requires eternal vigilance as is in a sense the driving dynamic behind the practice of 'refactoring'.

The very idea of feedback is integral to an XP style of working. Feedback is supposed to be real world and is exemplified by Beck's request that you bring the customer into the development environment, have the customer/user sitting and working beside you. Customers are necessary because developers are ignorant, ignorant in this case because you (the developer) are not an expert in the customer's domain and you can not know what the customer really needs, in spite of attempts to codify and capture in requirements documents. (Note: sometimes neither does the customer but that’s where eXtreme succeeds). In the same way that the customer does not know about your domain of expertise (coding).

And Courage. Right! But think again; coding, recycling, throwing it away after you have learnt how to do it right, taking an idea and writing/testing some stuff compile/debug, then using it, throw it away and start again. Thinking of programming as something miraculous, making something intangible tangible, bringing thoughts to substance in a program, thinking of programming as an inherently creative and therefore unknowable a-priori; it takes courage and perhaps a certain amount of luck to get it right.

THE VARIABLES
XP, like other systems development approaches, attempts to maximise project cost, time, scope and quality: Four variables of mixed types, uncertain (even changing) definition. If correctly modeled this problem would involve finding the maxima/minima on a complex perhaps fractal multi-dimensional surface?

Cost can increase or decrease and depends on the availability of money, people, hardware, tools. Time is generally limited and linked to estimation, other resources, need etc. Timeframe is also a concern, how long will the software be used for, is maintenance required, are people available, is the product dependent on other product release cycles. Scope should be variable, the customer can of course demand features, the goal however is to deliver on the features you really need now, leave the other stuff till later. Don’t deliver now what you can put off to a later iteration.

And Quality; the one variable that shouldn’t be treated as a variable and also the one perhaps most difficult to define. Quality is often an indicator of the success or failure of our ability to balance the dynamic interactions between cost, time and scope. Compromising quality undermines and destroys the values XP aspire's to; a craftsman strives for quality, the inherent value and appreciation of things made for use.

XP PRACTICES AND RULES
Many of these practices and rules have since become accepted as general professional practice on systems development projects. Many projects already apply some of these rules but XP aims to use ALL the rules as they reinforce each other. At least half of this list is accepted as general-programming-best-practice. Evidence of the following practices and rules defines whether a workplace is employing XP or not.
Small Releases: Start programming, check your progress against your goals, correct your direction and continue programming, repeat until you finish!
Metaphor: A simple design analogy or descriptive rubric that describes the software in a language that people from very different backgrounds can share.
Particularly useful for the customer to illustrate the problem in terms that are meaningful, e.g. “the IP packet routing and subnet bridge device” becomes “networking networks”, or “the host server proxy and daemon product” becomes a “portal”, or “the object request broker architecture for distributed applications” becomes “middleware”.
Simple Design: Focus on the real business problem, then design to meet that need, not anticipated needs or “really neat stuff” that some hypothetical future customer might find useful. You’ll probably get the first (and second) one wrong anyway so don’t invest unnecessary physical and intellectual capital into something you may throw away once, twice or three times.
Testing:  You write the code, you write the test (this is a “plural” you, see pair programming to follow).
The test is written before you code, automate the new test, run it often to boost your confidence.
On-site Customer:  Have full-time access to a customer or someone representing a customer working on the team, on-site with you as you code up the features.
Coding Standards:  Each programmer accepts the collective coding standard to support the all the source code, by making the style and formatting conform to a common standard so that the code is accessible to all past, present and future programmers that will touch the project.
No arguments about the position of curly braces or indentation, layout of functions etc.
Pair Programming: Can be roughly approximated as peer review or code review. Recall the Open Source pardigm “with enough eyeballs all problems are trivial”. The heart of XP, if you aren’t pair programming you aren’t doing XP. This (and the Planning Game) is the mark of a true XP project.
Collective Ownership: Has huge cultural and behavioural implications, this implies behaviour and practices akin to open source development. Everyone has access to the codebase, therefore everyone can (in principle) become expert in the architecture and ‘theories’ of the design of the software. But with ownership comes responsibility, instead of zones of ownership you have zones of greater or lesser expertise, ideally these average over the team, expanding over time or disappearing when members leave. The ideal outcome is to have sufficient knowledge embedded in practices, experience, memories and knowledge of the team members developing and maintaining the product.
Continuous Integration: Requires modern and usually open tools for managing source code, e.g. Subversion, CVS, git etc.
40 Hour week or Sustainable Pace:  A reasonable expectation on the part of workers and the business.
Refactoring: Coupled with attention to classic Patterns (architectural motifs) Refactoring is a way to restore or introduce simplicity of design to code on a continuous basis. Without refactoring, bug fixes and the addition of new features or enhancements leads to increasing complexity, complication, entropy and fragility. Refactoring removes what is termed 'cruft', it restores order and returns the software to stability.

The Planning Game: The planning game consists of periodic meetings development and the customer (or the customer’s representative) to explore the requirements and track progress. It facilitates incremental planning, reprioritisation and change. The plan and the software evolves continuously and visibly. The Planning Game involves the Business (customer) and Development (supplier) sitting at the same table. The game itself consists of three moves, exploration, commitment, and after an iteration, steer. Within an iteration the game is continued via Stand-up Meetings with the developers and the on-site customer present. The same moves can play out (exploration, commitment, and steer) but we can also follow how well the developers implement the 'user stories', verify the value and usability of completed stories, track progress and problems, and attempt recovery.

From Scrapbook Photos

Figure: The relationship between XP's key practices.

Agile work environments are supported by a host of tools and equipment. The
Soft Infrastructure requires good source control tools, test frameworks, build frameworks, email, news, messaging etc. An effective physical infrastructure includes best in class computer workstations, large (and multiple) monitors, accessible desk space, shared workspaces and personal areas, meeting rooms, whiteboards, display walls (information radiators) etc. The social environment has its own qualities, typically a strong espirit d'corps, pizza and social outings, sports at lunch and other social/work activities. The key point is that these values, rules, culture and practices support each other, weakness in one is covered by strength in another.

XP'S BENEFITS AND RISKS
XP is a distinctive attempt to shift from the general situation where decision-making authority resides in management teams and at key development milestones in Test/QA teams. It facilitates a shift in power and responsibility towards the engineers themselves in the product teams. As Beck’s opening introduction states...

"Extreme Programming turns the conventional software process sideways. Rather than planning, analyzing, and designing for the far-flung future, XP programmers do all of these activities—a little at a time—throughout development."
(Beck, 1999)

One way of reading XP is that it is an attempt by software engineers to exert or reassert a claim of power (autonomy, authority etc) over the production of the software. While Beck claims the effect of XP is limited to just the software engineering domain, we can conclude that if engineering teams adopt XP practices (and principles) then they will inevitably impact the other business divisions interacting with particular software development teams. The consequence therefore of adopting XP on even one team is to raise the possibility of ‘viral’ process occurring within the organisation, one that may alter the locations of control and decision-making throughout the organisation with unpredictable consequences. Like any alteration to the power balance within an organisation change itself is often subversive to current management knowledge and understanding. These are radical claims which, if we follow Beck's advice, may end up leading us to an unknown place and so a caveat; when attempting to adopt any new business process or methodology, members of the organisation need to carefully consider the potential impacts.

The Rise and Fall of Waterfall

Video link https://vimeo.com/18951935

A cartoon by Maxim Dorofeev

Seminar: Standards and quality enablers for high-tech business; 4:00pm, Tuesday 20th October 2015

The NSAI; Ireland's national resource for International Standards, standards processes, Quality and the ISO.
Kieran Cox, Education & Promotion officer with the National Standards Authority of Ireland will present on the NSAI's role in standards management, high-tech product standards and process standards including the ISO 26000 Guidance on social responsibility and ISO 9001 Quality Management Systems.

When: 4:00pm, Tuesday 20th October 2015
Where: Lecture Theatre MH201, UCD Blackrock; UCD Michael Smurfit Graduate School of Business.
Guest Speaker: Kieran Cox, NSAI Education and Promotion Officer
Contact Name: Allen Higgins

All Welcome

Enter NSAI into the UCD Library OneSearch box to bring you to the i2i system. i2i provides catalogue access for UCD Connect accounts. Members of UCD will be able to search for and access standards publications from the ISO, EN and IS (e.g. http://eu.i2.saiglobal.com/management).

Systemic Management Frameworks

An overview of SPI frameworks and standards. Organising organisations for high-tech development

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.

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

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.