Software Development Practices in Indigenous Software Startups
150
“Adopting a best practice approach to Software Development and Software Process Improvement, is fundamental to the growth and survival of many Indigenous Software Start-up Companies in Ireland” Robert Staunton National University of Ireland Galway (Atlantic University Alliance) A Research Dissertation submitted in partial fulfilment for the Degree of Masters of Science in Technology Management of the National University of Ireland, Galway. Head of Department : Professor Roy Green, NUI Galway. Thesis Supervisor : Dr. Kathryn Cormican, NUI Galway. M.Sc. in Technology Management September 2006
Transcript of Software Development Practices in Indigenous Software Startups
“Adopting a best practice approach to Software Development
and Software Process Improvement, is fundamental to the
growth and survival of many Indigenous Software Start-up
Companies in Ireland”
Robert Staunton
National University of Ireland Galway
(Atlantic University Alliance)
A Research Dissertation submitted in partial fulfilment for the Degree of Masters of
Science in Technology Management of the National University of Ireland, Galway.
Head of Department : Professor Roy Green, NUI Galway.
Thesis Supervisor : Dr. Kathryn Cormican, NUI Galway.
M.Sc. in Technology Management
September 2006
ii
Executive Summary
For a long time Ireland was behind other industrialised nations in terms of low
employment levels in industry and in its ability to attract Foreign Direct Investment
(FDI) to its shores. Throughout the past 20 years however, there has been a notable shift
in this, with Ireland seen as the leading recipient of FDI in the EU in 2002.
This has resulted in the creation of indigenous jobs through foreign companies
purchasing products and services from Irish suppliers, with Ireland now having the
highest rate of new business start-up in the EU. The indigenous software sector is
notably the biggest benefactor of this trend, employing over 15,000 people.
However, a key problem with the high rate of start-up companies in the software sector
is the time it takes for these companies to grow and compete in global markets. The
author of this thesis is of the opinion that many start-ups fail because of the underlying
management and organisational activities that drive the companies forward.
Secondly, the inherent disregard for best practice approaches throughout the software
development life cycle (SDLC) of Start-up companies is further oppressing their ability
to grow. The entrepreneurial behaviour of many managers that have founded such
software companies, is further enmeshed in this and compounds the mentality of live for
today, but don’t plan for tomorrow.
The focus of this study is on identifying the trying to resolve the problems mentioned
above. The scope of this study is on identifying best practice theory in the areas of
software engineering and breaking this down further by looking at best practice software
development and software process improvement methodologies.
iii
The research methods used in this study took the form of a survey/questionnaire and a
case study on four companies operating in the same software sector but at different
stages of maturity. The aim of this was to ascertain the levels to best practice techniques
are conducted throughout their software development processes.
From the results attained, the author then chose a case study approach on the Start-up
company to uncover why it scored so badly in relation to best practice as documented
through the Software Best Practice Questionnaire (SBPQ).
The key findings of the case study are presented and the author then provides a best
practice Framework model that in his view, would improve both the management and
organizational activities in the company and increase the possibility of the company
maturing to Build and Expansion phases of development.
Throughout history many methodologies have been touted as silver bullets to improve a
software company’s productivity and quality levels. However, few approaches have
been tailored to the specific needs of small Start-up companies. The author is satisfied
that the best practice Framework presented in this thesis could in fact be used as a
template for managers of software Start-ups. The Framework incorporates many of the
best practice techniques throughout the software development cycle and creates scale so
these companies can easily grow without major disruption to the organisational make up
of the company.
The author is confident that the findings from this research have the potential to better
equip Start-up software companies to adopt best practice software development and
process improvement techniques, thus increasing their chances of success in both
domestic and global markets.
iv
Acknowledgements
v
Table of Contents
EXECUTIVE SUMMARY ........................................................................................................................ II
ACKNOWLEDGEMENTS ..................................................................................................................... IV
TABLE OF CONTENTS ........................................................................................................................... V
LIST OF TABLES ................................................................................................................................ VIII
LIST OF FIGURES .................................................................................................................................. IX
ABBREVIATIONS ................................................................................................................................... IX
CHAPTER 1 – INTRODUCTION ........................................................................................................... 12
1.1 INTRODUCTION ........................................................................................................................ 12
1.2 PURPOSE OF THE THESIS ......................................................................................................... 14
1.3 AIM AND OBJECTIVES .............................................................................................................. 15
1.4 THESIS STRUCTURE ................................................................................................................. 17
1.5 CONCLUSIONS .......................................................................................................................... 19
CHAPTER 2 – INDUSTRY BACKGROUND ........................................................................................ 20
2.1 INTRODUCTION ........................................................................................................................ 20
2.2 SHAPING IRELAND’S ECONOMIC DEVELOPMENT ................................................................... 23
2.2.1 PEST Analysis ...................................................................................................................... 24
2.3 THE EMERGENCE OF ENTREPRENEURIAL ACTIVITY IN IRELAND ......................................... 25
2.4 THE EMERGENCE OF IRELANDS SOFTWARE SECTOR ............................................................ 26
2.5 SUSTAINING ECONOMIC GROWTH IN IRELANDS SOFTWARE SECTOR .................................. 28
2.5.1 TOWS Matrix ....................................................................................................................... 30
2.6 CONCLUSION ............................................................................................................................ 33
CHAPTER 3 – SOFTWARE ENGINEERING ...................................................................................... 36
3.1 INTRODUCTION ........................................................................................................................ 36
3.2 THE ORIGINS OF SOFTWARE ENGINEERING ........................................................................... 37
3.3 APPROACHES TO SOFTWARE ENGINEERING .......................................................................... 39
3.4 THE SOFTWARE DEVELOPMENT PROCESS ............................................................................. 42
3.5 SOFTWARE PROCESS MODELS ................................................................................................ 45
3.5.1 Waterfall Model ................................................................................................................... 45
3.5.2 Prototyping Model ............................................................................................................... 47
vi
3.5.3 Spiral Model ........................................................................................................................ 48
3.6 HEAVYWEIGHT VERSUS LIGHTWEIGHT METHODOLOGIES .................................................... 51
3.7 AGILE SOFTWARE DEVELOPMENT ......................................................................................... 52
3.7.1 Crystal/Adaptive Software Development (ASD) .................................................................. 53
3.7.2 Dynamic Systems Development Method (DSDM)................................................................ 54
3.7.3 Feature Driven Design (FDD) ............................................................................................ 55
3.7.4 SCRUM ................................................................................................................................ 56
3.7.5 eXtreme Programming (XP) ................................................................................................ 56
3.8 CONCLUSION ............................................................................................................................ 57
CHAPTER 4 - SOFTWARE PROCESS IMPROVEMENT ................................................................. 60
4.1 INTRODUCTION ........................................................................................................................ 60
4.2 WHY THE NEED FOR SOFTWARE PROCESS IMPROVEMENT (SPI)? ........................................ 61
4.3 SOFTWARE PROCESS IMPROVEMENT MODELS ...................................................................... 64
4.3.1 Capability Maturity Model (CMM) ..................................................................................... 65
4.3.2 ISO 9000 .............................................................................................................................. 67
4.3.3 BOOTSTRAP ....................................................................................................................... 70
4.3.4 Software Process Improvement & Capability Determination (SPICE) ............................... 72
4.3.4.1 The ISO 15504 framework ............................................................................................................. 72
4.4 CRITICAL SUCCESS FACTORS FOR SPI ................................................................................... 74
4.5 IMPLEMENTING A NATIONAL SPI EFFORT ............................................................................. 76
4.6 CONCLUSION ............................................................................................................................ 78
CHAPTER 5 - RESEARCH METHODOLOGY ................................................................................... 79
5.1 INTRODUCTION ........................................................................................................................ 79
5.2 RESEARCH METHODOLOGY .................................................................................................... 79
5.3 THE CHOICE OF RESEARCH METHOD .................................................................................... 82
5.4 SURVEY AND INTERVIEW METHODS ....................................................................................... 83
5.5 SURVEY DESIGN ....................................................................................................................... 84
5.6 CASE STUDY ............................................................................................................................. 85
5.7 TRIANGULATION ...................................................................................................................... 87
5.8 DOCUMENTARY RESEARCH..................................................................................................... 87
5.9 CONCLUSION ............................................................................................................................ 88
CHAPTER 6 – DATA ANALYSIS .......................................................................................................... 89
6.1 INTRODUCTION ........................................................................................................................ 89
6.2 SURVEY FINDINGS .................................................................................................................... 90
6.2.1 Requirements and Design .................................................................................................... 91
6.2.2 Code and Test ...................................................................................................................... 92
vii
6.2.3 Configuration Management ................................................................................................. 93
6.2.4 Estimates and Schedules ...................................................................................................... 94
6.2.5 Project Management and Training ...................................................................................... 95
6.3 SURVEY RESULTS..................................................................................................................... 96
6.4 CASE STUDY ............................................................................................................................. 97
6.4.1 Company D ......................................................................................................................... 97
6.4.2 As-Is Approach at Company D ............................................................................................ 98
6.4.2.1 Requirements and Design............................................................................................................. 100
6.4.2.2 Testing and Coding ....................................................................................................................... 101
6.4.2.3 Configuration Management ......................................................................................................... 101
6.4.2.4 Estimates and Schedules .............................................................................................................. 102
6.4.2.5 Project Management & Training ................................................................................................. 102
6.4.2.6 Conclusion ..................................................................................................................................... 103
6.4.3 To-Be Approach ................................................................................................................. 106
6.4.3.1 Requirement and Design .............................................................................................................. 106
6.4.3.2 Code and Test................................................................................................................................ 108
6.4.3.3 Configuration Management ......................................................................................................... 109
6.4.3.4 Estimates and Schedules .............................................................................................................. 110
6.4.3.5 Project Management and Training............................................................................................... 111
6.4.3.6 Conclusion ..................................................................................................................................... 111
6.4.4 The ‘As-Is’ Model in Practice ............................................................................................ 114
6.4.4.1 Pareto Analysis Results ................................................................................................................ 115
6.5 CONCLUSION .......................................................................................................................... 117
CHAPTER 7 – CONCLUSIONS ........................................................................................................... 120
7.1 INTRODUCTION ...................................................................................................................... 120
7.2 RESULTS OF THE STUDY ........................................................................................................ 121
7.2.1 Government Support of the Irish Software Sector ............................................................. 121
7.2.2 Benefits of Best Practice Approaches throughout the SDLC ............................................. 122
7.3 RESEARCH LIMITATIONS ...................................................................................................... 123
7.4 FURTHER RESEARCH ............................................................................................................. 124
7.5 CONCLUSION .......................................................................................................................... 125
REFERENCES AND BIBLIOGRAPHY .............................................................................................. 126
APPENDIX A SURVEY/QUESTIONNAIRE ............................................................................. A-1
APPENDIX B E-MAIL REQUEST TO PARTICIPATE IN SURVEY ..................................... B-1
APPENDIX C SPI INTERVIEW QUESTIONS .......................................................................... C-1
APPENDIX D DATA PERTAINING TO PARETO CHART ................................................... D-1
viii
List of Tables
TABLE 2.1.1 CYCLES OF INNOVATION .......................................................................................................... 20
TABLE 2.1.2 - LARGEST OECD EXPORTERS OF SOFTWARE AND COMPUTER SERVICES 2002. SOURCE
(OECD/EUROSTAT.) ........................................................................................................................... 21
TABLE 2.2.1 - FINDINGS BASED ON THE ENTERPRISE IRELAND (2005) ECONOMIC PROFILE OF IRELAND...... 24
TABLE 2.4.1– GENERAL CHARACTERISTICS OF THE IRISH ICT AND SOFTWARE SECTOR. (ICT IRELAND 2003,
IDA 2003) .......................................................................................................................................... 27
TABLE 2.5.1 - TOWS MATRIX. .................................................................................................................... 32
TABLE 3.3.1– APPROACHES TO SOFTWARE ENGINEERING (WANG & KING 2000, PG. 19). ........................... 40
TABLE 3.3.2– ORGANISATIONAL AND MANAGEMENT CATEGORIES OF SOFTWARE ENGINEERING. (WANG &
KING 2000, PG. 15). ............................................................................................................................ 41
TABLE 3.4.1– TYPICAL SKILL SET OF A SOFTWARE ENGINEER. .................................................................... 42
TABLE 3.4.2– ROLE OF STAKEHOLDERS DURING THE SOFTWARE DEVELOPMENT PROCESS .......................... 43
TABLE 3.6.1 – DIFFERENCES BETWEEN LIGHTWEIGHT & HEAVYWEIGHT METHODS. .................................. 51
TABLE 3.7.1 – GENERAL CHARACTERISTICS OF AGILE METHODS (HIGHSMITH, 2002). ............................... 52
TABLE 3.7.2- THE TWELVE PRACTICES OF XP. ............................................................................................. 56
TABLE 4.3.1– STRENGTHS AND WEAKNESSES OF SPI MODELS (RICHARDSON, 1999). ................................ 64
TABLE 4.3.2– KEY PROCESS AREAS OF THE CMM (PAULK ET AL. 1993) ..................................................... 66
TABLE 4.3.3- ISO 9000-3 GUIDELINE CLASSES (ISO 9000-3, 1997). ........................................................... 69
TABLE 4.3.4 – ISO 15504 FRAMEWORK, (ISO/IEC TR 15504-2 1998, PG.5). .............................................. 73
TABLE 5.2.1 – KEY RESEARCH DECISIONS (DENSCOMBE, 2003, PG. 5) ......................................................... 80
TABLE 5.2.2 – ADVANTAGES AND DISADVANTAGES OF METHODS OF RESEARCH. ....................................... 81
TABLE 5.6.1– CASE STUDY AND SURVEY USED IN RESEARCH...................................................................... 86
TABLE 6.3.1- SURVEY RESULTS ................................................................................................................... 96
TABLE 6.4.1- ADVANTAGES AND DISADVANTAGES OF THE ‘AS-IS’ FRAMEWORK MODEL ........................ 105
TABLE 6.4.2 - ADVANTAGES AND DISADVANTAGES OF THE ‘TO-BE’ FRAMEWORK MODEL. ..................... 113
ix
List of Figures
FIGURE 3.4.1– STAKEHOLDERS OF THE SOFTWARE DEVELOPMENT PROCESS ............................................... 43
FIGURE 3.5.1– INPUT/OUTPUT FROM A TYPICAL SOFTWARE DEVELOPMENT PROCESS. ................................ 45
FIGURE 3.5.2 – THE WATERFALL MODEL (ROYCE, 1970) ............................................................................ 46
FIGURE 3.5.3 – THE PROTOTYPING MODEL (BOEHM, 1988) ......................................................................... 47
FIGURE 3.5.4 – SPIRAL MODEL OF SOFTWARE DEVELOPMENT AND ENHANCEMENT. (BOEHM, 1988) ......... 49
FIGURE 3.7.1– TIME BOXES IN AGILE DEVELOPMENT. ................................................................................. 55
FIGURE 4.3.1– CAPABILITY MATURITY MODEL (CMM). (PAULK ET AL. 1993). .......................................... 65
FIGURE 4.3.2– STRUCTURE OF THE ISO 9000 STANDARDS. .......................................................................... 68
FIGURE 4.3.3– BOOTSTRAP METHODOLOGY (KUVAJA & BICEGO, 1994) ................................................. 70
FIGURE 6.4.1 - STAKEHOLDERS OF THE SOFTWARE DEVELOPMENT PROCESS ............................................... 99
FIGURE 6.4.2– STAKEHOLDERS OF THE SOFTWARE DEVELOPMENT PROCESS ............................................. 107
FIGURE 6.4.3 - DATA ANALYSIS PARETO CHART ....................................................................................... 116
Abbreviations
Term Meaning
SE Software Engineering
SPI Software Process Improvement
EI Enterprise Ireland
IDA Irish Development Agency
CMMI Capability Maturity Model Integration
ISA Irish Software Association
ICT Information and Communications Technology
PEST Political, Economic, Social and Technological
SME Small Medium Enterprises
EU European Union
OECD Organisation for Economic Cooperation and Development
GDP Gross Domestic Profit
FDI Foreign Direct Investment
TOWS Threats, Opportunities, Weaknesses, Strengths
x
EEC European Economic Community
NTMA National Treasury Management Agency
US United States
ESG Enterprise Strategy group
PRTLI Programme for Research in Third-Level Institutions
SFI Science Foundation of Ireland
R&D Research and Development
NDP National Development Plan
ESC European Software centre
DERI Digital research Enterprise Institute
IEI Institute of Engineers of Ireland
IEEE Institute of Electrical and Electronics Engineers
OS Operating System
NATO North Atlantic Treaty Organisation
ASD Agile Software Development
XP eXtreme Programming
ISO International Standards Organisation
OOD Object orientated Development
SDLC Software Development Lifecycle
DSDM Dynamic systems Development Method
FDD Feature Driven Design
ESD Effective Software Development
12
CHAPTER 1 – INTRODUCTION
1.1 Introduction
Since the inception of the software engineering field in the late 1950’ early 1960’s, there
is a shared view throughout literature that missed deadlines and poor quality are the
nature of the software industry.
Unlike other industrial sectors software development companies are unique in that
although many may have poor insight into their software development practices, high
margins allow them to maintain a certain level of profitable. In addition, few developers
have insufficient in best practice software development techniques, with little
opportunity within these companies to enjoy the opportunity to learn about best practice
development techniques, as poor practices are so widespread.
In 1998, it was stated that only an estimated 75% of software development organizations
achieve only Level 1 CMMI which equates to an ad-hoc approach to software
development. (Gainer, 1998)
Although many such software companies could benefit from adopting better practices
throughout the software development life cycle (SDLC), few ever attempt change and
even fewer manage to sustain the change effort to realize the benefits.
The irony is that many of these companies accept that implementing an appropriate
software development process can improve both the effectiveness and efficiency of their
software development practices. But adopting a disciplined approach to software
development or software process improvement is impeded manly because of a lack of
understanding of the long term benefits that can be gained from a best practice approach.
In many cases, such companies rely heavily on key personnel to push projects through
the development process which over time can create a stressful working environment as
13
developers and project managers are continually and unnecessarily handling major
development issues so as to maintain timely project completion.
Poor planning, late requirements and poor project management can impact greatly on
such projects that often results in late delivery and poor quality.
In Ireland, the indigenous software sector employs 15,000 people in 660 companies with
the total software industry employing 25,000 in Ireland (DETE, 2006). This alone
underlines the importance of the Indigenous software sector to the Irish economy. At last
years Annual Conference of the Irish Software Association, Minister for Trade and
Commerce Michael Ahern made clear that Ireland is at a turning point in its economic
development as a result of globalisation and increased global competition.
Some of the key challenges for Irish software companies lie in their ability to create
scale and compete in a global economy. Enterprise Ireland has provided support for
many start-up and small software companies. It looks to hone and develop skills in the
following key areas as its looks to encourage and sustain growth in the indigenous
software sector, (DETE, 2006);
• Leadership Capabilities
• Strategic Marketing & Sales Execution
• Funding
• Innovations & Commercialisation
To do this however many of Ireland’s indigenous software companies will need to
review existing software development practices and realize that their ability to create
scale will ultimately provide them with the direction needed to grow and increase both
their product range and client base. In the long term ad-hoc approaches to software
development will make this transition difficult. What is needed is a realization that
adopting best practice approaches though the SDLC will overcome difficulties with
missed deadlines and poor quality software. This type of approach is paramount in
sustaining growth in Ireland’s indigenous software sector.
14
1.2 Purpose of the Thesis
Having worked primarily for small software companies both directly and indirectly over
a ten year period, the author has experienced at first hand many of the difficulties
outlined in the previous chapter and the difficulties indigenous software companies
encounter when trying to adopt a best practice approach to their SDLC.
As also noted, this has now become a growing concern for the Government and the Irish
state development agency, Enterprise Ireland. This thesis has been developed from
different sources that include documented research in the area of Software Engineering
and the author’s personal experience and interest in the field.
This thesis argues that in order to sustain and grow Ireland’s indigenous sector, smaller
software companies need to embark on a process improvement strategy that is in line
with best practice teachings. It’s the authors view that this will promote a more focused
approach in the area software development, better align company practices with the
companies overall business strategy and increase the chances of long term survival in a
highly competitive industry.
This thesis is concerned with providing an explanation of known software engineering
best practice approaches and how these approaches impact on both software
development and software process improvement. To achieve this, the author exams
several companies operating in a related field but who are at different stages of maturity.
This examination is then used to ascertain the benefits best practice approaches can have
on the SDLC of the chosen companies.
If small software companies can focus their efforts on process improvement then the
author is confident that a series of best practice benefits such as increased productivity,
improved product quality, reduced time to market, increased organisational flexibility
and customer satisfaction are attainable to the overall business. If this is achieved then
15
there is no doubting the growth these companies can achieve though increased product
ranges and client base thus sustaining and raising the profile of the Irish Software sector.
1.3 Aim and Objectives
Ireland is quite unique when it comes to software development. Once viewed as a small
agricultural nation on the periphery of Western Europe, Ireland today boasts a thriving
ICT sector with high employment and is one of the largest exporters of software in the
World. As stated, Ireland’s software sector comprises many small indigenous companies
and to continue economic growth it is important to sustain growth in these companies.
The Hypothesis is best illustrated by the following statement;
“Adopting a best practice approach to Software Development and Software
Process Improvement is fundamental to the growth and survival of many Start-up
Indigenous Software Companies in Ireland”
The objectives of this thesis are as follows;
• To form an understanding of the Irish governments support for Ireland’s
indigenous software sector through FDI, Grants, Tax Incentives and support
networks.
• To understand and analyse the perceived advantages and disadvantages of best
practice approaches to software development and software process improvement,
based on documented theory and literature.
• To identify companies involved in software development in a related market
segment but at different levels of growth in term of number of employees,
number of projects and geographical concentration.
16
• To identify the level to which these companies adopt a best practice approach to
software development and software process improvement throughout their
SDLC.
• To identify and evaluate problem areas throughout their SDLC for all the
companies based on the three categories of;
o Start-up phase (Company D, Company C),
o Build phase (Company B) and
o Expansion phase (Company A).
• To identify key process improvement areas for the Start-up company identified
as part of the Case Study in this thesis. This is achieved through a comparison of
the companies existing SDLC practices to a best practice approach.
17
1.4 Thesis Structure
The first chapter provides information relating to the background of this thesis. This
covers the aims and objectives of the research and also provides an overview of the
thesis chapters
Chapter 2 looks at Ireland’s ICT sector and explains the reasons why Ireland emerged as
a true economic force in the industrialised World since the 1990’s. A PEST analysis is
presented to explain some of the external factors that can impact on the Irish economy
and the ICT sector as a whole. The growth of entrepreneurial activity and the correlation
this has with the growth of Ireland’s software sector is also examined.
A TOWS matrix is used to highlight some of the key finding of the Forfas Annual
Competitiveness Report 2005.
The chapter concludes with documented criticisms made by some leading software
experts and the authors opinions on the later in relation to government support of small
software companies in Ireland.
Chapter 3 focuses on Software Engineering. Its history and various approaches to
software engineering are discussed and reviewed which cover both heavyweight and
lightweight methodologies. The role and duties of a software engineering are also
explored. In conclusion the benefits of a lightweight approach are explored and some of
the shortcomings in adopting this approach are argued. This will later impact on the
authors proposed framework for software development in small software development
companies which is discussed in greater detail in Chapter 6.
Chapter 4 looks at Software Process Improvement and is presented in much the same
way as Chapter 3. In introducing the topic the author focuses on its foundations and then
explores four of the most widely used SPI models. The role of SPI in a European context
is examined and many of the critical success factors in adopting an SPI initiative are
documented. The author’s argument on implementing a national SPI effort is delivered
18
and how such an initiative can succeed. The author discussed this by focusing the many
support groups already established both directly and indirectly through Enterprise
Ireland.
Chapter 5 presents the methodology used in this research and explains how the author
envisaged the research which later impacted on its design and how it was executed. The
chapter illustrates the research strategy, research methods and research instruments used.
The chapter also outlines in detail how the research was conducted and how data was
collected. This later allowed for judgements to be made on the validity of this research
and whether or not any credibility should be given to its findings and conclusions.
Chapter 6 looks at the findings and comments on the results obtained from the research.
The data is presented and aspects of the findings are singled out and described. This is
followed by a case study which discusses what implications the findings might have for
the issues, problems and ideas that prompted the research. The findings are analysed
with reference to the theories and issues noted in the earlier chapters as providing the
context by which the research was conceived. The chapter concludes by considering the
findings from the case study that provides further evidence that a best practice approach
is a more viable option for long term growth when compared to the ad-hoc approaches
and their impact of the organisational and functional performance of the Start-up
company.
Finally, Chapter 7 deals with the conclusions to the entire study and suggestions are
documented for the way forward. The chapter presents an evaluation of the research and
its contribution to software development and software process improvement in small
software companies. New directions for further research are also identified.
19
1.5 Conclusions
A major goal for the author in was his ability to provide an understanding to persons not
inept in software engineering practices, in best practice approaches to both software
development and software process improvement and methodologies. But before
embarking on this, the main purpose of this chapter was to provide the reader with an
overall understanding of the aims and objectives of this thesis.
The main research questions were documented on page 9 which set up the discussion for
the forthcoming chapters.
Chapter 2 is concerned with an industry analysis and an overview of the Irish
governments support of the Irish software sector while Chapters 3 and 4 form the
literary review based on the in the main areas under examination, namely Software
Development and Software Process Improvement.
Some sections in these chapters may be more descriptive for the seasoned software
professional, but the author felt this was important to allow readers with limited
knowledge of both areas to fully understand the arguments that are being raised in this
thesis.
Chapters 6 and 7 focus on the analysis of the authors findings based on the research
undertaken. It is here that the author focuses more closely on the shortcomings Start-Up
companies have in adopting best practice techniques.
20
CHAPTER 2 – INDUSTRY BACKGROUND
2.1 Introduction
History shows that technological innovation and economic growth are closely related
and can be articulated within the concept of cycles or waves which have been repeated
over the past 300 years.
Dates No. of Years Cycle of Innovation
1780-1840 60 years First Wave cotton-spinning, iron making, steam power
1840-1900 60 years Second Wave steel making, railways
1900-1950 50 Years Third Wave electrification, internal combustion engine
1950-1990 40 Years Fourth Wave petrochemicals, electronics, computing,
aerospace
1990-2020 30 Years Fifth Wave corporate client -server networks, software.
Table 2.1.1 Cycles of Innovation
When defining the longest cycles, (Schumpeter 1942, 1976) referred to each cycle as the
interruption of a technological revolution and the absorption of its effects.
Techno Economic Paradigms are a concept developed by (Carlotta Perez, 1999) who has
argued that technological revolutions occur about every 50 years. After the initial
discovery there is a period of 10 to 20 years of adjustment and assimilation before the
full benefits to the technology are recognized.
The emergence of the Information Revolution in the 1990’s, the fifth wave, has
coincided in a period of rapid growth in the Irish Economy commonly known as the
21
‘Celtic Tiger’. This phenomenal growth was typified in 2002 when Ireland was
recognised as the largest exporter of software and computer services within the EU.
Of the top five countries listed in the figure below, Ireland had the highest proportion of
software and computer service exports to total exports which was recorded at 9.1%.
(OECD, 2002)
Country Exports (US$) Share Proportion of GDP
Ireland 10,377 9.1% 8.5%
US 6,930 0.7% 0.1%
Germany 5,162 0.7% 0.3%
UK 4,463 1.1% 0.3%
Spain 2,483 1.3% 0.4%
OECD 42,200 0.7% 0.2%
EU 30,646 1.0% 0.3%
Table 2.1.2 - Largest OECD exporters of software and computer services 2002. Source
(OECD/Eurostat.)
Ireland’s economic growth is due to a culmination of factors that include the inflow of
Foreign Direct Investment (FDI), the Governments model of Social Partnership and
structural and Cohesion funds from the EU long before the Celtic Tiger gripped the
country.
This Chapter provides the background to Ireland’s emergence as an economic force in
the industrialized World. It will identify reasons why Ireland was able to embrace the
technological revolution and entrepreneurial activity which ultimately coincided in rapid
growth in Ireland’s software sector.
The opening paragraph provides an insight into key incidents that helped shape the
country’s economic development form the 1970’s. An environmental analysis of
22
Ireland’s political, economic, socio-cultural and technological forces is presented to
further highlight mitigating factors impacting on Ireland’s economic development.
A background to entrepreneurial activity and the government’s support of the indigenous
sector sets the tone for a detailed review of why Ireland has become such a dominant
global player in the software sector. Sustaining this growth and developing Research and
development (R&D) capabilities is key to the governments vision for attracting research
based projects from abroad and ultimately moving Irish industry further up the value
chain.
The author uses a TOWS (Threats, Opportunities, Weaknesses and Strengths) matrix to
present some of the considerations that will impact on how this might be achieved.
In conclusion, the author presents some areas where the government can play a more
active role in supporting the growth of many small software firms in Ireland. These
findings are based on documented evidence of key figures who are actively involved in
the Irish software sector.
23
2.2 Shaping Ireland’s Economic development
In 1973 Ireland joined the European Economic Community (EEC) which later initiated a
single market for member states in the late 1980’s. Between 1979 and 1987 Ireland
experienced a relatively low economic growth and a rapid rise in unemployment which
jumped for 5.5% in 1979 to almost 17% in 1987. A series of fiscal corrections resulted
in a reduction in exchequer borrowings in the late eighties which later led to a fall in the
country’s debt and the beginning of Ireland’s economic recovery.
Between 1993 and 2000 Ireland began to experience unprecedented high levels of
economic growth through foreign investment from US companies which led to
employment rising from 1.15 million to 1.65 million over the period, (DETE, 2003,
pg.3).
By 2002 Ireland was the leading recipient of foreign direct investment (FDI) in the EU.
Annual output for 2002 from foreign owned companies amounted to €69billion of which
€65billion was exported. By 2004 there were just over 1000 international companies in
Ireland, of which 46% were of US origin, employing over 129,000 people, (DRA, 2006,
pg.3).
Factors such as Ireland’s low corporate tax regime and the availability of a low cost,
English speaking, well educated workforce all played a significant role in attracting
foreign investment.
In terms of job creation, evidence suggests that foreign firms have created indigenous
jobs through the purchasing of services in the Irish economy and through purchases from
Irish suppliers. In 2003, foreign firms purchased of €4.4bn of materials and €5.0bn of
services in Ireland. (Forfas, 2005)
The PEST analysis on the next page better illustrates some of the key factors impacting
on Ireland’s macro environment. PEST analysis involves looking at the Political,
Economic, Socio-cultural and Technological factors that need to be considered when
assessing both positive and negative impacts on a company’s operating environment.
24
2.2.1 PEST Analysis
Political factors
• Government commitment to supporting the Research and Development in the Indigenous sector through grants such as RTI funding, funding for Hose’s.
• Ireland has a politically stable economy that is recognised as being a parliamentary democracy.
• Ireland is a member of the European Union (EU) and is also a member of most major international organisations, but retains a neutral stance on military matters.
• Irish law is based on common law as modified by legislation and the written constitution. Justice is administered in public in courts established by law
• Ireland has a low corporate tax rate. A 10% tax rate on manufacturing profits a will continue until 2010 for those entitled to it in July 1998. A 12½% tax rate on corporate trading income applies from 1/1/2003 and is EU approved.
Economic influences
• High Economic Growth. From 1995-2001 it averaged 9.5%. Today, it remains almost 5 times higher than the EU 15 average of 1.0%.
• GDP in 2004 reached €148 billion. On a per capita basis this is equivalent to €36,000 per person, the second highest in the EU after Luxembourg.
• High Employment rates. Employment increased by 3% in 2004 and the numbers at work grew by 65,000. 2005 forecasts indicate that employment is projected to rise by 2.9% with unemployment falling to 4.2%.
• Ireland’s debt to GDP ratio, currently at 29.4% is the second lowest in the EU.
• A sustained expansion in exports has been Ireland outpace the rest of the World by a factor of three. 2004 exports stood at €84 billion, 2.2% more than 2003.
Sociological trends
• Ireland’s has a population of 4.1 million, its highest level in over 130 years. This is the highest in the EU and almost double that of the next member state Cyprus.
• Labour Supply is at its highest level ever due to high levels of immigration and increased levels of female labour force participation has helped to boost the labour supply to over 2 million people.
• The population is expanding at over 80,000 p.a. and house completions running at 5% of the national housing stock, compared to an average of 1% for the EU.
• Ireland has the youngest population profile and boasts the second highest proportion of under 15’s after Iceland. Ireland also has the largest economically active age group of 16 to 64 year olds.
• UN predictions indicate that by 2010, under 25’s as a share of the population will stand at 34% in Ireland compared to the projected average for all of Europe of 27.5%.
Technological Innovations
• Ireland’s current broadband rate of 4% is one of the lowest in the EU, ranked 19th out of 25 states. The leading countries of Denmark and the Netherlands average penetration rates of 18%.
• The National Development Plan (NDP) 2000-2006 has resulted in both the completion and close to completion of the following projects;
o Commencement of almost 500 health service projects ranging from major acute hospitals to more minor works
o The Dublin Port Tunnel to ease traffic congestion
o Completion and commencement of work on over 40 national road projects.
o The ongoing upgrading of Irish Rail Carriages, routes and services.
o Completion of the LUAS light rail system for the Dublin metropolitan area.
o Completion of over 180 water and waste water schemes.
Table 2.2.1 - Findings based on the Enterprise Ireland (2005) Economic profile of Ireland.
25
2.3 The Emergence of Entrepreneurial Activity in Ireland
In addition to attracting inward FDI, the Irish government has sought to support export
orientated indigenous companies including Start-up’s. Again, there is evidence to
suggest that local indigenous entrepreneurs have taken full advantage of foreign
investment by using their knowledge and responded by creating value added to their
products.
Between 1990 and 2002, exports by agency assisted indigenous enterprise grew in
nominal terms at 5.5% per annum. By 2003, Ireland had the highest rate of new business
start-ups in the European Union, at 4.7%, compared to the EU average of 2.8%.
Ireland
also ranks fifth of the EU member states for the proportion of the workforce that is self-
employed (Forfas, 2004, pg. 8).
Ireland’s state development agency, Enterprise Ireland, supports the development of
innovative products and services that offer unique extra value benefits to customers
in world markets by focusing on in-house research and development. Encouraging
and supporting new high potential start-up business is a key priority for Enterprise
Ireland.
In 2005 Enterprise Ireland supported 75 High Potential Start-ups all of whom
operate in knowledge intensive sectors. These companies are expected to grow
rapidly with the creation of over 1460 new highly skilled jobs, generating exports
worth €183m within the next two years. Enterprise Ireland invested €17m of the total
€83m investment in the 75 new start-ups. (DETE, 2006a).
26
2.4 The Emergence of Irelands Software Sector
As stated in chapter 1, the indigenous software sector employs 15,000 in 660 companies
with the total software industry employing 25,000 in Ireland. The OECD released the
results of research that showed Ireland was the world's largest exporter of software in
2001.Turnover in the software industry in Ireland was over €15 billion in 2004 (€1.4
billion from indigenous sector), accounting for 13% of total exports. DETE (2006b)
This fact would suggest that Ireland has a massive indigenous software development
industry. However, it should be noted that most of that export value comes from the
localization and distribution of products from foreign multinationals such as Microsoft,
Dell, Intel, Google, Oracle and Symantec. The number of Irish indigenous software
development companies competing successfully on the world stage is relatively small
with even fewer listed on major stock exchanges.
In truth, public listed Irish software companies have had mixed experiences in the stock
markets with drastic consequences for some. Some examples include travel software
company Datalex who de-listed from the NASDAQ in April 2002 after only eighteen
months of trading after its share price crashed to below $1, (Breaking News, 2002). One
time internet star and FTSE 100 index member, Baltimore Technologies de-listed in
2001, (Breaking News, 2001). Parthus Technologies was acquired by Ceva in 2002.
Education software company Riverdeep went private and de-listed in 2002 and both
IONA and Trintech reported losses in 2005, (Silicon Republic, 2005)
Indeed, Ireland does export software to global markets but the evidence suggests that
most of this emanates from US companies based here rather than from home-grown
companies. In 2001, out of a total sector worth just over €13bn, multinationals
accounted for €11.57bn, and of software exports worth €12.2bn in 2001 foreign-owned
companies were responsible for nearly €11bn, (Company A, 2003)
27
Far from being a dominant force in the software world, it seems, Ireland should more
correctly be seen as a highly effective route to market for US software firms.
The table below provides a breakdown of the main characteristics of the Irish ICT and
Software sector as of 2003.
A recent survey carried out by (HotOrigin, 2003) 1 found that Ireland’s indigenous
software market can be segmented into three broad categories based on the stage of
development of the company. 74% of the companies surveyed fall into the start-up
category (with up to 25 employees), 18% are defined as being in the build category (26-
75 employees), and 8% of the companies surveyed can be categorised as Expansion
firms (more than 75 employees).
Bearing this in mind, the author took the decision at an early stage the need to identify
companies that fell into each of these categories and to identify the level to which best
practice techniques are practiced in each.
ICT Software ICT Software
Firms Employees Firms Employees Exports Exports
FDI 300 55,000 200* 14,000* 28bn 7.0bn*
Indigenous >700* 45,000* 600 11,000 1.5bn
Total >1,000 100,000 800 25,000 8.5bn
* Estimate value
Table 2.4.1– General characteristics of the Irish ICT and Software Sector. (ICT Ireland 2003, IDA
2003)
1 HotOrigin (2003) conducted an online survey of CEO’s of indigenous software product companies and carried out in-depth interviews with CEO’s of indigenous software companies that achieved sales success in 2002. A total of 416 indigenous software product companies were identified in Ireland. Of these, 50 were based in Northern Ireland. 166 CEO’s responded to the survey representing a response rate of 40%. Companies in Northern Ireland represented approximately 10% of the respondents.
28
2.5 Sustaining Economic Growth in Irelands Software Sector
The Enterprise Strategy Group (ESG) report 'Ahead of the Curve, Ireland's Place in the
Global Economy suggests that Ireland’s performance was driven primarily by a
relatively small number of foreign-owned firms who chose Ireland as their base for
serving European markets. The effect of these firms on the economy was such that it
masked the generally poor performance of the indigenous sector, with the exception of a
small number of high-performing firms. Much of the business that Ireland developed in
the past now faces significant competitive pressure due to the countries rising costs
which is eroding its competitiveness and reducing attractiveness for FDI as foreign
companies look to alternative software markets such as India and Israel (Forfas, 2004).
The Irish government has placed an increased emphasis on building competitive
advantage through new product development (NPD) and Innovation.
“Building research and development capability to support the development of high-
value products and services will be a critical foundation of competitive advantage for
Ireland going forward," Minister Martin, Electric News (2005)
(Smilor & Gill, 1986) identify the following factors as being critical to technological
innovation and development, Talent, Ideas, Capital and Knowledge. According to
(Dertouzos, 1999), technological innovation has four pillars, which are consistent with
the factors mentioned above; venture capital investment; infrastructure for high
technology; creative ideas and an entrepreneurial culture focused in the passion for
business.
From a low starting point, Ireland has taken a number of significant steps to recognise
the importance of research and development (R&D) which is consistent with
(Dertouzos, 1999). This includes the allocation of €2.5 billion in the National
Development Plan (NDP) (2000-2006) to R&D and innovation, establishing the Science
Foundation Ireland (SFI), the Programme for Research in Third Level Institutions
(PRTLI) and the introduction of R&D tax credits for companies in 2004.
29
Evidence suggests that Ireland is making progress in the area of Venture capital
Investment with latest figures from the Q1 Techpulse Venture Capital survey showing
investment to be up by 70 percent on the previous quarter, (Electric News, 2006)
However, as the NDP looks to improve Ireland’s overall infrastructure, it is feared that
not enough is being done with evidence from the latest IMD report on international
competitiveness. It ranks Ireland only 44th out of the 60 countries surveyed in basic
infrastructure, well behind its main competitors, (Mulqueen, 2005).
Business Incubation facilities have been established to nurture talent and ideas and also
increase the level of entrepreneurial activity and innovation to improve the survival rates
and growth prospects of new and existing small companies. The European Software
Centre entered into collaboration with NUI-Galway in establishing the Digital Enterprise
Research Institute (DERI). Such facilities can help newly established companies to
survive and grow during the start up period through the provision of hands-on
management assistance, access to financing and advice on business or technical support
services.
The Institution of Engineers of Ireland (IEI) STEPS programme is another initiative
which is attempting to encourage more young people to enter engineering courses to
maintain a steady flow of science, technology and engineering graduates.
In October 2005 Mr. Micheál Martin TD, Minister for Enterprise, Trade and
Employment, announced SFI funding of €11.7m to the Irish Software Engineering
Research Centre (ISERC) at the University of Limerick, (Silicon Republic, 2005)
In total the SFI recorded a €122 million in funding world-class scientific and
engineering research in third level academic institutions in Ireland. There is no doubting
that work at such centres will deliver a sustained competitive advantage and address
some of the key challenges faced by the by the Irish software development sector.
30
The governments (R&D) tax credit system, in existence since 2004 is a welcome tax
initiative that goes some way towards promoting R&D activity in Ireland. However, the
scope of the legislation has disappointed many SME companies and initial feedback
from enterprises indicates that the scheme is not having a material impact on the level of
R&D activity.
Some of the main shortcomings identified to date include,
• A lack of incentive for companies currently in the development phase;
• The provision of tax credits for incremental expenditure only;
• A lack of preferential incentives for small companies;
• Unnecessary complexity in scheme administration.
Over fifty percent of ICT companies surveyed felt that the (R&D) tax credits scheme did
not encourage smaller companies to engage in research and development (ICT, 2006, pg.
8).
2.5.1 TOWS Matrix
Based on the evidence so far, the author presents a TOWS (Threats, Opportunities,
Weaknesses and Strengths) matrix on the next page to present a comparison of the Irish
economy’s position now (strengths and weaknesses) with the position of the future
(opportunities and threats) and also considers ways to manage and mitigate these
developments for the future development of Ireland’s economy.
31
In
tern
al
Fa
cto
rs
→
Ex
tern
al
fact
ors
Str
eng
ths
•
Ireland has a flexible, young and w
ell educated
workforce.
•
High Employment rates. (1995 1.3 million
employed, 2005 1.9 m
illion)
•
Strong ICT culture.
There
are
1,300 ICT
Companies
already
established
in
Ireland,
employing over 90,700 people.
•
Government commitment (N
DP 2000-2006) to
improving Ireland’s infrastructure has helped
sustain and attract FDI.
•
High Living Standards. A 2002 measure of
consumption expenditure by households ranked
Ireland 5th out of 12 nations.
•
Ireland ranks 5th among 16 countries in terms of
CO2 emissions, with 0.35 kg of CO2 emitted per
unit of GDP.
•
Ireland is one of the most open economies in the
world in term
s of trade in goods and services
(2nd/16).
Wea
kn
esse
s
•
Ireland remains
the
second most expensive
country in the EU, behind D
enmark in the EU
15.
•
Over the
past
12 months, Irish consumer
inflation rates have dipped below the EU average
(8th/15)
•
The 2004 EU Competitiveness Index ranks Irish
productivity in private sector services 8th/10 EU
countries.
•
In 2004 the EU AMECO Database stated Ireland
had experienced the highest increase in total cost
per employee among the countries benchmarked,
after Hungary.
•
Ireland is ranked 13/16 countries in term
s of
perceived quality of infrastructure. WEF G
lobal
Competitiveness Report, 2004/ 05
•
Ireland continues to perform
particularly poorly
with respect to broadband usage (14th/15).
•
Low level of patent applications is m
uch lower
in Ireland relative to leading economies such as
Finland and the Netherlands.
Op
po
rtu
nit
ies
•
Ireland’s low rate of
corporation tax is
frequently cited by foreign investors as the most
important reason for locating in Ireland. KPMG
Corporate Tax Rates Survey, 2004.
•
A
WEF
Global
Competitiveness
Report
2004/05 suggests that the level of regulation on
Irish enterprises is low relative to m
any of the
other countries benchmarked.
•
European Innovation Scoreboard, 2004 ranks
Ireland 1st the
number of
science and
engineering graduates per thousand of
the
population aged 20-29.
•
The
2004 Global Entrepreneurship Monitor
report placed Ireland's Total Entrepreneurial
Activity rate 5th/16 countries measured.
•
Tax incentives to support start-ups and business
SO
Str
ate
gie
s
•
High em
ployment rates should continue given
Ireland’s low corporation rate of tax, which is a
critical factor in attracting FDI.
•
Having
a Flexible,
young
and
educated
workforce
can sustain Ireland’s position EIS
ranking for science and engineering graduates.
•
Having an open economy in relation to trade can
sustain Ireland’s attractiveness as a place of low
regulation in industry compared to other EU
countries.
•
Continued
Government
support
for
future
business
start-ups
should
encourage
more
entrepreneurial activity in the SME ICT sector.
•
High
living
standards
and
Ireland’s
environmental consciousness should enhance its
WO
Str
ate
gie
s
•
Although Ireland is the second m
ost expensive
country in the EU, its relatively low rate of
corporation tax and low level of regulation can
compensate for this.
•
Despite recent price increases in relation to costs
per
employee,
Ireland
is
still
positioned
favourably in the EU competitive Index and in
the number of science and engineering graduates
produced. This is sure to attract further FDI and
supporting start up businesses in the ICT sector.
•
Government and Enterprise Ireland initiatives are
actively tackling problem areas such as Irelands
infrastructure and business
start
up support
respectively.
32
growth provided by the extension of the Seed
Capital
Schem
e and
Business
Expansion
Schem
e were extended in 2004 to 2006.
ability to attract FDI and also sell Irish products
abroad.
Th
rea
ts
•
A CBRE, Global Market Rents survey of 16
cities in 2005 found only two cites (London and
Paris) more expensive than Dublin.
•
Electricity costs for Irish firms have escalated
by alm
ost 42 per cent between July 2000 and
January 2005.
•
From 1995-2004 insurance costs have risen by
over 60 per cent in Ireland, compared to just
over 20 per cent in the EU.
•
Waste disposal for business in Ireland has risen
from €32 m
illion in 1995 to over €800 m
illion
in 2004. (IBEC)
•
Ireland’s high rate of VAT m
ay have an impact
on the competitiveness of the tourism
industry
in Ireland.
•
In 2004, the ESG recommended that m
any Irish
managers seek more training, particularly in
strategic development
and im
plementation.
“Ahead of the Curve – Ireland’s P
lace in the
Global Economy”, Enterprise Strategy Group,
(Forfás, (2004).
•
A 2004 Forfás report indicates that 42% of
SMEs
in Ireland do not
prepare
detailed
marketing plans. “Innovate
Market Sell”,
(Forfás, (2004).
ST
Str
ate
gie
s
•
Although insurance, electricity and w
aste costs
have risen this has also impacted on other E
U
countries. To Ireland’s advantage, C
onsumption
expenditure per household is low and CO2
emissions are low w
hen compared to other E
U
countries.
•
Enterprise Ireland, FAS and groups
such as
ITAG in Galway have provided assistance in
developing m
anager and employee skills in the
areas of strategic m
anagem
ent and best practice
approaches.
•
Ireland’s high rate of VAT is a little price to pay
when considering its green image, high standards
of living and open economy.
WT
Str
ate
gie
s
•
Providing better training for SME m
anagers, a better
strategic approach to m
anagem
ent can be promoted
and a better understanding of the need for patent
applications to protect new
product development in
small software companies.
•
Managers
should em
ploy strategies
to reduce the
energy costs in the day to day business activities of
their companies.
•
Improving the countries infrastructure may im
pact
less on rising costs as the advantages of good road,
rail and broadband network w
ould compensate rising
employee and operation costs.
Ta
ble
2.5
.1 -
TO
WS
Ma
trix
.
Situational Analysis of the Irish Economy. The findings from the above TOWS analysis is based on the documented findings from the
Annual Competitiveness Report 2005, Forfas, the National Competitiveness Council and the authors analysis of this data.
33
2.6 Conclusion
The importance of R&D for the development of the Irish software market has been
repeatedly stressed by industry experts since 2004. While the government has never
denied the importance of R&D it has been criticised for not investing enough by way of
procurement of software from some of Ireland’s smaller software companies.
A recent report from ICT Ireland, predicts that employment in the ICT sector could
double if the right policies, including research support, are implemented. However the
lack of government procurement of technology and software from small companies
could affect this, (ICT, 2006). While such measures are critical to the development of
the Irish software development sector the government could make a significant
difference by acting on the recommendations of the ISA Government Procurement
Working Group.
In a 2005 interview Michelle Quinn director of the Irish Software Association (ISA),
stated that the lack of government procurement of software solutions from smaller
software companies is a having significant impact on increasing their growth chances to
‘Build’ and ‘Expansion’ stages of maturity. Quinn cites the UK government as being
proactive in this regard by supporting indigenous companies there, (Electric News,
2005b).
Brian Hanley, founder and director of Exoftware, reiterated this in subsequent interview,
pointing out that the public tender policy is far from helpful to indigenous companies
during the early stages of their development.
Hanley makes a number of suggestions worthy of government consideration that
include, ring-fencing smaller projects for smaller firms, providing incentives to the
bigger companies to sub-contract work to smaller companies (Mulqueen, 2005).
34
Peter McManamon one of the co-founders of a company called Ceva and the Chair of
the ISA Government Procurement Working Group argues that the government should
set aside 25 percent of its procurement for software to small software companies. Again
it’s a strategy that has worked in the UK as it has helped stimulate the software industry
by giving local companies the opportunity to get reference sites with government
customers. By getting their first sale they now have a reference site when going to
venture capitalist as they are viewed as a real company with real customers and tangible
products, (Collins, 2005).
Although Ireland boasts being the largest exporter of software in the world the
governments lack of support for software procurement to small companies is one area
that is damaging innovation and threatening the future success of the sector from
emerging software economies, that for now, have a lower cost of production and greater
future capacity to create software, (Moore’s, 2005).
Criticising the Government for failure to allocate funds for software procurement is only
one side of the argument. The ability of small software companies to seem like viable
option to potential customers when compared to more established companies is largely
down to management representation of those companies. There needs to be an air of
professionalism and confidence that they can deliver a quality product on time. Although
Start-up companies are not overly concerned with best practice, it is their ad-hoc
approach that reduces the chances of good quality and on time delivery of software
solutions. Similarly managers within small software companies often base decisions
solely by their own experience and personal beliefs. This is strongly influenced by the
entrepreneurial activity that dominates such a large proportion of Ireland’s software
sector. Wish fulfilment and a refusal to recognize the critical changes that are happening
in the World around them often lead to small companies accepting short term solutions
and as a result ignore the long term impact this could have on the company.
This thesis is very much concerned with focusing on this type of approach to software
development and software process improvement. The focus on ad-hoc approaches
35
throughout the SDLC reduces the time it takes for Start-up companies to enter the Build
and later the Expansion phases of maturity. The use of best practice will in the authors
view increase this chances of successfully making this transition and;
• better positions Start-up companies to create scale,
• reduce the chances of both task and code re-working and
• reduce fragmentation throughout the SDLC thus creating a more coherent SDLC that
will create a better product and satisfy the customer.
To better illustrate how Start-up companies can grow and develop it is important to
explore theory in the area of Software Engineering and Software Process Improvement,
so that valid arguments can be raised when analysing the research findings in Chapter 6.
The following Chapters 3 and 4 will now provide the documented research into the
principles of software engineering and SPI.
36
CHAPTER 3 – SOFTWARE ENGINEERING
3.1 Introduction
Software engineering is the profession of people who create and maintain software
systems by applying technologies and practices from computer science, project
management, engineering, application domains and other fields. The IEEE define
Software Engineering as "(1) the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software, that is, the
application of engineering to software," and "(2) the study of approaches as in (1)."
(IEEE Standard 610.12.)
Undoubtedly, the ability of any software development company to deploy an appropriate
software process is paramount to it being able to maintain and improving the
effectiveness of its software engineering practices. But as previously stated, this is
something many smaller companies find difficult, particularly the tailoring of existing
software process models to their needs and allocating sufficient resources to improve
their software development processes.
The main purpose of this Chapter is to present the key approaches to software
engineering and the role of the software engineer. The Chapter opens with a brief history
of the origins and rise in popularity in the software engineering field. This Chapter
focuses heavily on the main software development process models adopted by software
companies and highlights some of the positive and negative impacts of each.
Both Heavyweight and Lightweight models are presented. The Chapter concludes with a
review of software engineering initiatives in Ireland and highlights the growth of
lightweight methodologies within the field of software engineering.
37
3.2 The Origins of Software Engineering
Software engineering has evolved steadily from its founding days in the 1940s to the
present day. The term software engineering was first used in the late 1950s and early
1960s.
The late 1960’s saw the emergence of large commercial software systems. The best
documented was the OS 360 operating system for the IBM 360. Such large projects
highlighted the fact that building large software systems was materially different from
building smaller systems.
Difficulties in scaling up the techniques of small program development to large software
development, was the single biggest obstacle affecting the field. In 1968, the NATO
Science Committee sponsored two conferences on software engineering and this gave
the field its initial boost and marked the start of software engineering as a profession.
Throughout the 1960’s, 70’s and 80’s the field of software engineering continued to
come under heavy criticism by the so-called software crisis which further highlighted
many of the problems of software development. Many software projects ran over budget
and not to schedule and the term software crisis was used commonly in reference to the
inability to hire enough qualified programmers on such projects. The software crisis was
originally defined in terms of productivity, but evolved to emphasize quality.
For decades, solving the software crisis was paramount to researchers and companies.
Many software tools and formal approaches to software engineering were touted as
solutions to the software crisis. The debate on how to solve the crisis has been ongoing
since the 1970’s. The search for a single approach or tool to deliver success never
materialised with all known technologies and practices only making incremental
improvements to productivity and quality.
38
Today there are a range of tools and software processes available to improve a
company’s software development process. It would appear that throughout its relatively
short history, software engineering is both too complex and diverse for a single approach
to eradicating software project failure.
The result is a variety of models and approaches that in the authors view often lead to
misinterpretation within smaller software companies because these companies often lack
direction because of insufficient resources and poor strategic management practices.
In recent years, adopting best practice techniques, the rise in e-business solutions and the
ever growing demand for software solutions in smaller organisations has resulted in a
growing demand for simpler, faster software development methodologies. The focus
now is on methodologies that are able to produce software from requirements to market
quicker than competitors.
To compensate for this, lightweight development methodologies, such as Agile Software
Development (ASD) and Extreme Programming (XP), are aimed at simplifying many
areas of software engineering, including requirements gathering and reliability testing
for the growing number of small software systems being produced by such companies.
The following sections of this chapter explain in more detail some of the most common
approaches to software engineering and explore both lightweight and heavyweight
methodologies that are available to today’s software development companies.
39
3.3 Approaches to Software Engineering
Software Engineering is a discipline that has emerged from computer science and
engineering and is based on inter disciplinary theoretical and empirical methodologies.
Where computer science is concerned with theory and fundamentals, software
engineering is concerned with the practicalities of developing and delivering useful
software. This is what this chapter focuses on and it forms the basis for the research
conducted and documented in later chapters, notably Chapter 6.
Software engineering covers not only the technical aspects of building software systems,
but also management issues, such as directing programming teams, scheduling and
budgeting for software projects. The practice of Software Engineering is concerned with
all aspects of software production, i.e. the practicalities of developing and delivering
useful software. It is both the management and organizational issues that the author
recognizes as being pivotal areas in the transition of software companies from early
maturity (Start-Up) to established company (Expansion).
Yet, history would suggest that although approaches to software engineering have
largely focused on technical aspects and have neglected both the organisational and
management structures of companies developing software. It has only been in the late
1980’s that a process approach to software engineering has begun to emerge. In 1987,
the development of the CMM and of ISO 9000 marked the full emergence of the
software engineering process as a new discipline.
Describing both areas is important to the overall argument of this thesis and the author
also identifies the limitations of some models that fits well with the underlying
arguments of this thesis.
40
The table on the next page has been adopted from (Wang & King, 2000, pg. 19) and
breaks down the approaches to software engineering into the three areas of Technical,
Organisational and Management.
No. Approach Description Coverage of SE Problems
Technical Organisational Management
1 Programming
Methodologies
-Functional Decomposition
- Structural Programming
- OOD Programming
-Component based
Programming
High Low Low
2 Software
Development
Models
- Life Cycle Models
- Waterfall Model
- Spiral Model
- Rapid Prototype Model
- Other Combined Model
High Medium Low
3 Automated
Software
Engineering
- CASE Tools
- UML tool
- Other Tools
HIGH Low Low
4 Formal
Methods
- CSP
- SDL
- Z
- Clean Room
High Low Low
5 Software
Engineering
Processes
- CMM
- BOOTSTRAP
- ISO/IEC 15504
- SPICE
- SEPRM
High High High
Table 3.3.1– Approaches to Software Engineering (Wang & King 2000, pg. 19).
When looking at organisational and management methodologies the focus should be on
non technical areas such as project management, project estimation, project planning,
software quality assurance configuration management, requirement and contract
management, document management and human resource management. The table on the
next page outlines these various categories and the typical methods that can be attributed
to each.
41
No. Category Typical Methods
1 Project Management Methods Productivity-orientated, quality orientated, schedule-driven, standard process
models, benchmark analysis, checklist/milestones etc.
2 Project estimation/planning methods COCOMO model, function-points, program evaluation and review technique
(PERT), critical path analysis, Gantt Chart etc.
3 Software Quality Assurance Methods Process reviews, process audit, peer review, inspection, defect prevention,
subcontractor quality control, benchmark analysis process tracking etc.
4 Configuration Management Method Methods of Version Control, change Control, version History record, Software
Component Library etc.
5 Requirement/contract management
methods
Methods of system requirement management, software requirement
management, standard contractual procedure, subcontractor management,
purchasing management etc.
6 Document Management Methods Methods of document library, classification, access control, maintenance,
distribution etc.
7 Human Resource management
Methods
Methods of position criteria, career development plan, training, experience
exchange, domain knowledge development etc.
Table 3.3.2– Organisational and Management categories of Software Engineering. (Wang & King
2000, pg. 15).
As already stated by the author the lack coherent direction in organisational and
management activities within the indigenous software sector, is, in the context of this
thesis, a mitigating factor in preventing small Irish software companies maturing into
Build and Expansion companies.
The remainder of this chapter and Chapter 4 provide the documentary research that has
enabled conclusions to be drawn on the current software development processes
discussed here and software process improvement discussed in Chapter 4.
42
3.4 The Software Development Process
Software Engineering has continually evolved from its foundation in the 1940’s. This
has resulted in a continual evolution in the educational skills required by today’s
software engineering professionals.
In particular, software engineer’s involved in the development of enterprise wide
applications must have a diversity of skills and competencies that are documented in the
table below.
Steps Role Description Requirements Analysis and Definition
Client Contact Client Liaison Client Relations
Be able to discover client needs and translate them to software and system requirements
System Design Researcher Lead Designer Graphic Design Systems Analyst
Work effectively in interdisciplinary contexts, in particular to bridge the gap between computing technology and the client's technology and to interpret and respect extra-technical constraints Apply design and development methods and techniques as appropriate to realize solutions Design appropriate solutions, using responsible engineering approaches Evaluate designs and products
Program Design
Technical Specialist Lead Code Architect
Understand and be able to use current technical solution elements, including both specific tools, components, and frameworks and also abstract elements such as algorithms and architectures Learn new models, techniques, and technologies as they emerge; integrate knowledge from multiple sources to develop solutions to problems; serve as an agent of change for introducing new technology
Program Implementation
Team Leader Project Leader
Reconcile conflicting objectives, finding acceptable compromises within limitations of cost, time, knowledge; understand the nature of unstructured, open-ended problems
Program Coding
Developer Head Programmer .Net Developer J2EE Developer Web Developer
Program effectively, including code creation, component use, and integration of multiple subsystems
Software Training and Support
Mentor Liaison Technical Lead Lead Developer Programming Leader
Organize and lead development teams, including team-building and negotiation Learn new models, techniques, and technologies as they emerge; integrate knowledge from multiple sources to develop solutions to problems; serve as an agent of change for introducing new technology
Technical Writer
Documentation Leader Documentation Style Manager Documentation Content Manager
Communicate effectively, both verbally and in writing. Log all documentation so it can be accessed quickly/easily by all members of the software development team.
Testing Testing Leader Testing and Verification
Perform test cases on software developed, co-ordinate with end users to sign off on software tested/delivered.
Maintenance Version Controller Quality Assurance Code Reviewer
Be able to manage multiple versions of software written for various projects, ensuing correct versions are deployed for the next build. Review code regularly so that so that uniform code is writer, reducing the likelihood of bugs in code.
Table 3.4.1– Typical skill set of a Software Engineer.
43
Software Engineering is both a creative and a step by step process that often involves
many stakeholders, who produce many different kinds of products and as a result a
diversity of skills is needed.
Figure 3.4.1– Stakeholders of the Software development process
A key component in the software development process is communication between the
Customer, the Developer and the End User. Any communication breakdown between
these stakeholders, will inevitable result in project failure.
Stakeholder Description of Role
Customer This is the company, organisation, or person who is paying for
the software system being developed.
Developer This is the company, organisation or person who is building the
software system for the customer. This includes managers
needed to coordinate and guide the programmers and testers.
User This is the person or people who will actually use the system.
Table 3.4.2– Role of Stakeholders during the Software development process
From project inception right through to its delivery, a software system goes through a
gradual development and evolution. This process is said to have a life cycle, thus the
software development process is sometimes referred to as the software life cycle because
it describes the life of a software product from start to finish.
44
Many process models exist in Software Engineering Literature (Shari et al, 2001, pg 48)
cites the following as benefits of having a software process model;
• When a group writes down a description of its development process, it forms a
common understanding of the activities, resources and constraints involved in
software development.
• Creating a process model helps the development team find inconsistencies,
redundancies and omissions in the process and in its constituent parts. As the
problems are noted and corrected the problems become more effective and
focused on building the final product.
• The model should reflect the goals of development, such as building high –
quality software, finding faults early in development, and meeting required
budget and schedule constraints. As the model is built, the development team
evaluates candidate activities for their appropriateness in addressing these goals.
• Every process should be tailored for the special situation in which it will be used.
Building a process model helps the development team understand where that
tailoring is to occur.
There is nothing untoward about four benefits identified by above and each point should
in theory be obvious to seasoned software professionals. As documented in the early
sections of this chapter, the notion that a single approach to deliver success to a
company’s software development process never materialised. What did materialise
however, was a range of tools and processes that software development companies can
use and tailor to their needs. The following sections of the chapter consider such tools,
differences between them and their limitations.
45
3.5 Software Process Models
When software development companies create a software product, they need to follow a
sequence of steps to complete a set of tasks. These tasks can be viewed as the process, a
set of steps involving activities constraints and resources that produce an intended
output.
Every process model assumes system requirements as input and a delivered product as
output.
Figure 3.5.1– Input/Output from a typical Software development process.
Many such models have been proposed in Software Engineering. The purpose of this
section is to provide an overview of the most popular models and some of the
differences between each one.
3.5.1 Waterfall Model
The waterfall model is probably the most recognisable version of the systems
development life cycle model for software engineering. Often considered the classic
approach to the systems development life cycle, the waterfall model describes a
development method that is both linear and sequential, where each stage of development
is depicted as cascading from one to the other.
The figure on the next page as depicted by (Royce, 1970) implies that one development
stage should be completed before the next one begins. For example, when the
46
requirements have been gathered, analysed and documented from the customer, then the
development team can begin system design activities.
The Waterfall method can be very useful in helping developers lay out what they need to
do and its simplicity makes it easy to explain to customers the development process
regardless of their familiarity with software development.
However, several drawbacks have been discussed in literature in relation to the Waterfall
model. (McCracken & Jackson, 1981), state that the model imposes a project
management structure on systems development.
Figure 3.5.2 – The Waterfall Model (Royce, 1970)
47
The greatest criticism is that the model provides no guidance to managers and
developers on how to handle changes to products and activities that are likely to occur
during development.
For example, when requirements change during coding activities, the subsequent
changes to design and code are not addressed by the Waterfall Model.
Software evolves as problems become understood and possible alternatives are
evaluated. The waterfall is less informant of the on the typical back and forth activities
that generally lead to creating a final product. A possible solution to this is the
introduction of a prototyping sub-process to the software development process that
enables customers and developers examine some aspect of the proposed system and
decide if it is suitable or appropriate for the finished product.
3.5.2 Prototyping Model
As already stated the Waterfall model can be adjusted to include prototyping activities
so that understanding between developer and customer can be improved throughout the
process. By itself, prototyping can be the basis for quite an effective process model.
Figure 3.5.3 – The Prototyping Model (Boehm, 1988)
48
The prototyping model allows for all or part of a system to be constructed quickly so
that an understanding or a clarification of issues can be arrived at. It is similar to an
engineering prototype, in that requirements or design require repeated investigation to
ensure that the developer, user and customer have a common understanding, both of
what is needed and what is proposed.
The number of iterations between requirements, design and system may be eliminated,
depending on the overall goals of the development process. Evolutionary or incremental
approaches to software development have been acknowledged in literature. (Boehm,
1988) defines an evolutionary process model as a model whose ‘stages consist of
expanding increments of an operational software product, with the direction of evolution
being determined by operational experience.’ Prototyping can be seen as an evolutionary
principle, where the prototype is progressively transformed into the final application.
3.5.3 Spiral Model
The goal of the Spiral Model is to provide a framework for designing software processes
guided by the risk levels in the project at hand. (Boehm, 1988) viewed the software
development process in light of risks involved, suggesting that a spiral model could
combine development activities with risk management to minimize and control risk.
The Spiral Model overcomes the inflexibility associated with the standard Waterfall
Model. Often requirements are poorly understood and poorly specified and it is simply
not possible to provide completely elaborated designs early in the process.
What Boehm proposed is that there should be a few iterations of the development
process with more sophisticated prototypes being produced at each stage. This is
illustrated in the diagram of the Spiral Model shown in the figure above. A typical cycle
involves elaborating a portion of a product (e.g. performance, functionality, etc.). Each
cycle has distinct; requirements analysis, designs, development and test phases.
49
Figure 3.5.4 – Spiral Model of Software Development and Enhancement. (Boehm, 1988)
(Boehm, 1988) argues that the Spiral model can accommodate any process development
model, thus a software development team can choose to most appropriate development
model suited to their project circumstances, i.e. waterfall versus evolutionary for
example. The guiding principle behind this lies in the level of risk associated with each.
Risks are seen as adverse circumstances that may affect the development process and the
quality of the products being produced. Risk management is a discipline whose
objectives are to identify, address and eliminate software risk items before they become
either threats to successful software operation or a major source of expensive rework,
(Boehm, 1989).
50
The spiral model focuses on identifying and eliminating high risk problems by careful
process design, rather than treating both trivial and severe problems uniformly. Its main
characteristics are that;
• It is a cyclical process not linear;
• Each cycle of the spiral consists of 4 stages and each stage is represented by one
quadrant of the diagram on the previous page.
o Stage 1 identifies the objectives of the portion of the product under
consideration and alternatives to buying, designing or reusing any of the
software produced.
o Stage 2 involves evaluating the alternatives from stage 1 and potential
risk areas are identified and dealt with.
o Stage 3 consists of developing and verifying the next level product. In
less understood end-user applications, the next step may be evolutionary
resulting in several spiral turns to achieve the desired results.
o Stage 4 consists of reviewing the results of the stages traversed so far and
planning for the next iteration of the spiral if any exist.
• The radius of the spiral represents the cost accumulated so far in the process;
• The angular dimension represents the progress made in the process.
So far this chapter has focused on heavyweight methodologies of software development.
The common theme of heavy methodologies is their allegiance in supporting
comprehensive planning, thorough documentation, and expansive design.
Over the past few years lightweight methodologies, also referred to as agile
methodologies, have been gaining ground on the more traditional heavyweight
methodologies. These methodologies are discussed in the next section.
51
3.6 Heavyweight versus Lightweight methodologies
The measurement for success in lightweight methods is early and continuous deliverance
of working features and software to customers. In contrast, heavy methods depend
heavily on documentation, upfront planning, and close conformance to plan in order to
success. Some of the differences are adopted from (Ambler, 2002) and are presented in
the table below;
Light Methods Heavy Methods
Approach Adaptive Predictive
Success Measurement Business Value Conformation to plan
Project Size Small Large
Management Style Decentralized Autocratic
Perspective to Change Change Adaptability Change Sustainability
Culture Leadership-Collaboration Command Control
Documentation Low Heavy
Emphasis People-Orientated Process-Orientated
Cycles Numerous Limited
Domain Unpredictability/Exploratory Predictable
Team Size Small/Creative Large
Upfront planning Minimal Comprehensive
Return on Investment Early in the Project End of the project
Table 3.6.1 – Differences between Lightweight & Heavyweight Methods.
Some of the limitations of the light or agile methods are team and project size. It is
difficult to form large agile teams, since these methods rely heavily on collaboration,
synergism and creativity among team members. All these traits work well in small
software development environments with agile methods increasing the chances of an
early return on investment when compared to heavy methods in the same environment.
The next section looks at the philosophy behind using agile methodologies and the
models available to software development companies.
52
3.7 Agile Software Development
(Ambler, 2002) discusses a number of agile methodologies and practices in relation to
agile modelling. The core set of these include Crystal methods & Adaptive Software
Development (ASD), Dynamic Systems Development (DSDM), Feature Driven
Development (FDD), Scrum, and eXtreme Programming (XP). Many authors in the
Agile modelling field, participated in writing the Agile Software Development
Manifesto resulting in a common bond among practitioners of these approaches. The
points of the Agile Manifesto sum up the philosophies behind all Agile methods:
• Individuals and interactions over process and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
No. Category Description
1 Visioning A good visioning practice helps assure that agile projects
remain focused on key business values (for example, ASD's
product visioning session).
2 Project Initiation A project's overall scope, objectives, constraints, clients,
risks, etc. should be briefly documented (for example,
ASD's one-page project data sheet).
3 Short, iterative, feature-driven, time-boxed
development cycles.
Exploration should be done in definitive, customer-relevant
chunks (for example, FDD's feature planning).
4 Constant feedback Exploratory processes require constant feedback to stay on
track (for example, Scrum's short daily meetings and XP's
pair programming).
5 Customer involvement Focusing on business value requires constant interaction
between customers and developers (for example, DSDM's
facilitated workshops and ASD's customer focus groups).
6 Technical excellence Creating and maintaining a technically excellent product
makes a major contribution to creating business value today
and in the future (for example, XP's refactoring).
Table 3.7.1 – General Characteristics of Agile Methods (Highsmith, 2002).
53
Although many agile practices have been adopted with success widespread use of more
traditional heavyweight approaches such as the waterfall, prototyping and spiral models
remains to be seen. Educating small indigenous software companies about the potential
benefits agile software development could have on such companies could improve
common problems such as quality assurance, customer satisfaction and development
scheduling associated with the software development lifecycle.
For these reasons mentioned above it is important to provide a brief overview of the
Agile methodologies mentioned at the beginning of this section as they could provide
software companies in the ‘start-up’ phase of maturity with a best practice approach to
software development.
3.7.1 Crystal/Adaptive Software Development (ASD)
(Cockburn, 2001) is credited with creating the family of Crystal methodologies, such as
Crystal Clear and Crystal Orange as a ‘human-powered’ approach to software
development. Rather than a more process-oriented approach, software development is
centred on the team and individuals involved in the software process.
Crystal provides suggestions for team organisation and management with the main
objective being to reduce bureaucracy and paperwork while increasing teamwork,
personal satisfaction, and communication. Crystal methods seek to find the simplest and
most compact team structure and process for an organization, thus making the
development process more speedy and efficient.
(Highsmith, 2002) joins Cockburn in supporting not only a change in process, but a
change in lifestyle. Adaptive Software Development (ASD) focuses on preparing
organisations for a world where requirements change and flexibility is a necessity. The
process and structure of the organisation must itself be flexible enough to adapt to the
changing directions and evolution that a software project may take.
54
The practices of ASD are driven by a belief in continuous adaptation and accepting
continuous change as the norm. In ASD, the static plan, design, build life cycle is
replaced by a dynamic, speculate, collaborate, learn life cycle. It is a life cycle dedicated
to continuous learning and oriented to change, re-evaluation, peering into an uncertain
future, and intense collaboration among developers, management, and customers.
3.7.2 Dynamic Systems Development Method (DSDM)
DSDM is another methodology designed to respond to short delivery timescales and a
limited amount of resources. Like Crystal, DSDM strives to shorten communication
lines between customer, developer, and business stakeholders in order to provide a more
efficient software process.
The DSDM Consortium website states that DSDM is a development framework that
‘focuses on the priorities of the business and delivers what can safely be delivered
within the time and cost constraints of the project, in priority order determined by the
business needs and the objectives of the project’ (DSDM, 2006). Both coding and design
is iterative in order to receive maximum feedback from all stakeholders throughout the
development process, (Stapleton, 1995).
Time boxes are used to ensure that deadlines are adhered to and keep the development
team focused on what is most important in a given time box. An essential element in the
time box concept is priorities, meaning that all tasks in a given time box must be
prioritised. It must be possible to complete all tasks with the highest priority within a
comfortable time frame, but the time box will most likely not be long enough to
complete all tasks. This results in the most important tasks being completed and the
lowest prioritised tasks are skipped.
55
Figure 3.7.1– Time Boxes in Agile Development.
The model above describes the functional model iteration is a process of gathering and
prototyping functional requirements based on an initial list of prioritized requirements.
Non-functional requirements are also specified during this phase. Each iteration is
followed by a design and build iteration that refines the prototypes to meet all
requirements. On reaching the maturing stage a final release is made and the software
deployed onto a customers environment.
3.7.3 Feature Driven Design (FDD)
FDD follows the belief that a strong yet flexible design will create a process that is
better managed and thus more efficient. FDD divides a project into features which are
subsets of the project that contain customer value.
FDD creates design, code, and code inspection schedules that lack the details associated
with a system completely specified in the requirements phase by instead relying on
people and their roles to address the details as needed, (Coad et al, 1999).
The simplified design schedule serves as a bridge of communication between manager
and developer. The design schedule can be used to establish a baseline for productivity
and be used to estimate future product development and serve as an important
component of contract negotiation.
56
3.7.4 SCRUM
SCRUM is a set of values and practices that optimizes the development environment,
reduces organizational overhead, and closely synchronizes market requirements with
iterative prototypes, (Schwaber & Beedle, 2002). It is designed to be productive, where
working prototypes are delivered in thirty day time frames or sprints.
Work accomplished during the sprint is predefined by the development team and no
other work may be added during a sprint. The team can focus on a particular set of
features intensely for that period of time and produce a working prototype.
Once a sprint has been completed, a new set of features is analyzed and selected for the
next iteration.
SCRUM has been successfully used as a standalone development process, but can also
be used for other processes and to encourage productivity in failing projects.
3.7.5 eXtreme Programming (XP)
Today, Extreme Programming is probably the most widely used agile methodology. XP
consists of approximately twelve interconnected practices, making it the best defined
agile process. It has been adopted by development groups around the world, in a variety
of different companies, has inspired many books and is the subject of various
conferences around the world.
1. Planning Game 7. Refactoring
2. Small Releases 8. Continuous Integration
3. Customer Acceptance Tests 9. Collective Code Ownership
4. Simple Design 10. Coding Standards
5. Test-Driven Development 11. Sustainable Pace
6. Pair Programming 12. Metaphor
Table 3.7.2- The Twelve practices of XP.
57
XP is founded around small releases (approximately six months) with iterations of two
weeks during which developers implement ‘User Stories’, which are program features
specified jointly by customer and developer.
Customer collaboration and constant feedback are paramount to a successful XP
process. The customer needs to be involved in planning and is also on hand to answer
developer questions in order to produce a piece of software closely tailored to the users
needs.
The emphasis on testing, such as customer acceptance tests, pair programming, and test-
driven development, result in production code of higher quality and more reliability.
The robustness of XP combined with its lightweight approach to the software process
and substantial knowledge base has made it the most popular agile methodology with
practitioners in every domain of software engineering.
3.8 Conclusion
An Agile Software Development (ASD) life cycle has six basic characteristics; mission-
focused, feature-based, iterative, time-boxed, risk-driven, and change-tolerant
(Highsmith, 2002). For many projects, lightweight methodologies can be seen as an
iterative approach to software development especially when the requirements may be
unclear at the beginning, but the overall mission that guides the team is well articulated.
The mission driving the project provides boundaries rather that the final project
destination or end product. Without a good mission and a constant mission refinement
practice with the software development team, iterative life cycles can loose sight of the
end goal and result in little or no real progress being made.
The ASD life cycle focuses on results, not tasks, and the results are identified as
application features. Agile development defines a strategic capability, a capability to
58
create and respond to change, a capability to balance flexibility and structure, a
capability to draw creativity and innovation out of a development team, and a capability
to lead organizations through turbulence and uncertainty, (Highsmith, 2002)
One of the major drawbacks of agile development is misinterpretation and abuse of its
main teachings. For example, the practice of time boxing, addressed as part of DSDM,
or setting fixed delivery times for iterations and projects, has been abused by many who
use time deadlines. Time deadlines are often used to pressure staff into long hours, cut
corners on quality and as a result undermine the collaborative working environment
promoted by using agile development techniques.
It has been the author’s experience that the idea of time boxing can in fact have very
little to do with time and more to do with forcing hard trade-off decisions during
software development.
This again comes down to poor organisational and management practices of companies
that adopt an agile approach to their software development. If both are neglected then
the lightweight approach to software development can suffer in ways mentioned above.
However, good organisational and management practices that allow for an adaptive
development cycle can be easily accommodated for; not only in lightweight approaches
but also heavyweight approaches. As in (Boehm’s, 1998) Spiral development model, the
ability to analyse the critical risks drives the plans for adaptive iterations. ASD is also
change-tolerant, not viewing change as a problem but seeing the ability to incorporate
change as a competitive advantage.
Today, many indigenous Irish software companies want to be more agile. There is a
growing need for companies to be competent enough to create change for their
competitors and respond quickly to market conditions. They want to be innovative and
have the ability to plan for the future, but at the same time not be blinded by their plans.
The focus should be on delivering customer value, not adding the number of processes
they have in place. But the pressure to deliver value in a turbulent, ever-changing market
grows all the time.
59
All software development companies continually face stiff competition from global
competitors offering similar products that they may in fact not be as good as theirs.
Making sales is difficult, thus growth in such companies is slow, resources are limited
and attracting and retaining high quality engineers is proving more and more difficult.
The Effective Software Development (ESD) seminar recently organised by Enterprise
Ireland has looked to address and improve these organisational and management
constraints on Irish software companies. Such initiatives can achieve only so much, as
it’s primarily down to the companies themselves to improve existing practices and make
the transition from Start-up to Build and from Build to Expansion company.
Finally, the purpose of this chapter was to provide the reader with and overview of
heavy and light weight methodologies and the many tools that are available throughout
the software development process.
The Agile approach is gaining popularity in smaller development teams, but just like
heavyweight methodologies, it too requires a systematic approach and careful
consideration for each of the six basic characteristics that define it. The next chapter
focuses on software process improvement looks deeper into organisational and
management issues that can help address some on the shortcomings identified in this
section.
60
CHAPTER 4 - SOFTWARE PROCESS IMPROVEMENT
4.1 Introduction
Software Process Improvement (SPI) is a well known concept within the field of
software engineering and throughout the software industry itself. Its foundation stems
from the field of management science with particular emphasis on quality system
improvements. It has evolved steadily over time with (Shelwhart, 1939) first developing
the concept of plan-do-check act iteration which was later adopted in Japanese
manufacturing and renamed the KAIZEN method. This was later adopted by (Deming,
1980) to become the Deming cycle.
SPI is about continuously improving a software companies approach to software
management and development. Its aim is to provide companies with a repeatable and
predictable approach to software development that is flexible to market needs, guides
staff and management, minimizes risks, prevents costly mistakes, accelerate efforts and
encourages creativity.
In late 2005, Enterprise Ireland surveyed 30 Irish Software Development Companies, of
which none had a recognizable Software Development process although some had a
number of elements in operation. Given Ireland’s growing reputation and reliance on
software development for employment, it is important that Ireland’s indigenous sector
strive to defend and strengthen its position in the global market place. This is a point
echoed by the Minister for Trade and Commerce, Michael Ahern at the opening of
Enterprise Ireland’s Conference on Effective Software Development;
“we must continuously strive to defend and strengthen this position and perception if we
are to retain our reputation into the future. Irish companies need to be able to
61
consistently deliver good quality products and services on time and on budget -- all
characteristics required to compete effectively in today's global economy,"2
The purpose of this chapter is to provide the reader with an understanding of the
importance of SPI to Irish software companies by providing an overview of current
approaches to SPI and the benefits a best practice approach can have on the software
development process.
This chapter presents a number of SPI models that provide software development
companies with a framework to this best practice approach. The author was conscious of
documenting these models in detail as they later played a key role on the research
approach in Chapter 5 and on the data analysis in Chapter 6
4.2 Why the need for Software Process Improvement (SPI)?
As was already discussed in Chapter 3, many methodologies have claimed to ease the
software crisis that emerged from the 1960’s where budget overruns and poor quality
software hampered the software engineering profession. (Curtis & Paulk, 1993 pg.381)
claim that a “cultural transition rooted in the prowess of the individual programmer” is
to blame for the inability of software teams to manage a project which is further
exasperated by the sheer size of some of these projects.
A recent Enterprise Ireland survey to determine the use of software process
improvement methodologies in Irish software companies, it was found that between 30
and 40 companies had not implemented an SPI program.
(Curtis & Paulk, 1993) suggest that software companies should firstly focus on defining
their existing process and then select tools and methods to support these processes
before embarking on a full SPI program. They further claim that a well defined
2 Electric News.Net "Quality products key to Ireland's high-tech rep" .http://www.electricnews.net/news.html?code=9698845. Wednesday, May 31 2006
62
documented process can provide a solid foundation for long term productivity and
quality growth by integrating people, tasks, tools and methods.
There are a variety of assessment based programs that have been formulated and
developed in response to process improvement in software development. The most
widely known of these is the Capability Maturity Model (CMM). This model is
particularly popular in the United States, with software companies in other countries
adopting their own models. The European equivalent of CMM is known as
BOOTSTRAP.
Internationally, practitioners within the software engineering discipline recognized that
there needed to be a harmonization between the various approaches and the development
of an international standard. This standard became known as SPICE and today it is
commonly referred to as ISO/IEC 15504.
More recently in Ireland there have been a few well publicized reasons why some
changes to software management might be considered. Both the Irish Times and the
Irish Independent covered these stories in 2005, for example;
• Prison Service computer system costing €500,000 was abandoned, (Coulter, 2005).
• Garda computer summonses thrown out, (Labanyi, 2005).
• Millions overpaid to health staff under new pay system, (Donnellan and Reid, 2005).
• Health Service Executive (HSE) to suspend second computer project, (Reid, 2005).
Although such issues do little to shed light on what is actually happening, a review of
these high profile software projects might suggest there was an ad-hoc approach through
the SDLC or poor management practices that are less in line with best practice.
63
Evidence from these high profile cases would also suggest that not only are small
software companies at risk but larger companies are too, as it was primarily large
companies that were spearheading these projects. Although this thesis is primarily
focused with the need for start-up companies adopting best practice approaches to both
their software development and improvement processes, evidence would suggest that
larger companies could also benefit, but to a lesser degree.
64
4.3 Software Process Improvement Models
Software Process Improvement models are based on formal frameworks and promote the
use of systematic processes and management practices for software engineering, (Dutta,
Lee & Van Wassenhome, 1999). Approaches such as CMM, BOOTSTRAP and SPICE,
give software development companies the ability to understand, control and improve
their development processes. The purpose of an SPI assessment should be to compare
the current processes used in an organization with a list of recommended “best
practices”.
The above discussion yields the basis for an investigation of possible software process
improvement methodologies. The four SPI methodologies that are most inherent to this
Chapter and referred to in literature are, CMM, ISO 9000-3, SPICE and BOOTSTRAP.
The following paragraphs will discuss these methodologies in more detail.
But, before describing each methodology in greater detail, an interesting evaluation from
(Richardson, 1999) shows us that experience from many companies has shown that the
use of the CMM is very limited within small software development companies. She
points out that such models are continually tailored suit the needs of the development
team. The table below depicts the strengths and weaknesses (Richardson, 1999) gives of
three of the four models under discussion here.
Model Strengths Weaknesses
CMM • Improves software process
• Specific set of guidelines
• Assessment is expensive
• Lack of improvement model
• Tailoring required for small
• No credit for higher levels
• One-dimensional
ISO 9001
• Market-driven
• Internationally recognised
• Recognised outside software community
• Improves software process
• Not designed for software
• Results in cumbersome procedures
• Lack of improvement model
• One-dimensional
SPICE • Developed from existing models and experiences
• Credit for higher levels
• Specific set of guidelines
• Expensive assessment
• Lack of improvement model
• One-dimensional
Table 4.3.1– Strengths and Weaknesses of SPI Models (Richardson, 1999).
65
4.3.1 Capability Maturity Model (CMM)
Based on best practices from industry, the Software Engineering Institute (SEI)
developed the Capability Maturity Model (CMM) in the early 1980’s. The model was
originally developed to assess the software development process of third party suppliers,
of the US Department of Defence; however, this model also helped those suppliers to
improve their process. Organisations are supported with the CMM to improve the
maturity of their software process through an evolutionary path, of five maturity levels,
from 'ad hoc and chaotic' at level 1 right through to a 'mature and disciplined' at level 5.
As s Software Company becomes more mature, risks are expected to decrease and
productivity and quality are expected to increase.
Figure 4.3.1– Capability Maturity Model (CMM). (Paulk et al. 1993).
Each CMM maturity level contains a set of Key Process Areas (Kappa’s) which describe
the main capabilities for that level. The Kappa’s of the CMM are listed in the figure
below.
66
Level Description Key Process Area (KPA) 1. Initial
The software process is characterised as ad-hoc, occasionally or chaotic. Few processes are defined, and success depends on individual effort and heroics.
2. Repeatable Basis project-management processes are established to track cost, schedule and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.
• Requirements management
• Software project planning
• Software project tracking & oversight
• Software subcontract management
• Software quality assurance
• Software configuration management
3. Defined The software process for both management and engineering activities is documented, standardised, and integrated into a standard software process for the organisation. All projects use an approved, tailored version of the organisation’s standard software process for developing and maintaining software.
• Organisation process focus
• Organisation process definition
• Training program
• Integrated software management
• Software product engineering
• Inter-group co-ordination
• Peer reviews
4. Managed Detailed measurements of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.
• Quantitative process management
• Software quality management
5. Optimising Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.
• Defect prevention
• Technology change management
• Process change management
Table 4.3.2– Key Process Areas of the CMM (Paulk et al. 1993)
A suite of models developed by the SEI including the SW-CMM, the Systems
Engineering Capability Maturity Model and the integrated product Development CMM
have recently been merged and extended into an integrated CMM called CMMI. The
CMMI provides two views of capability.
• A Staged View gives five levels of evolution towards organisational
maturity. These are Initial, Managed, Defined, Quantitatively managed and
Optimising.
• A Continuous View provides six levels of process capability. These are
Incomplete, Performed, Managed, Defined, Quantitatively managed and
Optimizing. (CMMI Product Team 2002 p .18 -9)
67
The SEI claims the CMMI model improves upon the best practices of previous models
in many important ways (Goldenson & Gibson, 2003). CMMI best practices enable
organizations to do the following;
• Link management and engineering activities more explicitly to business
objectives.
• Expand the scope of and visibility into the product lifecycle and engineering
activities to ensure that the product or service meets customer expectations.
• Incorporate lessons learned from additional areas of best practice, (i.e. risk
management, supplier management)
• Implement more robust high maturity practices.
• Address additional organizational functions critical to its products and
services.
• More fully comply with relevant international standards such as ISO 900 and
ISO/ IEC 15504. (Chrissis, Konrad & Shrum 2003; CMMI Product Team
2002)
4.3.2 ISO 9000
Another well-known methodology for SPI is the ISO 9000 approach. The assumption
behind the ISO 9000 standards is that a well-managed organisation with a defined
engineering process is more likely to produce products that consistently meet the
purchaser’s requirements, within schedule and budget, than a poorly managed
organization that lacks an engineering process.
ISO 9001 describes ‘Quality systems - model for quality assurance in
design/development, production, installation and servicing’. A representation of the
structure of the ISO 9000 standards is provided below.
68
Figure 4.3.2– Structure of the ISO 9000 standards.
ISO 9001 is a set of quality system requirements that consists of twenty clauses that
represent requirements for quality assurance in design, development, production,
installation and servicing that defines which aspects of a quality system have to be
available within an organisation.
As ISO 9001 was designed to be used in different industrial sectors, ISO 9000-3 was
added specifically for software-development. ISO 9000-3 provides guidelines for
applying ISO 9001 to the specification, development, supply and maintenance of
software (ISO 9000-3, 1997).
69
The requirements for ISO 9000-3 certification are divided over twenty requirements
classes;
No. N0. Guideline classes
4.1 Management responsibilities
4.2 Quality system requirements
4.3 Contract review requirements
4.4 Product design requirements
4.5 Document and data control
4.6 Purchasing requirements
4.7 Customer-supplied products
4.8 Product identification and tracing
4.9 Process control requirements
4.10 Product inspection and testing
4.11 Control of inspection equipment
4.12 Inspection and test status of products
4.13 Control of non-conforming products
4.14 Corrective and preventive action
4.15 Management responsibilities
4.16 Handling, storage and delivery
4.17 Control of quality records
4.18 Internal quality audit requirements
4.19 Training requirements
4.20 Servicing requirements
4.21 Statistical techniques
Table 4.3.3- ISO 9000-3 Guideline classes (ISO 9000-3, 1997).
Receiving ISO 9000-3 certification assures customers that in an audited company all its
processes and work instructions documented conform the ISO requirements, and that
these processes and work instructions are being followed on a continuous basis.
ISO certification does not give any guarantee for product quality, it only indicates that
the procedures are used to a certain extent.
70
4.3.3 BOOTSTRAP
The BOOTSTRAP method (Kuvaja & Bicego, 1994; Bicego et al., 1998) is the result of
a European project under the auspices of the European Strategic Programme for
Research in Information Technology (ESPRIT). It provides an alternative for
organizations that are interested in improving their software development process and
attaining ISO 9001 certification, as it combines and enhances the methods provided by
the CMM and the ISO 9000 quality standards.
Figure 4.3.3– BOOTSTRAP methodology (Kuvaja & Bicego, 1994)
71
The basis of the BOOTSTRAP methodology is established by CMM. Like the CMM, an
assessment is based on five maturity levels, but the BOOTSTRAP method uses a
different scale to measure an organisation or projects overall strengths and weaknesses.
The ISO 9000 quality standards ISO 9001 and ISO 9000-3 are incorporated in the
methodology because they provide guidelines, unlike CMM, for a company-wide quality
system.
BOOTSTRAP distinguishes between the three areas of Technology, Methodology and
Organisation, which help identify the maturity levels of an organization.
The methodology is further sub-divided into a Life-cycle dependent, Life-cycle
independent and Process related areas, of which the life-cycle independent area is further
divided into Management, Support and Customer-supplier.
For each area in this BOOTSTRAP tree, a number of processes are defined. Each
process has a number of ‘key-practices’ that need to be addressed for that process.
Furthermore, each process has a capability dimension, which identifies the current status
of that process on a scale from 0 to 5.
72
4.3.4 Software Process Improvement & Capability Determination (SPICE)
SPICE is a major international initiative to develop a Standard for Software Process
Assessment (ISO 15504, 1998). It was established as a project to develop draft
standards, trial the developing standards and to promote awareness of the developing
standard (Rout, 1996). The SPICE project is developing the ISO/IEC 15504 standard to
address all processes involved in software acquisition, development, operation, supply,
maintenance, and support and has been created to be aligned closely with (ISO/IEC
12207, 1995) software life cycle processes. ISO 15504 is used as a reference framework
for software process capability determination. It is based on other popular approaches
already discussed, namely BOOTSTRAP, CMM and ISO 9001.
4.3.4.1 The ISO 15504 framework
There are two dimensions of the ISO 15504 reference model, the process dimension and
the process capability dimension. The process dimension includes measurable objectives
for each process and relates to the software lifecycle model (ISO 12207).
The ISO 15504 technical report outlines a roadmap for the implementation of best
practice in software engineering by defining 40 processes divided into 5 categories,
customer- supplier, engineering, support, management and organization. The processes
are made up of 24 main processes and 16 sub processes. The process capability
dimension is measured by capability levels, which is characterised by a set of attributes
that work together to provide a major enhancement in the capability to perform a
process.
The process capability of each defined process evaluates to what extent the process
achieves its defined purpose and objectives, (SPIRE, 1998). For each process, capability
is measured in 6 levels from incomplete, performed, managed, established, predictable
and optimizing. These capability levels represent milestones along the road to software
process improvement.
73
Table 4.3.4 – ISO 15504 Framework, (ISO/IEC TR 15504-2 1998, pg.5).
Process Group Basic Processes Component Processes
Primary Life Cycle Processes
Customer CUS. 1 Acquisition CUS 1.1 Acquisition Preparation
CUS 1.2 Supplier Selection
CUS 1.3 Supplier Monitoring
CUS 1.4 Customer Acceptance
CUS.2 Supply
CUS.3 Requirements Elicitation
CUS.4 Operation CUS 4.1 operational Use
CUS 4.2 Customer Support
Engineering ENG.1 Development ENG 1.1 System Requirements Analysis
and Design
ENG 1.2 Software Requirements
Analysis
ENG 1.3 Software Design
ENG 1.4 Software Construction
ENG 1.5 Software Integration
ENG 1.6 Software Testing
ENG 1.7 System Integration and Testing
ENG.2 System and Software
Maintenance
Supporting Life Cycle Processes
Support SUP.1 Documentation
SUP.2 Configuration Management
SUP. 3 Quality Assurance
SUP.4 Verification
SUP.5 Validation
SUP.6 Joint Review
SUP.7 Audit
SUP.8 Problem Resolution
Organisational Life Cycle Processes
Management MAN. 1 Management
MAN.2 Project Management
MAN .3 Quality Management
MAN.4 Risk management
Organisation ORG.1 Organisational Alignment
ORG. 2 Improvement ORG 2.1 Process Establishment
ORG 2.2 Process Assessment
ORG 2.3 Process Improvement
ORG. 3 Human Resource Management
ORG. 4 Infrastructure
ORG.5 Measurement
ORG.6 Reuse
74
4.4 Critical Success Factors for SPI
Introducing an SPI initiative needs careful planning, gradual introduction, be properly
managed and the adoption of all stakeholders in the company. (Zahran, 1998, pg. 79)
states that the following factors need to be considered to ensure the success of an SPI
effort;
• Set realistic expectations for senior management.
• Secure management Support. Educate them and highlight the potential benefits to
them resulting from a disciplined process.
• Get the buy-in from and involvement of project managers and software engineers.
• Treat process improvement as any other project with budget, milestones, committed
resources, allocated resources, defined deliverables and dedicated project
management.
• Process Improvement plans should follow a process improvement roadmap so
everyone will be aware of the target end state.
• Continuous process improvement should be considered a journey and not a
destination.
• Measurement of staff performance and reward schemes should be linked to process
performance.
• Process performance should be evaluated in terms of the degree to which the process
goals have been achieved.
• Ensure continuous alignment between process goals, project goals and business
goals.
• Involve everyone in the organisation in process improvement activities.
The success of using such models described in the last section have been reported and
documented. The most widely reported survey of best practice in Europe was that
conducted by the European Software Initiative (ESI).
In 1995 the EU launched the European System and Software Initiative (ESSI) program.
Its aim was to promote testing and deploying software best practices in the hope that
they could realize the benefits that this could offer them.
75
The ESSI developed the Software Best Practices Questionnaire (SBPQ) to collect data
for the ESSI program. The SBPQ represent a conceptual view of existing software
engineering practices and comprises a subset of core software development practices
from for four models mentioned. The five best practice areas covered by the SBPQ are;
• Organisational Issues, covering project management, change control and training
programmes for managers.
• Standards and Procedures, formal assessment of benefits and risk management,
reviews, independent audits, coding standards, formal handover, test planning.
• Metrics, Records of actual and estimated resources, error sources, test efficiency,
computer performance, project tracking.
• Control of the development process, Accountability for estimates and schedules,
requirements management, control of code and specification changes, regression
testing.
• Tools and Technology, Use of design notations, automated testing tools, prototyping,
data dictionary, Project Management tools, (ESSI, 1997b).
There are significant differences across the five areas of the SBPQ in relation to take up
levels, suggesting that some companies paid more attention to some areas than other did.
(Dutta & Van Wassenhove, 1997a) have criticised the survey for two reasons. Firstly,
they argue that it over looks important issues relating to organizational and custom-
supplier relationships and secondly that it does not include practices associated with
high maturity organizations such as CMM level 4/5.
Nevertheless the study yielded valuable findings over the three year period from 1995 to
1997. The final survey in 1997 generated 397 responses (ESI 1997) and showed a wide
variation in both awareness and application of process improvement techniques. Overall
the survey yielded an average level of 51% which would imply that at best, companies
surveyed adopted half of all the best practices in the SBPQ.
76
4.5 Implementing a national SPI Effort
The author is confident that with the support of Enterprise Ireland, the implementation
of a national software process improvement program is achievable in the short term with
many initiatives and support groups already in place and already highlighted in Chapter
2 page 21.
The need for software process improvement is beneficial for both the long term needs of
the companies undertaking the program and for the economy. In his presentation to
companies at the 2006 SPI conferences in Dublin and Cork, Eugene Connolly cites the
following reasons why companies need to improve their software processes;3
• Response from the 2005 SPI Conferences
• A Subsequent Survey indicated that there was a low level of SPI knowledge
• Establish Irish Software Industry as centre for:
� Consistency, Quality and ‘on-Time’
• Increasing demand from Marketplace
• Provides Competitive Advantage
• Assists Productivity Improvement
• Promotes Management & Control of process
• Encourages effective use of resources
Ireland would not be alone in implementing a national SPI initiative. The Danish
government participated in a national initiative to facilitate the use of such approaches as
CMM and BOOTSTRAP within the software sector there. This collaboration ran over a
three year period from 1997-1999.
As part of its effort, four software companies were identified and the following
questions relating to software process improvement were addressed;
3 see http://www.enterprise-ireland.com/NR/rdonlyres/BBD81B5F-F543-466D-A663-00A219492DC9/16766/SPIRoadmap.ppt#2 Roadmap to Establishing a “S P I” Culture
77
• Modelling. Understanding software development processes, the conditions under
which they are performed, and their capability to develop quality software?
• Measurement. Assessing the capability to develop software, identify appropriate
improvement areas and strategies and measure the effect of the implemented
improvements?
• Change. Managing change. How to organise and carry out sustainable initiatives
to improve an organisations capability to develop quality software?
A number of lessons were learned from by the undertaking of this study and these are
listed below (Johansen, 1999),
• Data-driven interventions motivate and provide insight
• Maturity can be assessed in different ways
• Establishment of a metrics program is a project in itself
• Process improvement is organisational development
• Process improvement initiatives should set an example
• Process improvement must lead to visible results
• Process improvement requires dynamic organisation
• Management must play an active role
• There are many roads to improved project management
• Each organisation must make its own experiences
When looking at the lessons learnt by the Danes, it would be beneficial for Irish
software companies to bear each point in mind so as to effectively introduce a program
of software process improvement.
Recognising the need for the adoption of an SPI initiative in Ireland is already well
underway. A series of collaborating networks and research institutes have been
established since the turn of the century with some of the more well established listed
below;
78
• ITAG (IT at Galway)
• Digital Enterprise research Institute (DERI) Galway
• Lero (aka ISERC) based in UL
• ISA & Momentum (N. Ireland. version of ISA)
• SPIN (SPI Network) being established
• Centre for Software Engineering CSE based in DCU.
• European Software Institute & Software Engineering Institute
4.6 Conclusion
The importance of Software Process Improvement is today recognised by the Irish
government as a major initiative to growing and improving the indigenous software
sector in Ireland. This chapter along with the previous chapter have dealt with both the
software development process and software process improvement, the people involved
and their functions. What has struck the author in reviewing research in both areas was
the continual reference throughout the history of software engineering to the idea of a
software crises and its close association with poor productivity in software companies
resulting in poor quality software products.
Today, the indigenous software sector in Ireland could inevitably face a similar crisis if
software companies do not recognise the need for improving both their productivity and
quality systems. Although the term ‘software crisis’ was first coined back in the early
1960’s, almost half a century on evidence in Ireland suggests that the government and
organisations alike are still tackling this very same issue. Both the government and
Enterprise Irelands focus is now on educating companies on how to adopt a best practice
approach to software development and SPI.
In order to establish how both impact on the indigenous software sector, the author uses
different methods of research to gather the relevant data to explore and analysis the
finding s in greater detail. Chapter 5 outlines in detail the manner in which thesis
research was conducted.
79
CHAPTER 5 - RESEARCH METHODOLOGY
5.1 Introduction
The chapters so far have analysed the existing practices and knowledge in the areas of
software engineering and software process improvement. In this chapter the focus shifts
to the research methodologies used as part of this thesis. The first section of this chapter
introduces the principles of research, while the remainder of the chapter explains the
rationale behind the research methods chosen and also how it was designed and
executed.
This chapter illustrates the research strategy, research methods, the choice of research
instruments and how the research was done. This chapter is important as it outlines the
manner in which the research was conducted and how the data was collected. The author
feels that this will allow for greater judgements to be made on the accuracy of the
research and whether or not any credibility should be given to its findings or
conclusions.
5.2 Research Methodology
Before researching the chosen areas of this thesis, some key decisions in relation to the
strategy and methods to be used in compiling the research needed to be taken. In
designing and executing the research approach, the author used a check list approach so
that all eventualities were considered when conducting the research design. Using this
approach meant that the minimum requirements were easily attained and critical factors
associated with good research were not overlooked.
The author was well aware that different research methods can be used for a variety of
purposes, which are dependent on the context for which the research occurs. The author
realised early on that applying a variety of methods would, in his view, provide for
80
better interpretation and validation of the final research results. The benefits of a multi-
method approach are promoted by (Morrison & George, 1995, pg 90) who argue that an
‘interdisciplinary, multi-dimensional, multi-faceted approach to research involving
software development provides a vehicle for mutually beneficial research among both
organisationally-orientated and technically-orientated researchers.’
The table below is adopted from (Denscombe, 2003, pg.5) and illustrates factors that
need to be considered in order to make key decisions about research used for this thesis.
Issue Factors to be Considered
Relevance • Is the research significant in relation to current issues on society?
• Will the research build upon existing knowledge about the topic
Feasibility • Is there sufficient time for the design of the research, collection of data and
analysis of results?
• Will the resources be available to cover the costs of the research?
• Will it be possible and practical to gain access to necessary data (people,
events, documents)?
Coverage • Will the questions cover the full range of issues?
• Will an adequate number of diverse people and events be included?
• Will it be reasonable to make generalisations on the basis of the data
collected?
• Is it likely that there will be an adequate response rate?
Accuracy • Will the data be precise and detailed?
• Are respondents likely to give full and honest answers?
• Will the investigation manage to focus on the most vital issues?
Objectivity • Can I avoid being biased because of my personal values, beliefs and
background?
• Will the research be approached with an open mind about what the findings
might show?
Ethics • Can I avoid any deception or misinterpretation in my dealings with the
research subjects?
• Will the identities and the interests of those involved be protected?
• Can I guarantee the confidentiality of the information given to me during the
research?
Table 5.2.1 – Key research Decisions (Denscombe, 2003, pg. 5)
81
Recognising the significance of using more that one method of research the author also
looked at the advantages and disadvantages of various research methods and their
relevance in relation to the chosen topic area.
The table below provides a brief summary of the advantages and disadvantages of
various methods that were taken into consideration when choosing the appropriate
research instruments.
Method of Research Advantages Disadvantage
Questionnaire, Survey • Reduced Cost
• Wide Coverage
• Standardised answers
• Pre-coded answers
• Eliminated effect of personal
interaction
• Poor response rate
• Incomplete or poorly completed
answers
• Limit Nature of answers
• Cannot check truth of answers
Structured Interviews • Depth of Information
• Insights
• Equipment
• Informant’s Priorities
• Flexibility
• Validity
• High response rate
• Therapeutic
• Time consuming
• Data analysis – non standard
responses
• Reliability
• Interviewer effect
• Inhibitions
• Invasion of privacy
• Resources
Systematic observation • Direct Data collection
• Systematic and rigorous
• Efficient
• Pre-coded data
• Reliability
• Behaviour, not intentions
• Over simplifies
• Contextual Information
• Naturalness of the setting
Participant Observation • Basic Equipment
• Non-interference
• Insights
• Subjects points of view
• Access
• Non-interference
• Reliability
• Representative ness of the data
Documentary research • Access to data
• Cost effective
• Performance of data
• Credibility of source
• Secondary data
• Social Constructions
Table 5.2.2 – Advantages and disadvantages of Methods of Research.
82
A good research design provides a framework for the collection and analysis of data. It
represents a structure that guides the execution of a research method and the analysis of
the subsequent data (Bryman, 2001, pg.28.).
A combination of qualitative and quantitative methods is seen by (Iversen et al. 1998 pg.
464) as providing the advantages of both triangulation and synergy. In the area of
software engineering, researchers such as (Carver, 2003) have urged the use of
quantitative analysis focusing on statistical analysis of numerical data as well as
qualitative analysis focusing on textual and numerical data.
5.3 The Choice of Research Method
The main research strategy used in investigating the chosen topic is represented through
Case Studies. The author took the decision to use this strategy as it enables a thorough
examination of the topic area of this thesis and as a consequence creates a greater
opportunity to discover areas that may not have been apparent through more superficial
research.
The use of a Survey and in-depth interviews gave a broader view of the focussed
industry area and gave a more detailed view of the companies that were being examined.
This approach to the research used mixed methods as defined by (Gallivan, 1997) as it is
empirical research using at least two different methods for collecting data. One
collection method is quantitative, the Survey, and the other is qualitative, case study.
Triangulation was then used to corroborate data produced by the different methods of
research mentioned above. In the author’s opinion, this mixed method approach provides
for a richer set of findings and an opportunity to compare best practice survey results
with the results from the chosen process improvement plan, in this case the ISO 15504
framework.
83
5.4 Survey and Interview Methods
The first method used in researching the chosen area involved the use of a survey as the
basis for a study to try and identify problem areas within the targeted software
development companies. It was hoped that the results of this could answer the first
research question in relation to the extend at which software development companies are
using best practice techniques and if the organisation structure or company resources
play a part in the results obtained from these companies.
Survey research ‘comprises a cross-sectional design in relation to which data are
collected predominately by questionnaire or by structured interview on more than one
case and at a single point in time in order to collect a body of quantitative data in
connection with two or more variables which are then examined to detect patterns of
association’ (Bryman, 2003, pg. 49).
The main objective of the survey is to determine the extent of adoption of software
engineering ‘best practices’ for each company surveyed. Following this a descriptive
study, known as a correlation, which entails the collection of data in order to determine
whether an association exists between two or more quantifiable variables was carried
out.
Interviews were chosen by the author primarily because they provide more of an in-
depth focus and insight into the topic under discussion, based on information provided
by fewer informants.
(Merton, Fiske and Kendall, 1956) refer to a focused interview as and interview using
predominantly open questions to ask interviewees questions about a specific situation or
event that is relevant to them and of interest to the researcher (Bryman 2002, pg. 119).
The interviews were conducted on an informal level before the Survey had been sent to
each of the companies under review. As part of the interviews, the author asked
individuals from each company four questions (see Appendix C) into their thoughts on
84
software process improvement and its effect on their company. The author decided on
this as this would give him a good indication on whether or not the survey would be
received positively. After receiving the survey results, a more focused interview
approach was conducted to gather and understand in more detail some of the answers
given in the survey.
The interviewees were not recorded, instead the author wrote notes immediately after
each one so that the answers given were fresh in his mind and so reduced the need to
contact the interviewees again if any ambiguity arose to the initial answers given in the
survey.
5.5 Survey Design
To overcome time constraints, the author took the decision to use the questions from the
ESI Software Best Practice Questionnaire (SBPQ) in designing the survey. In was felt
that this would give a more thorough coverage of practices for each company under
examination and as a result provide for a better examination of current practices.
Before the questionnaire was sent to all the companies, the author took the decision to
pre-test its structure and contents with two former work colleagues.
The author was aware that some of the questions may have caused misinterpretation and
as a result may have resulted in unclear or invalid responses. As the Survey is almost ten
years old the author felt that it may be better to change some of the questions slightly to
over come this problem.
The second point that was made was that the flow of the questionnaire and the heading
of the ESI (SBPQ) may also cause some confusion and as it is, do not necessarily flow
or follow the actual steps of a typical software development life cycle.
To over come this the author decided to group the questions under five new headings of
Requirements and Design, Code and Test, Configuration Management, Estimates and
Schedules and Project Management and Training.
85
5.6 Case Study
Case studies ‘focus on one or more instances of a particular phenomenon with a view to
providing an in-depth account of events, relationships, experiences or processes
occurring in that particular instance’ (Denscombe, 2003 , pg 32). The choice of a case
study approach fits well with the research needs of this thesis as it concentrates efforts
on just a few examples.
From the outset of writing this thesis the author considered various reasons as to the
suitability a case study would have for the purposes of the research. This goes back to
the argument that a company in the start-up phase needs to implement a program of
process improvement to sustain growth and move up the value chain.
The rationale for choosing the specific case in this thesis is that it contains critical
elements that are significant in that each one shows the impact a program of best
practice could have on a start-up company’s overall software development practices.
Initially the author decided to carry out four case studies, one for each of the companies
surveyed. However due to both time constraints and the fact that this thesis’s primary
objective is to present a best practice framework for sustaining growth in start-up
companies, the author took the decision to document just one case.
Although the Survey Method allowed each of the four companies to be examined in
terms of their approach to best practice software development, the single case chosen
provided evidence relating to the whole hypothesis of the authors research and as such
allowed for deeper discussion.
The table below illustrates the companies examined as part of the Survey, with
Company D being chosen as the Case study as it is at the Start-up phase in its maturity
and best illustrates the research objectives of this thesis, supported by the surveys
results.
86
Table 5.6.1– Case Study and Survey used in Research.
Case Study Stage of
Maturity
Type of
Business
Response to Survey
Company A
Enterprise Financial
Services
Software
Provider
Stage Total Yes NO
Requirements & Design 6 4 2
Code & Test 9 9 0
Configuration & Mgt. 5 5 0
Estimate & Schedules 8 6 2
Project Mgt. Training 10 8 2
38 32 6
Company B
Build Financial
Services
Software
Provider
Stage Total Yes NO
Requirements & Design 6 4 2
Code & Test 9 7 2
Configuration & Mgt. 5 5 0
Estimate & Schedules 8 5 3
Project Mgt. Training 10 7 3
38 28 10
Company C
Build/Start-Up Financial
Services
Software
Provider
Stage Total Yes NO
Requirements & Design 6 5 1
Code & Test 9 5 4
Configuration & Mgt. 5 3 2
Estimate & Schedules 8 5 3
Project Mgt. Training 10 7 3
38 25 13
Company D
Start-Up Financial
Services
Software
Provider
Stage Total Yes NO
Requirements & Design 6 4 2
Code & Test 9 4 5
Configuration & Mgt. 5 2 3
Estimate & Schedules 8 1 7
Project Mgt. Training 10 4 6
38 16 22
By incorporating both the interview/survey with the case study approach, the author was
able to gather a large amount of data which later allowed for data validation through a
process of triangulation.
The main difficulty the author found with the Case study approach was getting access to
Case study settings. It was difficult to get access to documentation and people without
running into ethical difficulties such as company confidentiality. (Denscombe, 2003 pg.
38) states that ‘good case study research needs to contain a clear vision of the boundaries
to the case and provide an explicit account of what those boundaries are’. To overcome
this, the author used the survey as a way of defining those boundaries and in practice this
approach made it easier to decide the sources of data to incorporate in the case study and
which to exclude.
87
The case study used as part of this research is an indicative sample of companies
involved in software development. By analysing the case study, the author was able to
identify problems and achievements within the case and to seek explanations for
potential difficulties arising throughout their software development process that may
inhibit future growth and expansion.
5.7 Triangulation
Such an approach to research attempts to cancel out the limitations of one method by the
use of another method in order to cross check the findings. The term triangulation refers
to an approach that uses ‘multiple observers, theoretical perspectives, sources of data
and methodologies’ (Denzin 1970, quoted in Bryman, 2003 pg. 291). It was originally
conceptualised by (Webb, 1966) as an approach to the development of measures of
concepts, whereby more than one method would be employed in the development of
measures, resulting in greater confidence in findings (Bryman, 2003 pg. 291).
For this thesis, the triangulation approach allowed the findings to be corroborated and
questioned even further by comparing the data produced by different methods. The
literature review together with the issues arising from the survey provided both the
direction and approach taken toward the case study research. Similarly, the case study
findings were consistent with the survey and interview results and also with that
obtained from the documentary research.
5.8 Documentary Research
A major objective from the outset of this thesis was an examination of existing literature
on the subject of software engineering practices and software process improvement. As
both subject areas are very broad the author was well aware that not all subject matter
could be covered in this thesis. However, the author is satisfied that enough was covered
to provide both the author and reader with a good understanding of the wide range of
principles of software engineering and their impact on Irish software industry for the
purposes of this thesis.
88
The sources of documentary research were all written sources and included books,
journals, newspapers, government publications and websites. When carrying out this
method of research the author was conscious of both the credibility of the documents
and their applicability for discussion in this thesis.
The author is satisfied that this method of research was effective with the added benefit
of allowing the author to explore research questions related to the chosen areas without
the author having to go through the process of collecting the data himself.
5.9 Conclusion
This research was chosen so as to identify the implications a best practice software
engineering approach can have on a software development company. In turn this will
help highlight both the advantages and disadvantages of the same in the next chapter.
The review of existing literature on the chosen topic areas played an important part in
this research, thus allowing for credible research in its analysis.
Although this chapter dealt in detail with the methodology of this thesis, further
discussion of the research in the next chapter will bring to an end this process by
analysing the findings of this research.
The research areas of survey/questionnaire and the case study that were discussed here,
form the basis for deeper discussion when analysing the data and findings in the next
chapter.
89
CHAPTER 6 – DATA ANALYSIS
6.1 Introduction
In theory the interviewees who contributed to this thesis believed that they were well
aware of current software engineering practices and methodologies. But in practice, the
author was to a large degree quite taken by the surprising abyss that unfolded between
best practice theory and actual practice within some of the companies under scrutiny.
From an Irish context and from the author’s research, there was little evidence to suggest
that a large amount of academic research had been undertaken to ascertain the attitudes
in small software companies toward best practice approaches in software engineering.
As stated in Chapter 5, a major component of the research was to undertake a survey and
interviews with a number of predefined companies whose existence depends on their
ability to create and developing software solutions for the financial services sector.
A case study was analysed of the same to further scrutinise these findings and broaden
the discussion.
This chapter continues the discussion on the research process by looking at the findings
of the research with the aim of delivering reasonable arguments on the significance of
these findings. The chapter concludes with a reflection on the implications of the
findings for the research questions that have driven the research.
In Conclusion the author intends to provide evidence that support the author’s argument
of how a non best practice SDLC is inhibiting a start-up company in the Case Study
moving to Build and Expansion phase of maturity. This is supported through Pareto
Analysis which measures efficiency levels of the SDLC over a specified period of time
under the As-Is framework.
90
6.2 Survey Findings
A key component of researching this thesis was driven by an interviewing process and a
survey focusing on the software development practices within those companies
identified at the outset.
The survey takes the form of a questionnaire that is highly focussed on the analysis of
relevant areas that relate to different stages of the software development lifecycle
(SDLC). The survey is deemed best practice and is based on the ESSI Software Best
Practice Questionnaire (SBPQ), first developed in 1997.
Once the questionnaires were completed, the author analysed the results to try and
identify the level to which each company conformed to best practice throughout their
software development process, thus identifying the companies that may benefit from a
software process improvement initiative. The benefit of mapping the ISO 15004
framework to the survey was that it gave a further view of specific best practice areas as
responses were being analysed throughout the Survey.
Following this and after acquiring the responses, the author could quickly identify any
trends or specific areas that were common between the companies in their approaches to
software development or software process improvement.
The questionnaire was executed under a number of relevant topic areas that relate very
closely to the sequential steps common with Waterfall software development model. It
was thought that designing the questionnaire around such a model would make it more
recognisable and generic for each of the interviewees. The same questionnaire was used
for each company.
The aim of the survey was to ascertain the level to which a best practice approach to
software development was carried out at each company. From the responses given the
91
author could then report on the implications the current practices (the As-Is approach)
may have on the long term viability and growth prospects of each company.
Rather than report the results verbatim, the author has decided to group the findings
under each of the questionnaire headings. By discussing the findings in this manner, the
author aims to provide a more holistic understanding of the difficulties each company
faces in light of best practice approaches to software development.
6.2.1 Requirements and Design
This section of the Survey contained 6 questions that related directly to requirements
gathering and software design. There wasn’t a large degree of variation between the
companies in relation to the responses provided for each of the six questions asked. In
fact there was only 1 question separating the overall best practice rating between the
Start-up company and the Expansion company.
Similar responses were given also in the ‘Detail’ section after each documented
question. Although many of the design tools being used by the companies [Question 4]
did vary, such as Visio for Start-Ups and SSADM/UML for Build and Expansion
companies, the author is satisfied that Start-Up and Build companies are for the large
part following best practice teachings.
From the findings of this questionnaire, the author is satisfied that as the Start-Up
category company grows, stakeholders will need to make only minor changes to current
Requirements and Design processes to conform fully to best practice, thus emulating
Build and Expansion companies.
92
6.2.2 Code and Test
This section of the Questionnaire contained 9 questions that were aimed at
understanding the Coding and Testing processes at each company. From the responses
given the author was able to ascertain the levels of quality management when carrying
out both Coding and Testing processes. The responses given helped identify the
procedures that were adhered to in relation to coding standards [Question 1], the testing
process such as regression testing [Question 7] and sign off [Question 8].
Unlike requirements gathering in the previous section, these questions have a more
direct bearing on the main operational activities of the development process in each
company. The responses in this section showed that the Expansion company adhered
fully to best practice in its approach to Coding and Testing as deemed by the SBPQ.
Each of the remaining companies measured poorly in the areas such as the use of testing
tools [Question 9] and the practice of regression testing [Question 7].
More alarming though was the poor performance of the Start-Up company in this section
and its failure to adhere to best practice. As well as the above, the Start-Up company
reported that they did not always test every required function [Question 8] when code
changes were made.
The major risk with this is that if the whole system is not fully tested, there is a higher
risk of bugs being found in the software resulting in re-work of the same fix sometime in
the future. If this does happen it can be very frustrating for developers as they are re
doing code, but also for ones customers as they are waiting for additional functionality
but instead get a defected solution.
Overall there was a wide variation in the best practice approach between the Expansion
and Start-up companies. Evidence suggests that the Start-up’s approach is very much ad-
hoc and chaotic (see level 1 CMMI, pg. 57), with no formal process in place which again
is some way of best practice theory and literature.
93
6.2.3 Configuration Management
There were 5 questions asked in this section of the questionnaire. From an
organizational standpoint this is a vitally important area to all software development
companies. Its primary function is to control and record the changes throughout the
software development process by managing documentation such as Test Plans, Code
Review documents and File versioning pertaining to the company during the software
development cycle.
For software companies with several different customers and products it is vitally
important that this function is managed correctly.
In this section the Expansion and Build companies performed well and both recorded a
complete best practice approach to Configuration Management.
The Build/Start-up and Start-Up companies faired poorly. Neither used software tools
for assisting in forward and backward tracing of software designs [Question 4] or
tracking the status of code in the software development library [Question 8].
The Start-up company did not have any formal procedure in place for controlling
changes to software requirements [Question 2] after they have been decided upon in the
Requirements and Design section. Like the previous section this again shows us that
Configuration Management is performed on an ad-hoc basis with no formal sign-of by
key stakeholders throughout this process. In general, the poor performance by the Start-
up is possible attributed to the small number of products and customers it supports.
Both the Expansion and Build companies support a number of products and customers
and as a result they use cross platform software configuration management solutions
(CVS, MKS Integrity) to support this function and its business. As a result the model is
highly scalable with little disruption when new products or customers are added.
94
The Build/Start-up and Start-up companies do not use such a platform as they have a
small number of products, and so see a single platform solution such as Microsoft Visual
Source Safe as being sufficient. However it is important that these companies recognize
that as they grow and win new contracts they too will need a more robust and scalable
configuration management tool to manage this process and conform to best practice.
6.2.4 Estimates and Schedules
There were 8 questions asked in this section that address management functions such as
developing schedules and controlling the overall development process. The focus is also
on managing timeframes and allocating resources to ensure that those timeframes are
adhered to.
In this section the Expansion, Build and Build/Start-Up companies all performed well,
although none of them achieved a full complement of best practice in this section. None
of the companies had a documented process for estimating software size and measuring
productivity [Question 2], or for providing feedback into the estimation process
[Question 5].
Neither the Build nor the Build/Start-up companies conducted actual versus planned
deliverable analysis [Question 6] although there were indications that this was
something they did want to account for in the near future.
More alarming yet again for the Start-up company was evidence suggesting that there
was no form of scheduling whatsoever and a complete lack of control over the
development process. It would appear from the responses given that there is a serious
lack of direction with no clear vision or sense of purpose to the management function.
The only positive response the Start-up company made in this section was [Question 1].
This ad-hoc approach could only be sustainable for a small number of customers and
products.
If the company was to scale up it operations by developing new products and supporting
more customers it would have to conform to a best practice approach with better
communication channels [Question 8] and planning processes [Question 4].
95
6.2.5 Project Management and Training
There were 10 questions in this section. The style and flow of questioning was still
heavily focused on organizational and management functions and as such, is a
continuation from the previous section. The focus of questioning is directly fixed on the
activities of the Project Manager and how he/she co-ordinates activities during each
phase of the development process, i.e. [Questions 1 and 2]. However, there is also a
focus on the relationship between Management and the Customer such and how
management perform reviews [Question 7] and assessing project viability [Question 6].
Like the previous sections, the Expansion, Build and Build/Start-up companies all
performed well; with little variation in the responses they gave. Each of them gave
negative responses for maintaining an awareness of software engineering technology
[Question 5] and also their relationships with external subcontracting companies
[Question 8].
The Build and Build/Start-up’s did not always get formal sign-off for deliverables
[Question 10] which can cause problems and rework if a change is misunderstood. This
can cause major disruption for Build companies supporting multiple products and
customers as they are unnecessarily forced into reworking code.
The Start-up company again performed poorly in light of best practice approaches to
Project Management and Training. There is a trend of poor management practice that
has continued from the previous section that is impacting directly on its software
development process.
The Start-up does not perform any quality assurance measures [Question 3], which again
increases the chances of bugs in applications and resulting in re-work for the
development team. The Training program is not formalized and largely depends on a
few hours with a developer often based on the developer with the least amount of work
on at that time.
96
Again, if the Start-up company wants to grow and scale up its operations, it needs to
look closely at its current practices in the areas of project management and training and
at best aim to adopt some of the best practice initiatives in this section.
6.3 Survey Results
As was anticipated, the gulf in best practice approaches to software engineering
activities is alarming when comparing companies who are in the Expansion phase of
growth and those that are at the Start-up phase. The Table below depicts the results
obtained from the Questionnaire that was conducted with each of the four companies.
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Fineos
Vulcan
Metis
Avaeon
Fineos 83% 100% 100% 75% 80% 84%
Vulcan 67% 78% 100% 62% 70% 74%
Metis 83% 55% 60% 62% 70% 66%
Avaeon 67% 44% 40% 13% 40% 39%
Req. &
DesignCode&Test Config.Mgt Est&Sch
Project.
Mgt
Best
Practice %
Table 6.3.1- Survey Results
To better understand these results, a Case study is presented in the next section to try and
explain where the difficulties are in closing the gap between ‘ad-hoc’ and best practice
software development practices. The author is convinced that start-up companies can
utilise best practice approaches from the outset, thus creating a more scalable iterative
approach to software development as they grow.
97
6.4 Case Study
A major component of the research carried out as part of this thesis is represented
through a case study. This strategy afforded the author the ability to uncover further
details related to the difficulties Start-up company’s have in their ability to adopt a best
practice approach to software development.
The case study is focused on one of the company’s identified in the research. Originally
the author was going to look at each company individually, but as this would be time
consuming and result in a lot of repetition the author decided against this approach.
The following sections introduce the company under discussion such as the number of
employees, customers it has and its typical software development environment. The
author has produced an 'As-Is' framework detailing the current typical software
development life cycle (SDLC) for this company that is consistent with the survey
findings in the previous section.
As part of this case study the author critically evaluates the current model to identify
shortcomings with it based on best practice theory. In parallel, the author presents a ‘To-
Be’ framework that is consistent with best practice theory. This framework is highly
scalable and should be adopted in place of the ‘As-Is’ model to afford the company a
better opportunity to grow in the short to medium term.
6.4.1 Company D
Company D is best described as a small indigenous software company that has been in
business since 2001. Company D employs twelve people, all of whom have IT
backgrounds including the CEO. Company D provides software consulting services to
its clients who are in the financial services industry and are all located outside of Ireland.
98
The duties of a Company D software engineer include code writing, analysis and design,
testing and implementation of functionality as required by its customers. At all stages of
this process Company D employees interact with the clients. This interaction can vary
from sending emails, to answering calls, to spending weeks at a time on site. This
working environment necessitates a thorough knowledge of the entire development
cycle, as well as good communication skills.
Company D’s main source of revenue comes from software support and development
work it does for a large Insurance company in the United States. This is the company’s
sole customer at this time. New Product Development (NPD) is conducted at Company
D and is supported by Enterprise Ireland and also through revenue generated from
supporting its large customer.
The CEO sees NPD as the gateway for developing new innovative products, winning
new contracts and ultimately moving up the value chain.
6.4.2 As-Is Approach at Company D
The Software Development model used by Company D is illustrated in Figure below.
The process begins in the top left corner with the End-Users [Step 1] and finishes in the
bottom right when the Build is applied to the Customers live environment [Step 15].
In this section the author will discuss in detail this process from the time the customer
makes contact with the development company with development requests, to the time
the build is applied to their live environment. Company D sees this model as being both
agile and customer responsive.
Like the previous section the ‘As-Is’ model is discussed under the same headings that
were used in the questionnaire.
99
Fig
ure
6.4
.1S
tak
eho
lder
s of
the
So
ftw
are
dev
elo
pm
ent
pro
cess
100
6.4.2.1 Requirements and Design
The agile approach to software development means the stakeholders in this process must
have a diversity of skills. They act as Support representatives, Testers and Build
managers while all the time performing their duties as Developers, Managers and
Business Analyst.
Contact is made by phone and e-mail. The majority of e-mails come via the company’s
web based Helpdesk [Step 1a], which enables users type their message and send it via a
web service. The Helpdesk logs all problems and reports can be printed to show all
problems by the user reporting the problem, the department affected, the number of
users affected and whether it is a high or low priority etc.
Developers, the Business analyst and Project Manager all field calls [Step 1c]. If a
problem requires a small code fix then a developer will more often than not stop what
they are working on to fix the end users problem.
The Team Meetings [Step 2] and Conference calls [Step 5d] with the Customer is where
all strategic decisions are made and as such, impact directly on the overall SDLC
process.
The PM is responsible for assigning tasks to members of the team and planning out the
weeks work. The CEO has a strong influence on this however and as such has the final
say on all decisions that impact on all processes throughout the SDLC.
The Status Report is written by the PM [Step 4] and is used as a reference guide during
the week by all stakeholders to see those tasks that have been completed and those still
outstanding. The CEO uses it as a performance measurement tool to see who is
performing certain tasks. Approval is often required from the CEO [step 5b] before
coding a particular task or updating items on the helpdesk.
101
After the Status Report is completed, the Business Analyst is responsible for going
through the document and updating the online helpdesk with progress reports on the
items being worked on [Step 5c]. The Analyst also writes specs [Step 6c] for new
features which are then used by the Developers to code the requirements as specified by
the Users.
6.4.2.2 Testing and Coding
As soon as the Team meeting has concluded and work requests have been approved and
assigned, the Developers begin Coding [Step 6a]. The Project manager is also part of the
core development team.
Developers are responsible for writing Test Plans [Step 8a]. The developer uses a Test
Plan as a reference to verify that the code feature works correctly [Step 10a]. When the
Developer is satisfied that the new feature or bug fix is working as intended, they check
in the files they’ve changed [Step 7] and update the Status Report to mark the task as
completed [Step 10b]. There is no designated Testing team at Company D. Testing is
performed by Developers, the Business Analyst with the testing team consisting of the
developers, the business Analyst, the Project Manager and sometimes the CEO [Step
10].
6.4.2.3 Configuration Management
Like the Testing phase of development, there is no defined Build Manager role at
Company D. Instead a developer will double up as the build person for that week and
more often than not it is the Developer who has completed his/her tasks first.
When the Developers have completed all the Test Plans, the Developer assigned to build
duties will apply the build to the development companies Test environment. The Test
102
Plans are then given to the Analyst who acts as the Test Manager to ensure that all the
tasks are tested and work accordingly.
When the build has been fully tested, the Business Analyst signs off [Step 11a] on it and
informs the Build Developer and they in turn release the build [Step 12] and apply it to
the customers Test environment [Step 13a]. The Project Manager is then notified when
the above step is completed [Step 13b].
6.4.2.4 Estimates and Schedules
The CEO often decides on the schedules and estimates based on conference calls with
the Customer [Step 5 d]. Sometimes the Project manager is involved in these meetings to
form opinions on timeframes and any other technical issues.
The Helpdesk and Status Report are the main resource for measuring timeframes as part
of the Analysts role in [Step 5c]. As such there is no formal approach nor are software
tools such as Microsoft Project used to develop schedules.
6.4.2.5 Project Management & Training
Efficiency is measured by how quickly a bug can be fixed or a new feature developed
and applied to the customer site. There is no formal process for measuring employee
performance, call handling, success rate of fixing bugs, amount of re-working bug fixes
etc. The CEO bases all of the above information on what has been documented in the
Status report [Step 5b]. More often than not efficiency is measured by the speed of a
Developer to fix the items assigned to them in the Status report for any given week.
There is no formal process of budgetary provisions allotted for Training and
Development. Training is usually done when somebody new starts at the company. In
extreme cases if the CEO saw a need for training then a course may be arranged, but
more often than not senior developers or the Project Manager will provide training to
new developers.
103
After the Build has been applied to the Customers Test environment the Project manager
will update the Helpdesk and liaise with End-Users on the customer site to ensure items
are tested and signed off on. The sign-off is done by the End-Users marking the items as
completed on the helpdesk [Step14c] or verbally through the project manager. The
Project Manager then informs the Build Developer who then applies the build to the
customers live environment [Step15].
6.4.2.6 Conclusion
Rather than describe the shortcomings with the As-Is approach, the author produced a
table with what he believes are the advantages and disadvantages on the current
practices. Also include in this table is a column that identifies the ISO 15504 process
that is most affected. The table is broken up into five key areas to highlight these
findings. The areas are Customer Contact, Skills, Decision Making, Documentation and
Efficiency.
10Ta
sk
Ad
va
nta
ges
D
isad
va
nta
ges
Im
pro
vem
ent
area
s b
ase
d
on
IS
O
15
504
Fra
mew
ork
Cu
sto
mer
Co
nta
ct
1.
Developers fielding calls directly from end-
users can speed up troubleshooting due to
their technical knowledge of the system
.
1.
Developers
often become
overloaded with
work.
2.
The
SDLC can be
delayed if several
developers, the PM or Business Analyst are
fielding Calls at any one time.
CUS .4 Operation
SUP .8 Problem resolution
Sk
ills
1.
Everybody has a diversity of skills, thus the
SDLC process very cost efficient.
1.
There is little room error e.g. developers not
paying attention to T
esting can result in re-
work and slow down the build.
2.
If one
person is ill the
whole process is
affected.
3.
Absenteeism
can affect staff
morale as
increased pressure and stress is placed on tem
mem
bers to perform
additional tasks.
ENG .1 Development
ENG .2 System
& Software Maintenance
ORG.1 Organisational Alignment
Dec
isio
n
Ma
kin
g
1.
Decision m
aking is quick
2.
The SDLC stakeholders are secure in the
knowledge that decisions that they make
must first be made by the CEO.
1.
By having an ad-hoc decision m
aking process
often m
eans specs don’t fully document the
changes needed later resulting in re-work.
2.
A non dem
ocratic approach to decision
making often affects m
orale as the voice of
the developers is rarely heard.
3.
The
Customer is over reliant
on the
Developing company to make decisions for
them
due to a lack interaction between U
sers
and M
anagers
MAN .1 M
anagem
ent
MAN .2 Project M
anagem
ent
MAN .3 Quality M
anagem
ent
10 Ta
ble
6.4
.1-
Ad
va
nta
ges
an
d D
isa
dv
an
tag
es o
f th
e ‘A
s-Is
’ F
ram
ewo
rk M
od
el
Do
cum
enta
tio
n
1.
A process is in place so that documentation
is produced at the critical stages throughout
the SDLC.
1.
Specs and Test plans are increasingly done on
an ad-hoc basis due to tim
e constraints and
pressure to get fixes out a.s.a.p.
2.
Specs
not
always
signed off on by the
Customer which can lead to re-work.
3.
Test Plans are often w
ritten after the code has
been developed and shipped to Customer.
4.
The CEO has the final say on task assignment
without
fully
understanding
time
that
developers spend Testing and Fielding calls.
SUP .1 Documentation
SUP. 2 Configuration M
anagem
ent
SUP .3 Quality Assurance
ORG. 3 HRM
ENG. 1 Development
Eff
icie
ncy
1.
The process is quick and efficient.
2.
No added pressure on employees once they
complete the item
s assigned to them
in the
status report they are seen to be efficient.
1.
Staff m
otivation is affected as there is nothing
to aspire to. The software development model
is very static and repetitive.
2.
A lack of perform
ance m
easuring tools m
eans
employees have nothing to aspire to; again
there is no incentive to do better.
CUS. 4 Operation
ORG .4 Infrastructure
ORG .5 M
easurement
MAN .3 Quality M
anagem
ent
106
6.4.3 To-Be Approach
In this section the author presents a ‘To-Be’ framework that in his opinion would rectify
many of the difficulties identified in both the questionnaire and with the current
practices under the ‘As-Is’ software development process.
Similar to the previous section, the author will discuss the ‘To-Be’ approach in detail,
from the time the customer makes contact with the development team to the software
build finally being applied to the customers live environment.
The author sees this model as something than can be easily adopted without causing
major disruption or changes to current practices. It is both agile and customer responsive
but more importantly this model can be deemed best practice as it draws on software
engineering literature that has already been documented in Chapters 3 and 4.
Unlike the As-Is framework, the To-Be model places a greater emphasis on individual
skills and functions, thus moving away from the ad-hoc and chaotic processes so
prevalent under the ‘As-Is’ model. For the process to run smoothly it is imperative that
all stakeholders understand their role and communicate effectively. By adding additional
skills and functions to key process area such as Testing and Configuration Management,
the SDLC process will become more efficient, functional and scalable.
6.4.3.1 Requirement and Design
Contact is again made by phone and e-mail but this time a Support person(s) handle end
user queries by providing Level 1 support. If the Level 1 support team can not rectify
the problem, an updated request with specific detail on the problem is then forwarded on
to Level 2 Support [Step 1d] consisting of the Developers and/or the Business Analyst.
At this point the problem will be discussed and assigned to a Developer based on the
Project Manager’s decision [Step 2/3].
107
Fig
ure
6.4
.2– S
tak
ehold
ers
of
the
Soft
wa
re d
evel
op
men
t p
roce
ss
108
The Team Meetings [Step 2] and Conference calls [Step 5d] with the Customer is where
all strategic decisions are made that impact the SDLC process. This is discussed in
greater detail under the Project Management section.
The Status Report is written by the PM [Step 4] and updated during the week by all
stakeholders as tasks are completed. The Project Manager should use this to detail work
done and work completed. A summarized report should then be given to the CEO so he
can get a snapshot of work being done.
Once the Status Report is completed, it is proposed that a Support Representative be
responsible for going through the report and updating the online helpdesk with progress
on the items being worked on [Step 5c]. By having the Support Representative do this,
the Business Analyst can dedicate more time writing up specs [Step 6c] and ensuring all
necessary details are acquired before coding commences, which is more inline with the
duties of a typical Business Analyst.
6.4.3.2 Code and Test
Like the As-Is framework, the Developers begin coding once Team meeting has
concluded and work requests have been approved and assigned by the Project Manager.
The proposed ‘To-Be’ model however does not advocate that the Project Manager take
part in code development as this can create work overload for him/her which can later
result in inefficiencies in other that the PM is directly responsible for. In a similar vain,
the Business Analyst and CEO are not seen as key members in the Testing function
[Step 13 a].
Again, Developers are responsible for writing Test Plans [Step 10a]. The developer uses
Test Plans as a reference to verify that the code feature works correctly [Step 10a].
When the Developer is satisfied that the new feature or bug fix is working as intended,
they update and check back in the files used [Step 9] and update the Status Report to
mark the task as completed [Step 10b]
109
Having a dedicated Test team will ensure that the Developers, the Analyst and Project
Manager have more time to perform their duties to a very high standard and thus follow
a best practice approach throughout the SDLC process. The poor performance in both
the organizational and management areas throughout the responses in the questionnaire
produced significant evidence that duties within these areas were being ignored.
The Project Manager needs to introduce a formal testing process that includes
regression, black box and white box testing. This is in line with [Question 8] in the
Questionnaire and will reduce the risk of reworking code, as will be shown in following
sections to be a major problem from the company.
If a code defect of bug is found during the testing process, the Tester sends a request
[Step 13b] to the developer responsible so that they can fix the problem, before the build
is released [Step 15]. The test team should also develop tools for replaying tests so as to
improve the efficiency of the testing process, which again is in line with best practice,
[Section 2 - Question 9] of the questionnaire.
6.4.3.3 Configuration Management
Like the Code and Testing phase of development life cycle, the ‘To-Be’ model is
proposing a defined role of Build Manager to coordinate activities in this are of the
SDLC. The Build Manager should be responsible for managing the code as soon as it is
checked in by he developers [Step 9], maintaining the Test and Live servers and
providing feedback to the Project manager on the status of a build at any given point in
time.
The Build manager should also be responsible for maintaining documentation with
evidence from the survey again suggesting that this has proved a difficult area under the
‘As-Is’ approach, [Section 3- Question 2].
110
The ‘To-Be’ model also supports the idea of having a Build and Test Manager at the
customer site to be responsible for maintaining the server their and ensuring that all code
changes are fully tested and signed off on, before they are applied to the live
environment. The main advantage of this under the ‘To-Be’ model is that the software
development life cycle becomes highly scalable. When more additional contracts are
signed and more customers are brought on line, they can now be easily supported
without little disruption to the current SDLC. Also the Customer has better control of
their environment as they are not solely dependent on the development company to their
environment which again, this is consistent with ASD best practice, see Chapter 3 pg.
52, point 5 (Highsmith, 2002).
6.4.3.4 Estimates and Schedules
Both the Build and Test managers at the customer site will work closely with their
counterparts from the development company to decide on schedules of when to apply
builds etc. This can allow for better planning through the SDLC and better
measurements of the time it takes to fully test and apply builds can be achieved. Again,
these were problem areas under the ‘As-Is’ model and addressed in the questionnaire,
[Section 4 – Questions 3 and 4].
The ‘To-Be’ model also proposes a better working relationship between the Project
manager and the CEO [Step 5e]. Both need to work together on organisational and
management functions such as those outlines in [Section 4 –Question 7] of the
questionnaire. The structures set out in the areas on Coding and Testing and
Configuration Management also relieve the Project Manager of many of the additional
functions he endured under the ‘As-Is’ model.
Adopting this approach will ensure allow for more realistic timeframes, better allocation
of resources and manpower and will also allow the CEO a better understanding of
earned value project tracking, [Section 4 – Question 6], this is consistent with ASD best
practice, see Chapter 3 pg. 52, points 1 and 2 (Highsmith, 2002).
111
6.4.3.5 Project Management and Training
The Project Manager is responsible for assigning tasks to members of the team and
planning out the weeks work. Unlike the ‘As-Is’ model the ‘To-Be’ model proposed that
the Project Manager also co-ordinate activities with the CEO and provides more
frequent updates on resources needed or additional Training needs [Step 5e] that he sees
important or beneficial to the overall Development team.
Both the CEO and the Project manager should conduct project reviews with Customers
and the Customer should also consult with stakeholders on their side to get feedback on
any issues that may arise [see top right hand corner of To-Be Framework model].
This would allow better decision making, [Section 5 –Question 7], and a more
democratic approach to decisions made where the Project Manager’s for the
development and customer sites act as the voice for each of their teams.
Another area where the ‘As-Is’ model falls short is in the area of sign-off and handover,
addressed in [Section 5 –Question 10] of the questionnaire. Again with the Business
Analyst now relieved of many of the duties they had under the ‘As-Is’ model they can
now introduce a formal process where the , the Project Manager and Customer are more
involved [Step 6d, 6e and 7] in ensuring that all details is documented in Specs before
coding commences.
6.4.3.6 Conclusion
Similar to the last section, the author has produced a table with what he believes are the
main advantages and disadvantages of introducing the ‘To-Be’ model. Again, the table
is broken up into five key areas to highlight these findings. The areas are Customer
Contact, Skills, Decision Making, Documentation and Efficiency.
11Ta
sk
Ad
va
nta
ges
D
isad
va
nta
ges
Im
pro
vem
ent
are
as
ba
sed
o
n IS
O
15
50
4 F
ram
ewo
rk
Cu
sto
mer
Co
nta
ct
1.
Developer time spent on writing code and testing
bugs
would increase as Support people are
now
providing Level 1 support to end users.
2.
Job satisfaction w
ould improve as D
evelopers are no
longer under so m
uch pressure to field calls.
3.
Customer satisfaction w
ould improve as problems are
handled m
ore professionally.
4.
The
process is a
lot easier to manage
and any
problems can be dealt with quickly.
1.
Cost of hiring additional staff.
CUS .4 Operation
SUP .8 Problem resolution
Sk
ills
1.
The Structure is highly scalable and less chaotic. The
To-B
e structure can support m
ore customers using the
same process as the company grows.
2.
Less stress on employees to perform
a m
ultitude of
activities in their working day.
3.
Clearer job specification and better planning w
ithin
the SDLC process.
4.
Customer has greater control of their business.
5.
Less chance of Bugs slipping through the net as there
is no a structured Testing procedure in Place.
1.
The Cost of hiring additional staff.
2.
Training Safew
ay staff to handle builds
and
monitor testing procedures.
3.
Initially, the process m
aybe perceived as slower.
ENG .1 Development
ENG
.2
System
&
Software
Maintenance
ORG.1 Organisational Alignment
Dec
isio
n M
ak
ing
1.
Better decisions will be made as they are thought out
better at all stages of the SDLC process.
2.
Having Safew
ay sign off on every Spec [Step 6c]
encourages them
to be more thoughtful about the
1.
Decision M
aking process is slower than the As-
Is m
odel.
2.
The CEO m
ay not be happy at relinquishing so
much control.
MAN .1 M
anagem
ent
MAN .2 Project M
anagem
ent
MAN .3 Quality M
anagem
ent
11
business im
pact a code change could have on their
business.
3.
Reduction in re-doing code fixes as decisions are
thought out better.
4.
All Stakeholders are involved in decision m
aking thus
motivating the team
.
Do
cum
enta
tio
n
1.
Producing documentation at all stages creates a m
ore
robust SDLC process that can be traced from start to
finish.
2.
Easy to train new
employees instead of just throwing
them
straight into the SDLC process.
3.
Easy for CEO and PM to m
easure tim
e spent on code
and bug fixes as there is now a complete trail of
signing off on Specs etc.
4.
More transparent for the Customer as they see w
hat
exactly they are being billed for and agreeing to.
1.
The
development
process can be
slower if
signoff is not agreed on Specs in a tim
ely fashion
or if Test plans are not completed.
2.
Tim
e taken to w
rite training m
anuals and new
process to support the To-B
e model.
SUP .1 Documentation
SUP. 2 Configuration M
anagem
ent
SUP .3 Quality Assurance
ORG. 3 HRM
ENG. 1 Development
Eff
icie
ncy
1.
Reliable inform
ation readily available to make
inform
ed decisions.
2.
Using Perform
ance measurement
techniques can
stim
ulate em
ployees
to work harder and achieve
higher level goals.
1.
Perform
ance
measurement
can
be
time
consuming and slow down the SDLC process
2.
Relying too heavily of perform
ance techniques
can have
an adverse affect on em
ployee
motivation if scrutinized too m
uch.
CUS. 4 Operation
ORG .4 Infrastructure
ORG .5 M
easurement
MAN .3 Quality M
anagem
ent
Ta
ble
6.4
.2 -
Ad
va
nta
ges
an
d D
isa
dva
nta
ges
of
the
‘To
-Be’
fra
mew
ork
Mo
del
.
114
6.4.4 The ‘As-Is’ Model in Practice
When presented with the ‘To-Be’ framework model, the current stakeholders at
Company D agreed that by having formal procedures in the areas of testing, sign-off
and support would in all probability improve current production and motivation levels.
The CEO however was a bit more sceptical and took the view that some of the proposed
initiatives would be seen bureaucratic and would ultimately slow down the SDLC
process. To him, the “As-Is” approach is seen to be cost efficient, productive and
customer responsive.
It is apparent that the chances of reworking code are a lot higher under the ‘As-Is’ model
when compared to the ‘To-Be’ model. Reworking a software requirements problem once
the software is in operation typically costs 50 to 200 times what it would take to rework
the problem in the requirements stage (Boehm & Papaccio, 1988).
To illustrate the high level of code re-working under the ‘As-Is’ model the author has
compiled data from several Status Report over a given month and mapped this data onto
a Pareto chart to try to ascertain the high levels of code rework at Company D. See the
figure on the next page.
By applying the 80:20 rule it was possible to identify specific areas in the software
application that were the focus of both bug code fixes and new code features (Appendix
D). This was further broken down to identify specific areas with the system that were
causing the greatest amount of code rework and so by concentrating on those areas,
improvement in quality and development times could be achieved.
Once armed with this information the Project Manager now needed to rectify the
problems and find answers to the following questions;
� Why was the level of code reworking so high?
� Who was responsible for these code changes?
115
� What Testing was carried out and by whom?
� Why was Testing so inefficient?
� Who Signed-off on Testing?
� Were Spec’s written for the Changes?
� Were these changes made during busy times? .i.e. high level of call handling
from users?
6.4.4.1 Pareto Analysis Results
The diagram on the next page plots out the Frequency levels (X axis) for which the
problems occur with the (Y-axis) detailing the areas of the system affected. The data
used in performing this analysis can be found in Append E.
The analysis tells us that by concentrating on the first 3 areas of the system (Other,
Rating and Cancels) and greater improvement in software quality would be realized
than concentrating on the last 3 areas on the graph (MVR, Renewals and VIN)
Item 3 - Bug Frequency
This indicator highlights the levels of Bugs in the application and their direct impact of
the software application. The areas of Other and Rating are high at 54%, VIN is at 80%
but Cancels, MVR and Renewals are at a staggering 100%. At this point the Project
Manager should be concentrating all efforts on eliminating those areas at 100%, to
realize the greatest production levels, based on the 80:20 rule.
Item C - Re-Work
The VIN Column shows that there was a 100% re-working of code. This means that all
the Code Requests reported for this period of time, had previously gone out as part of
another bug fix. Again, this needs to be addressed by the Project Manager immediately
so that such defects can be eliminated thus ensuring SDLC process operates more
effectively and software produced is of better quality.
11
Fig
ure
6.4
.3Data Analysis Pareto Chart
See
Ap
pen
dix
D f
or
All
Da
ta p
erta
inin
g t
o t
he
ab
ov
e M
od
el.
Pareto Chart. (Task/Work Analysis)
54%
54%
100%
100%
100%
80%
39%
57%
70%
81%
91%
100%
33.30%
73%
50%
43%
33.30%
0%
12.50%
27%
50%
57%
66.60%
100%
05
10
15
20
25
30
Other
Rating
Cancels
MVR
Renewals
VIN
Area of System Causing Problem
Frequency
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
1. Frequency
2. Cumulative Frequency
3. Frequency Bugs
A. Cumulative Frequency
B. New Issue
C. Re-W
ork
117
Measuring performance using simplified metrics such as this do not exist under the “As-
Is” model. But by simply analyzing work conducted over a period of time it is easy to
identify areas that need to be addressed and so improve the software development
process. This also conforms to best practice based on Part 3 of the SBPQ, see page 66.
6.5 Conclusion
The findings from the Pareto Analysis is further is evidence that the recommendations
presented by way of the proposed ‘To-Be’ model need urgent consideration. The author
is convinced that additional resources in such areas as support, testing and spec sign off
would greatly improve the current SLDC and dramatically improve the chaotic approach
that is prevalent throughout the ‘As-Is’ model.
In the long term, the Project Managers ability to keep staff motivated under the “As-Is”
regime will be difficult with already a growing feeling of discontentment within the
group. Some members of the team do not find the work varied enough and as a result are
less motivated to perform better. This could explain why code is of poor quality as was
presented in the Pareto Chart. When people feel they are moving forward, learning new
concepts, adding to their skill base, and stretching their minds, motivation tends to
remain high (Grazier, 1998)
The “To-Be” model can help achieve a better working environment by providing better
collaboration between team members and the customer with the goal being the delivery
of a better quality end product. Teams whose members are aligned with this goal will be
more motivated.
Researchers (Turner and Boehm, 2004) have implemented mappings between agile
software development and plan driven development such as the Software Engineering
Institute’s (SEI) and Capability Maturity Model Integration CMMI (SEI, 2002), already
discussed in Chapter 3. Microsoft sought to achieve a full life cycle method that was
truly agile but that met the requirements for CMMI to level 3. (Microsoft, 2005b)
118
(Chrissis, 2003) defines CMMI as a model which is intended to take an organization to a
level where continuous improvement in productivity and quality is possible. The ‘To-
Be’ model presented by the author in this chapter should be used as Company D’s
improvement model. Not just Company D, but all Start-Up companies need to awaken
from ‘ad-hoc’ development and management practices. Bearing in mind the 5 levels of
CMMI, Start-up companies need to elevate themselves from level 1 to levels where
there is an increased emphasis on creating a disciplined approach to project management
that can be deemed best practice.
The author is confident that the ‘To-Be’ framework would be a beneficial to Company D
and would eliminate a lot of the shortcomings with the current ‘As-Is’ model, as it offers
the agility they are used too while being detailed enough to communicate better and
provide more feedback channels so all stakeholders are aware of what is happening at
any stage of the SDLC. All of this is consistent with the 12 practices pf XP on page 48
and also the characteristics of Agile Methods on page 44.
The biggest challenge for Company D and Start-up companies like it, is the ability to
change both the organizational structures and management culture so that they
understand that by not following a disciplined best practice approach preventing these
companies moving to Build and Expansion phases of maturity. In the opening section of
Chapter 3, the author made the point that in general, the lack of direction in
organizational and management activities within Start-up companies is increasing the
time it takes for them to make the transition to Build and Expansion companies.
The author is again satisfied that the ‘To-Be’ can create an environment for quickly and
easily making this transition. Start-ups like Company D can enjoy good customer
relations where satisfaction and quality levels are high, but also have a highly scalable
SDLC process capable of supporting multiple customers and products. (Kanter, 1991)
offers six rules that inhibit innovation in organizations. Those that impact directly on a
companies ability to grow are managing tightly, offering criticism and an attitude that
119
management knows everything there is to know. These are characteristics of the As-Is
model.
There is no doubting the technical capabilities and knowledge that exist in many
software start-ups, but is important that organizational and management functions are in
place for these companies to grow.
120
CHAPTER 7 – CONCLUSIONS
7.1 Introduction
The research conducted as part of this thesis has examined the attitudes of Start-up
software development companies adopting a best practice approach throughout their
(SDLC). In order to provide a solid basis for the research, the literature was heavily
focused on such topics as Software Development models and Software process
Improvement models, with both areas providing an insight into frameworks that follow
best practices. As both areas come under the Software Engineering umbrella, the author
considered it appropriate to describe in brief the history of software engineering and also
the role of software engineers involved throughout the software development process.
The literature review had to be limited due to the large volume of information available
on the chosen topic areas. This was a difficult exercise as the author initially found it
hard on deciding what material to exclude and what material to include.
To overcome this difficulty the author decided early on the type of research questions
that needed to be asked in relation to what was being researched. With this in mind, the
author concentrated the literature review around the areas that where under scrutiny, i.e.
Software Development and Software Process Improvement.
It was during the literature review that the author discovered the ESSI SBPQ. This
helped provide a more focused researching of best practice techniques that later
impacted on the direction the author took in relation to the research methods used in
Chapter 5 and the data analysis in Chapter 6.
The purpose of this chapter is to present a retrospective evaluation of the research
carried out and discuss the results of the empirical study in more general terms than the
previous chapter. The author also explores new directions for further research in this
area and suggestions are made for the way forward.
121
7.2 Results of the Study
The objectives of this thesis were set out at the very beginning (Chapter 1, page 15). The
author is satisfied that the objectives laid down here have been achieved. The research
identified a number of issues in relation to the implications of the current software
development practices of the chosen Case Study and that evidence would suggest that a
best practice approach would improve the company’s current strategy.
Based on the research questions asked on Chapter 1, page 15, the author is now prepared
to focus on the main findings of the research under the following headings.
7.2.1 Government Support of the Irish Software Sector
Chapter 2 provided research that identified the various levels of support that is available
to companies involved in software development. The government is committed to
developing Ireland’s software sector through the development of research and
development capabilities and encouraging innovation in start-up companies as discussed
in Chapter 2 page 29.
Instead of competing against low wage countries for low level coding and maintenance
contracts, the governments focus is on encouraging start-up companies to target niche
software products and services that generate greater value to the economy and the
companies themselves.
Many research centres have been established such as the ISERC at UL, DERI in
Galway, with millions of euro available in funding to further develop this initiative.
Ireland’s low rate of tax plays a major role in attracting, retaining FDI and developing
the software industry. The establishment of the Irish Software Association (ISA) has
helped to promote, lobby and consult with the software industry and the Irish
government in matters relating to the ITC sector.
122
Although the ISA recognizes the support afforded to the industry as a whole, there is a
strong belief among many industry experts that the procurement of contracts from the
government to smaller software companies is preventing them from growing.
Evidence from the UK supports the view that providing such contacts to these
companies can help them grow and seem more attractive to potential customers as they
are already providing custom to the government.
Although not dismissing this fact, the author is of the opinion that the inability of start-
up companies to adopt a best practice approach throughout their software development
life cycle model is the underlying factor that is preventing these companies from
growing. The adoption of best practice techniques will, in the long run prove to be the
principal base that will make companies more scalable, productive and attractive to
customers so they can mature to Build and Expansion companies.
7.2.2 Benefits of Best Practice Approaches throughout the SDLC
The framework proposed by the author is in his view, applicable to any Start-up
software development company as a means of eliminating irrational, redundant and
counter productive activities. By having a central figure or focal point in each of the five
development phases of the To-Be framework, the grouping of activities improves by
ensuring that the necessary work is completed without oversight, thus increasing
productivity and quality.
By having a division of labour where different tasks are completed by key personnel
throughout the SDLC phases, the Project Manager can now manage and plan, thus
ensuring a high level of best practice throughout. The added benefit of this model relates
to how Start-ups can use the Framework it represents to allow them scale up operations
as they grow through developing new products and winning customers, without having
to reorganise the company each time a new product or customer comes on line.
123
This facilitates interchange-ability among developers and project managers within the
company, as they may later be re-assigned to different projects as extra skills for
example are needed on new projects.
As already mentioned in the previous section, the ISA have urged the government to
procure software from Start-up companies, but as stated the onus should inevitably be on
the companies to be more professional with more formal methodologies so that they can
show they can produce quality software in a timely fashion.
History has shown that the field of software engineering has since its inception come
under criticism for the failures of companies to adopt a formalised best practice
approach throughout the SDLC. Evidence from this thesis supports this view, with not
only Start-up companies affected, but also companies in Build and Expansion phases of
maturity, albeit not to the same extent as Start-Up’s.
7.3 Research Limitations
The main factors that limited the research of this thesis relate to time and resources.
These limitations had a direct bearing on the specific focus for the research .i.e. software
development companies operating in the financial services field, which meant that only a
small number of companies were surveyed and one of these provided the case study
research. It would have been interesting and no doubt more revealing to have had a
larger sample of interviewees to allow for deeper analysis.
The research was limited by the requirement to collect as much information as possible
in a very short period of time as the author was conscious not to discourage potential
respondents with long interviews and time consuming questionnaires.
124
7.4 Further Research
Inevitably, the research from this thesis has revealed areas that are worthy for further
investigation. Whilst it has achieved its aim of investigating the affects of ad-hoc
approaches to software development in a Start-up company environment, more specific
research could be carried out on a number of important areas that have been revealed.
Theses issues don’t relate directly to the awareness of ad-hoc and chaotic practices in
Start-up companies, but to the mentality that seems averse to changing these practices.
This could be more a sociological factor rather than poor strategic management
practices, so this could be an area open to further and more deeper research than was
presented here.
Another area that in the author’s opinion may need further research is in the area of
training and development through government and state agency initiatives. Although
slow to criticise the government based on the financial support it is providing to Start-up
companies and research centres throughout Ireland, the author does feel that there are
areas that do need further researching.
One example of this is the continual reference made in newspapers, journals and the
media of the government and Enterprise Ireland’s allocation of funds for Start-up
companies and research centres, (DETE, 2006a, Silicon Republic, 2005). But this
support does not consider whether or not best practice techniques are being practiced by
these Start-up companies. The author feels strongly that this is an area that deserves
further research.
It is his view that if State support groups are providing financial support for Start-up
companies, that in return they have the right to demand that these companies adopt best
practice approaches. Maybe then, the strategy of trying to create awareness through
Enterprise Ireland’s Conference on Effective Software Development is no longer needed
as policies and support are in place from the outset.
125
7.5 Conclusion
It is impossible and wrong for the author to suggest that the Framework presented in this
thesis is applicable for all Start-up software companies and will dramatically improve
their existing ad-hoc practices. Nevertheless, he is confident that it will help bring them
more in line with best practice, make them more scalable and in the long term, position
them better in the market for winning new contracts.
On reading this thesis, the author hopes that managers of small Start-up companies can
relate to some of the findings and realise that operating in a ‘realm of darkness blissfully
unaware of rudimentary concepts of structured analysis and design, (Yourdon, 1991)
need not be the way they do business.
The field of software engineering does not advocate one methodology to ensure best
practice throughout the SDLC. If it did then all companies, regardless of their size would
adopt that model and stick with it. The findings from the authors research through the
questionnaire was further evidence of this, as no company had a 100% best practice
record for all five areas examined, (see Chapter 6 pg. 96).
What this thesis is advocating though, is that there are many different approaches to
Software Development and to Software Process Improvement. Understanding that Start-
Up companies neither have the time, money or resources to be CMMI compliant from
day 1, the author believes they can however take a simplified iterative model and adapt
it so that it is best practice, scalable, customer responsive and ensures quality such as the
To-Be Framework model presented in this thesis.
These findings are not just limited to software companies operating in the financial
services sector. The author is confident that Start-up and even Build and Expansion
companies operating in different sector such as the telecoms and medical sectors can
identify with this model and adapt it to their specific needs.
126
References and Bibliography
Ambler, S. (2002) Agile Modelling. The Official Agile Modelling (AM) Site.
http://www.agilemodeling.com. Visited Aug 9th 2006.
Barry, F. (2003) “Tax Policy, FDI and the Irish Economic Boom of the 1990s”,
forthcoming in Economic Analysis and
Barry, F., and J. Bradley (1991) "On the Causes of Ireland's Unemployment", Economic
and Social Review, 22(4), 253-286.
Boehm, B. and Turner, R. (2004) Balancing Agility and Discipline: A Guide for the
Perplexed. Boston: Addison-Wesley, 2004.
Boehm, B. and Papaccio, P. (1988) "Understanding and Controlling Software Costs,"
IEEE Transactions on Software Engineering, v. 14, no. 10, October 1988, pp. 1462-
1477.
Boehm, B. W., (1988), IEEE Computer, Vol. 21, No. 5, pp61-72.
Bryman, A. and Bell, E. (2003) Business Research Methods. Oxford 2003.
Breaking News.ie. (2002). Datalex finance director to resign
http://archives.tcm.ie/breakingnews/2002/05/09/story49485.asp
Breaking News.ie (2001) Baltimore to shed 30 Irish jobs
http://archives.tcm.ie/breakingnews/2001/08/22/story21536.asp
Carver, J.C. (2003) The impact of background and experience on software inspections,
PhD thesis, University of Maryland.
127
Chrissis, M.B., Konrad, M. and Shrum, S. (2003) CMMI – Guidelines for Process
Integration and Product Improvement, SEI Series in Software Engineering, Addison
Wesley, Boston, MA 2003.
CMMI Product Team. (2002) Capability Maturity Model Integration (CMMI), Version
1.1: CMMI Software Engineering. Software Engineering, Integrated Product and
Process Development, and Supplier Sourcing, CMMI-SE/SW/IPPD/SS, V1.1 Carnegie
Mellon University Software Engineering Institute, Pittsburgh PA.
Coad, P., Lefebvre, E. and De Luca, J. (1999) Java Modelling in Color with UML:
Enterprise Components and Process, Chapter 6, Prentice Hall, 1999.
Cockburn, A. (2001) Agile Software Development, 1st edition, December 2001, pages
256, paperback, Addison-Wesley Professional,
Collins, J. (2005). The Sunday business Post. Supporting the Software Sector
Curtis, B. & Paulk, MC. (1993) Creating a software process improvement program,
Information and Software Technology, vol. 35, no. 6/7, pp. 381 -6.
Denscombe, M. (2003) The Good Research Guide. 2nd ed. Maidenhead: Open
University Press.
Dertouzos, M. (1999) Four Pillars of Innovation. MIT’s Magazine of Innovation
Technology Review. Nov-Dec.
DETE. (2003). National Employment Action Plan Ireland 2003-2005 Department Of
Enterprise Trade and Employment October 2003
http://www.entemp.ie/publications/labour/2003/nationalemploymentactionplan.pdf
128
DETE. (2006a) Department of Trade and Employment. Enterprise Ireland Supports 75
New High Growth Potential Start-Ups in 2005.
http://www.entemp.ie/press/2006/20060202a.htm
DETE. (2006b) Ireland and India move to boost collaboration on software.
http://www.entemp.ie/press/2006/20060119d.htm
DETE. (2006c) Ireland and India move to boost collaboration on software. New
opportunities for Irish software companies in Asia.
http://www.entemp.ie/press/2006/20060119d.htm
DETE. (2003) National Employment Action Plan Ireland 2003-2005.
http://www.entemp.ie/publications/labour/2003/nationalemploymentactionplan.pdf#sear
ch=%22employment%20rising%20from%201.15%20million%22
Donnellan, E. and Reid, L. (2005) Millions overpaid to health staff under new pay
system, The Irish Times, 5 October, 2005 p. 1.
http://www.ireland.com/newspaper/front/2005/1005/574573571HM1PAY1.html
DRA. (2006). Dublin Regional Authority. Regional Newsletter Jan 2006
http://www.dra.ie/PDF/Newsletter-01-
06.pdf#search=%22employing%20over%20129%2C000%22
DSDM, (1998) Guidelines for introducing DSDM into an Organisation.
http://agilealliancebeta.org/system/article/file/902/file.pdf
Dutta, S. Lee, M & Van Wassenhove, L (1997b), Management practices for Software
excellence: an empirical investigation, 97/32/TM, INSEAD, Fontainebleau, France.
129
Dutta, S & Van Wassenhove, L. (1997a) An empirical study of adoption levels of
software management practices within European firms, 97/118/TM, INSEAD,
Fontainebleau, France.
Dutta, S. Lee, M & Van Wassenhove, L. (1999) Software Engineering in Europe: a
study of best practices, IEEE Software Vol. 16, no.3, pp.82-90.
Electric News. (2005a). Government ups spending on high-tech R&D
http://www.electricnews.net/news.html?code=9574047
Electric News. (2005b). Straight Talk: Michele Quinn, Irish Software Association
http://www.enn.ie/frontpage/news-9646637.html
Electric News. (2006). Healthy quarter for Irish tech investment
http://www.enn.ie/frontpage/news-9678523.html
Enterprise Ireland. (2005) Irelands Economic Profile.
http://www.enterprise-ireland.com/NR/rdonlyres/2FC1B0E8-3641-495E-A541-
362FB8E841A0/0/EconomicProfleOctober20.pdf#search=%22the%20population%20is
%20expanding%20at%20over%2080%2C000%22
ESSI (1997a), 1997 Software Best practice Questionnaire: Analysis of Results,
European Software Institute Bilboa.
ESSI (1997b) SOFTWARE BEST PRACTICE QUESTIONNAIRE Directorate General
III - Industry EUROPEAN COMMISSION
http://cordis.europa.eu/esprit/src/essi-qn.htm
Eurostat. (2004). Statistical Yearbook, pg. 158,
http://epp.eurostat.cec.eu.int/cache/ITY_OFFPUB/KS-CD-04-001-8/EN/KS-CD-04-
001-8-EN.PDF
130
Company A. (2003) Digital Ireland, February 2003.
http://www.Company
A.com/news_events/media_coverage/2003/feb_2003/digital_ireland.htm
Forfas. (2004). Enterprise Strategy Group Report [Ahead of the Curve, Ireland's Place in
the Global Economy].
http://www.forfas.ie/publications/esg040707/pdf/esg_ahead_of_the_curve_chapter1.pdf
Forfas. (2006) International Trade & Investment Report 2005
http://www.forfas.ie/publications/forfas060220/webopt/forfas060220_trade_and_invest
ment_webopt.pdf
Gainer, J. (1998) May edition of the itmWeb Report Critical Path: Applying the
Capability Maturity Model. http://www.jeffgainer.com/cmm_applied.html
Gallivan, M.J. (1997) Value in Triangulation, a comparison of two approaches for
combining qualitative and quantitative methods.(quoted in Lee, A., Liebenau, J. and
DeGross, J Information Systems and Qualitative Research, Chapman and Hall pg. 417-
43.)
Gazier P. (1988) Team Motivation. EI Network January, 1998.
http://www.teambuildinginc.com/article_teammotivation.htm. Accessed June 2th 2005.
Goldesson, D.R & Gibson, D. (2003) Demonstrating the impact and benefits of CMMI:
an update and preliminary results, CMU/SEI-2003-SR-009, Software Engineering
Institute, Carnegie Mellon University, Pittsburgh.
Highsmith, J. (2002) Cutter Consortium What Is Agile Software Development?
http://www.stsc.hill.af.mil/Crosstalk/2002/10/highsmith.html
131
ICT. (2006). Ireland Budget Submission.
http://www.ictireland.ie/Sectors/ict/ictDoclib4.nsf/245d0de7e513aed980256ed70051372
1/3ac2688df0c775ff802570b9003de052/$FILE/ICT%20Ireland%20Budget%20Submiss
ion%202006%20FINAL.pdf
IEEE Std. 610.12. (1990) Standard Glossary of Software Engineering Terminology,
IEEE, Piscataway,N.J., 1990.
ISO/IEC. (2002) Information Technology - Software Life Cycle Processes : Amendment
1, ISO/IEC 12207 AMD 1
ISO/IEC PDTR 15504. (1996) Information Technology - Software Process Assessment:
Parts 1- 9.
ISO/IEC TR 15504-2. (1998) Information Technology - Software Process Assessment -
Part 2: A Reference model for processes and process capability, ISO/IEC TR 15504-
2:1998(E).
ISO/IEC TR 15504. (1998) Information Technology - Software Process Assessment
Parts 1-9 ISO/IEC TR 15504-9:1998(E).
Iversen, J., Johansen, J., Nielsen, P.A. and Pries-Heje, J. (1998) Combining quantitative
and qualitative assessment methods in software process improvement. Proceedings of
the 6th European Conference on Information Systems (ECIS), Aix-en-Provence, France
pg. 451-66.
Johansen, J. (1999) Lessons learned in a National SPI Effort. The Danish SPI initiative:
Centre for Software Process Improvement. DELTA Software Engineering, Denmark
http://www.iscn.at/select_newspaper/surveys/denmark.html
132
Jones, Capers, ed. (1986) Tutorial: Programming Productivity: Issues for the Eighties,
2nd Ed. (Los Angeles: IEEE Computer Society Press), 1986.
Kanter, R. (1991): Improving the development, acceptance, and use of new technology:
organizational and interorganizational challenges. Pp. 15-56 in National Academy of
Engineering and National Research Council, People and Technology in the Workplace.
Washington, D.C.: National Academy Press.
Kanter R. (2002) Driving Corporate Entrepreneurship. By: Kanter, Rosabeth Moss;
Ingols,Cynthia; Morgan, Erika; Seggerman, Tobias K. . Management Review ,Apr87,
Vol. 76 Issue 4, p14
Kuvaja, P. and Bicego, A. (1994), BOOTSTRAP A European Assessment Methodology,
Software Quality Journal, June.
Labanyi, D. (2005) Garda computer summonses thrown out. The Irish Times Sept 28th
2005.http://www.ireland.com/newspaper/motoring/2005/0928/1524210185MOT28_P1_
LEAD.html
McCracken, D. and Jackson, M. (1981) A minority dissenting position. In Agresti, W.
(1986) New Paradigms for Software Development. IEEE Computer Society Press,
Washington DC.
McGuire, T. (2005) The Post.ie. IT debacle exposes myth that big is better.
http://archives.tcm.ie/businesspost/2005/10/09/story8650.asp
Microsoft. (2005) Solutions Framework for Agile Software Development.
http://lab.msdn.microsoft.com/teamsystem/workshop/msfagile Accessed June 6th 2005.
Morck, R., Acs, Z., Yeung, B. (2001) Entrepreneurship, globalization and public policy.
Journal of International Management, 7: 235-251.
133
Morrison, J. and George, J.F. (1995). Exploring the software engineering component in
MIS research. Communications of the ACM, vol. 37, no. 7, page 80-91
Moores, S. (2005) Something’s rotten in the software economy. The future's not so
bright.
http://www.silicon.com/research/specialreports/compliance/0,3800003180,39152796,00.
htm
Mulqueen, T. (2005) Future Soft, A look at the future for Irish software development.
http://www.techcentral.ie/corporate_it/Future_Soft/view
Musgrove, M. (2004) Washington Post: IBM Sells PC Business to Chinese Firm in
$1.75 Billion Deal http://www.washingtonpost.com/wp-dyn/articles/A45273-
2004Dec7_2.html
NERA Economic Consulting. (2005) A Study of the Benefits of Public Sector.
http://www.supplyinggovernment.gov.uk/repositoryDownload.asp?SITE=SRG&SOUR
CE=N&ID=631
NTMA. (2005) Ireland Information Memorandum March 2005, national Treasury
Management agency. http://www.ntma.ie/Publications/2005/NTMA_Info_05.pdf
OECD. (2002) OECD Information Technology Outlook ICT and the information
economy 2002. Paris 2002.
Paulk, M., et al. (1994) The Capability Maturity Model for Software: Guidelines for
Improving the Software Process. Reading, MA: Addison- Wesley, 1994.
Paulk, M. (2002) Agile Methodologies and Process Discipline, Crosstalk, October 2002,
http://www.stsc.hill.af.mil/crosstalk/2002/10/paulk.html. Accessed July 14th 2005.
134
Perez, C. (2002). Technological Revolutions and Financial Capital. The Dynamics of
Bubbles and Golden Ages.
Reid, L. (2005) HSE to suspend second computer project, The Irish Times, 6
October 2005 p. 1.
http://www.ireland.com/newspaper/front/2005/1006/2636179300HM1COMPUTERS.ht
ml
Reid, L. (2005) €577,000 system for jails 'scrapped after six months'.
The Irish Independent, 7th October 2005.
http://www.unison.ie/irish_independent/stories.php3?ca=9&si=1483704&issue_id=1310
4
Richardson, I. (1999), Improving the software process in small indigenous software
development companies using a model based on quality function deployment'. PhD
Thesis, University of Limerick.
Rising, L, and Janoff, N. (2000) The Scrum Software Development Process for Small
Teams, IEEE Software, July/August 2000, pages 26-32.
Rout, T. (1996), The SPICE project - Past, Present and Future', paper presented to
Software process 96 Conference, Brighton UK 1996
Royce, W.W. (1970) Managing the Development of Large Software Systems: Concepts
and Techniques, proceedings of Wescon, August USA.
Software Engineering Institute. (2002) CMMI® for System Engineering, Systems
Engineering/Software Engineering/Integrated Product and Process
Development/Supplier Sourcing, Version 1.1, Staged Representation (CMMI-
SE/SW/IPPD/SS, V1.1, Staged), Carnegie Mellon University, Pittsburgh, PA 2002.
135
Schumpeter, JA. (1942/1976) Capitalism, socialism and democracy (with Introduction
by Tom Bottomore). Harper Collins, New York.
Schwaber, K. and Beedle, M. (2002) Agile Software Development with SCRUM,
Pearson Technology Group, 2002.
SFI. (2004). SFI-Funded Research Team Links Up with Global ICT Leaders to Boost
Ireland’s Software Development Sector.
http://www.sfi.ie/content/content.asp?section_id=467&language_id=1&publication_id=
1256
Shari, Lawerence and Pfleeger. (2001) Software Engineering. Theory and Practice 2nd
Edition, Prentice Hall.
Silicon Republic. (2005a). Trintech posts second-quarter losses.
http://www.siliconrepublic.com/news/news.nv?storyid=nextarchiveSN3&next=260
Silicon Republic. (2005b). SFI to fund €11.7m software centre.
http://www.siliconrepublic.com/news/news.nv?storyid=single5652
Smilor, R. and Gill, M. Jr. (1986). The New Business Incubator: Linking Talent,
Technology, Capital, and Know-How. Lexington, MA: Lexington Books.
SPIRE. (1998) The Spire Handbook: Better, Faster, Cheaper Software Development in
Small Organisations, Centre for Software Engineering DCU Campus, Dublin.
Stapleton, J. (1995) Dynamic System Development Method. Addison-Wesley
136
UL.ie (2005) Minister Micheál Martin announces funding of €11.7million for the Irish
Software Engineering Research Centre In UL.
http://www.ul.ie/main/news/index17thoct.shtml
Wang, Y. and King, G. (2000) Software Engineering Processes. Principles and
Applications. CRC Press.
Yourdon, E. (1991) Sayonara, once again, structured stuff. American Programmer, 4, 8,
31-38.
Zahran S, (1998) Software Process Improvement. Practical Guidelines for Business
Success. Addison-Wesley
137
A-1
Appendix A Survey/Questionnaire
Organisation :
Address :
Number of Employees:
Number of Employees involved in Software Engineering:
Organisation primary involvement in software industry (delete those descriptions which do not apply):
• Software user (developed in-house)
• Software user (developed by a 3rd party)
• Software vendor (producing off-the-shelf systems)
• Software vendor (producing custom software systems)
• Research & Development institute or university
• Interest Group (e.g. professional society or standards body)
• Other (please specify):
Programming Languages/Technologies Used :
Number of Software Projects/Customers :
Community of Interest (delete those which do not apply)
• Business Orientated Systems
• Technically Orientated Systems
• Embedded and Control Systems
A-2
Section 1 - Requirements and Design Answer
ESSI (SBPQ) ISO 15504
framework
1. Is there a procedure for ensuring that an
appropriate level of user, customer and marketing input is made throughout the project?
Details:
(YES/NO)
1.7 Org. Issues CUS. 3 Requirements Elicitation
2. Is there a mechanism to ensure that the
projects selected for development qualitatively or quantitatively support the organisation's business objectives.
Details:
(YES/NO)
2.9 Standards & Procedures
CUS. 1.1 Acquisition Preparation
3. Are there procedures to ensure that the
functionality, strengths, and weaknesses of the "system" which the software is replacing are formally reviewed? (This refers to next generation versions of software applications being developed)
Details:
(YES/NO)
2.10 Standards & Procedures
N/A
4. Are design notations such as Software
Analysis and Design Tools used in program design?
Details:
(YES/NO)
5.2 Tools & Technology
ENG. 1.3 Software Design
5. Are prototyping methods used in ensuring the
requirements elements of the software? Details:
(YES/NO)
5.5 Tools & Technology
ENG. 1. 1 Systems Requirements Analysis and Design
6. Is a data dictionary available for controlling
and storing details of all data files and their fields?
Details:
(YES/NO)
5.6 Tools & Technology
ENG. 1.3 Software Design
A-3
Section 2 - Code and Test Answer
ESSI (SBPQ) ISO 15504
framework
1. Are common coding standards applied to
each software project? Details:
(YES/NO) 2.5 Standards & Procedures
ENG. 1.4 Software Construction
2. Does test planning commence prior to
programming beginning based on the user requirements and high-level design documents?
Details:
(YES/NO)
2.11Standards & Procedures
ENG. 1.6 Software Testing
3. Is there a procedure to check that the system
configuration (i.e. the programs and any data) passing user acceptance testing is the same as that which is implemented for live operation and that no changes are made directly to a "live" version of any system (other than through modification to its development version)?
Details:
(YES/NO)
2.13 Standards & Procedures
SUP.2 Configuration Management
4. Are estimates made and compared with actuals for target computer performance (e.g. memory utilisation, processor throughput and file/channel I/O and disk usage)?
Details:
(YES/NO)
3.6 Metrics MAN. 3 Quality Management
5. Are post-implementation software problem reports logged and their resolution effectively tracked and analysed?
Details:
(YES/NO)
3.7 Metrics SUP. 8 Problem Resolution
6. Do records exist from which (and requiring nothing extra) all current versions and variants of software systems and their components can be quickly and accurately reconstructed in the development environment?
Details:
(YES/NO)
3.8 Metrics SUP.2 Configuration Management
7. Is there a mechanism for assuring that regression testing (i.e. the forced re-run of all previous tests prior to any new tests) is routinely performed during and after initial implementation?
Details:
(YES/NO)
4.5 Control of the Development Process
ENG.1.6 Software Testing
8. Do procedures exist to ensure that every required function is tested and verified?
Details:
(YES/NO) 4.6 Control of the Development Process
SUP. 4 Verification
9. Are automated testing tools used? (For example for capturing and replaying tests, or for ensuring logic paths coverage)?
Details:
(YES/NO)
5.3 Tools & Technology
ENG 1.6 Software Testing
A-4
Section 3 -Configuration Management Answer
ESSI (SBPQ) ISO 15504
framework
1. Is a change control function established for
each software project? Details:
(YES/NO)
1.4 Organisational Issues
SUP. 2 Configuration Management
2. Is there a procedure for controlling changes to the software requirements, designs and accompanying documentation?
Details:
(YES/NO)
4.3 Control of the Development Process
SUP. 2 Configuration Management
3. Is there a procedure for controlling changes to the code and specifications?
Details:
(YES/NO)
4.4 Control of the Development Process
SUP. 2 Configuration Management
4. Are software tools used to assist in forwards and/or backwards tracing of software requirements to software designs through to code?
Details:
(YES/NO)
5.1 Tools & Technology
ENG. 1 Development
5. Are software tools used for tracking and reporting the status of the software/subroutines in the software development library?
Details:
(YES/NO)
5.4 Tools & Technology
SUP. 2 Configuration Management
A-5
Section 4 - Estimates and Schedules Answer
ESSI (SBPQ) ISO 15504
framework
1. Where other non-software resources are critical to the success of the project is there a procedure for ensuring their availability according to plan?
Details:
(YES/NO)
1.8 Organisational Issues
MAN. 2 Project Management
2. Is there a documented procedure for estimating software size (such as "Lines of Source Code") and thus for using productivity measures?
Details:
(YES/NO) 2.6 Standards & Procedures
MAN. 2 Project Management
3. Is a formal procedure used to produce software development effort, schedule, and cost estimates?
Details:
(YES/NO) 2.7 Standards & Procedures
MAN. 2 Project Management
4. Are records of actual project resourcing and timescales versus estimates maintained (at individual resource/resource-type level) and regularly analysed/fed-back into the estimating and scheduling procedures?
Details:
(YES/NO) 3.1 Metrics
MAN. 2 Project Management
5. Are records of software size maintained for each software configuration item, over time, and fed-back into the estimating process?
Details:
(YES/NO)
3.2 Metrics MAN. 2 Project Management
6. Is "earned value" project tracking used throughout the software development process (actual versus planned deliverables analyses, designed, unit tested, system tested, acceptance tested over time) to monitor project progress?
Details:
(YES/NO)
3.5 Metrics
MAN. 2 Project Management
7. Are estimates, schedules and subsequent changes produced only by the project managers who directly control the project resources and are fully aware of their abilities and availabilities?
Details:
(YES/NO)
4.1 Control of the Development Process
MAN. 2 Project Management
8. Does the overall business project manager gain agreement and sign-off from all parties who have produced detailed estimates and schedules before publishing or revising a consolidated project plan?
Details:
(YES/NO)
4.2 Control of the Development Process
MAN. 2 Project Management
A-6
Section 5 – Project Management and Training Answer ESSI (SBPQ)
ISO 15504 framework
1. Does each software project have a nominated software project manager?
Details:
(YES/NO) 1.2 Organisational Issues
MAN. 2 Project Management
2. Does the software project manager report to a business project manager responsible for the overall benefit of the project to the business?
Details:
(YES/NO) 1.2 Organisational Issues
MAN. 2 Project Management
3. Does a Software Quality Assurance (SQA) function exist within an independent reporting line from software development project management?
Details:
(YES/NO)
1.3 Organisational Issues
SUP. 3 Quality Assurance
4. Is there a required training programme for all newly-appointed software personnel designed to familiarise them with in-house software project management procedures?
Details:
(YES/NO)
1.5 Organisational Issues
ORG.3 Human Resource Management
5. Is there a procedure for maintaining awareness of the state-of-the-art in CASE or software engineering technology?
Details:
(YES/NO) 1.6 Organisational Issues
ORG. 4 Infrastructure
6. Does management formally assess the benefits, viability, and risk of each software project prior to making contractual (or internal) commitments?
Details:
(YES/NO) 2.1 Standards & Procedures
MAN. 2 Project Management
7. Do management formally conduct periodic reviews of the status of each software project?
Details:
(YES/NO) 2.2 Standards & Procedures
MAN. 2 Project Management
8. Are there procedures to ensure that external software subcontracting organisations, if any, follow a disciplined software development process?
Details:
(YES/NO) 2.3 Standards & Procedures
CUS. 1.3 Supplier Monitoring
9. For each project, are independent audits (such as inspections or walkthroughs) conducted for each major stage in the software development process?
Details:
(YES/NO)
2.4 Standards & Procedures
SUP.3 Quality Assurance
10. Is a formal procedure (such as a review or handover with sign-off) used whenever a deliverable (such as a user statement of requirements or system requirements) is passed from one discrete group to another (e.g. user to analyst to designer) to ensure it is properly understood?
Details:
(YES/NO)
2.8 Standards & Procedures
SUP.3 Quality Assurance
B-1
Appendix B E-mail Request to Participate in Survey
Dear XXXXX,
I was hoping you could help me with a survey I am conducting as part of my Thesis for a Masters course in Technology Management I'm studying at NUI Galway.
The Thesis is based on an a study into software development practices in Start-Up Software companies; the study is aimed at understanding why;
1. They find it difficult to prioritise long term planning, (Product development decisions are made based on opinions of key personnel rather than deliberate planning, often resulting in rework and market failure).
2. are tempted to shortcut the software development process to bring products to market quicker by omitting crucial planning stages,
3. difficult to integrate product strategy with business strategy,
The study also looks at the notion that Software Engineering tools are designed for larger companies, with limited literature available into their applicability to smaller companies. As a result smaller development companies are overwhelmed when they even attempt to introduce process improvement.
The companies that I am focusing on and all software development companies based in Galway (3) and Dublin (1). They develop financial services software primarily for Insurance companies and the Banking sector.
I know that your company is in the same line of business. What I'm hoping to achieve is a Framework that will enable the small companies I am examining improve existing practices and hopefully follow a similar growth path that your company has.
The attached questionnaire is based on a European Software Best Practices survey devised back in 1997. I have changed it around a bit so that it follows, somewhat, the SDLC of a typical company, i.e. Requirements, Code and Test, Config Mgt etc.
You'll notice as well that the furthermost column on the right called ISO 15504 framework has a series of entries in relation to the questions being asked.
ISO 15504 framework is an alternative to CMMI for organizations that are interested in improving their software development process and attaining ISO
B-2
9001 certification, as it combines and enhances the methods provided by the CMM and the ISO 9000 quality standards.
By including this I will be able to ascertain the level by which a company is implementing a best practice approach to their software development cycle (based on
the attached Questionnaire) and then plot this on the ISO 15504 framework best
practice improvement model.
After this I hope to be able to show Strengths and Weaknesses and devise my own Framework that can help companies improve their process quickly and without significantly disrupting existing development practices.
I'd really appreciate if you could answer the attached questionnaire as best you can based on your companies practices. Total confidentiality is assured. The results will be summarised and individual responses will NOT be published.
After the responses have been analysed, I will email a summary report to all respondents.
I appreciate your help on this. Should you have any queries on the questionnaire don't hesitate to contact me on xxxxxxxx or else drop me an mail.
Regards,
Robert Staunton
C-1
Appendix C SPI Interview Questions
Based on your opinion, please answer each question by placing an X in the box that best describes your company’s position for each of the questions in the Table below.
What are your views on the following
Issues?
Strongly
Agree
Agree Disagree Strongly
Disagree
1. SPI is essential for the future success of my Company.*
2. By applying an SPI program my company can significantly improve the quality of software supplied to customers. *
3. SPI is not cost-effective initiative for my company. *
4. Senior Management in my company support SPI activities by arranging sufficient resources for training and development. *
• The results will be summarised and individual responses will NOT be public
C-1
D-
Appendix D D
ata
per
tain
ing
to P
are
to C
ha
rt
Affects
Frequency
Bugs
Enhance
New
Issue
Re-Work Spec
Re-Work Bugs
Freq. %
Cum Freq. %
Frequency Bugs
New
Issue
ReW
ork
Oth
er24
1311
81
239
%39
%54
%33
.30%
12.5
0%
Rat
ing
116
58
12
18%
57%
54%
73%
27%
Can
cels
88
04
04
13%
70%
100%
50%
50%
MV
R7
70
30
411
%81
%10
0%43
%57
%
Ren
ewal
s6
60
20
410
%91
%10
0%33
.30%
66.6
0%
VIN
54
10
41
8%10
0%80
%0%
80%
Total
6144
1725
617
Affects
Frequency
Freq. %
Cum Freq. %
Frequency Bugs
New
Issue
ReW
ork
Oth
er24
39%
39%
54%
33.3
0%12
.50%
Rat
ing
1118
%57
%54
%73
%27
%
Can
cels
813
%70
%10
0%50
%50
%
MV
R7
11%
81%
100%
43%
57%
Ren
ewal
s6
10%
91%
100%
33.3
0%66
.60%
VIN
58%
100%
80%
0%10
0%
Total
61
D-
Status Report Items Oct 31st - Nov 13th 2005
Ticket
Type
State
Affects
Description
Severity (1-
10)
New
Issue
ReWork
(Spec)
ReWork
(Bugs)
28
44
6B
ug
AL
Ca
nce
lsno
ca
ncel n
otice
ha
s b
ee
n m
aile
d7
Y
28
56
5B
ug
AL
Ca
nce
lsN
o-L
oss m
essa
ge
fo
r a
ge
nt p
aym
en
ts w
he
re p
olicy is c
an
ce
led
5Y
28
44
6B
ug
AL
Ca
nce
lsno
ca
ncel n
otice
ha
s b
ee
n m
aile
d6
Y
27
80
2B
ug
AL
Ca
nce
lsP
olicy c
an
ce
llin
g f
or
Su
sp
end
ed
Lic
J s
ho
uld
n’t
7Y
28
44
6B
ug
AL
Ca
nce
lsno
ca
ncel n
otice
ha
s b
ee
n m
aile
d7
Y
28
65
2B
ug
GA
Ca
nce
lsw
ill n
ot
let
us r
eq
ue
st
ca
nce
l6
Y
28
49
9B
ug
GA
Ca
nce
lscan
ce
l o
f 1
00
764
9,
wh
en
it
sh
ou
ldn
't5
Y
28
56
9B
ug
LA
Ca
nce
lsu/w
ca
ncels
are
no
t g
ivin
g th
e r
eq
uir
ed 3
0 d
ay n
otice
9Y
52
44
28
16
9B
ug
AL
MV
R#7
93
8 -
ca
nn
ot
se
e M
VR
on
cu
rre
nt
po
licy
6Y
28
62
4B
ug
AZ
MV
RIN
TL lic
en
se
en
do
6Y
28
41
8B
ug
AZ
MV
RIn
tern
atio
na
l lice
nse
's s
ho
win
g u
p o
n t
he
no
hit lis
t6
Y
28
35
9B
ug
GA
MV
Rre
qu
est
mvr
sta
tus
6Y
28
16
3B
ug
MS
MV
RP
OS
ap
plicatio
n m
vrs
ap
plied
bu
t se
ttin
g p
olicy u
p f
or
ca
ncella
tio
n7
Y
28
34
4B
ug
TX
MV
RS
R2
2 a
nd
No
Hit
for
TX
10
86
94
66
Y
28
50
4B
ug
TX
MV
Rpo
licy 1
08
73
06
du
plica
te p
oin
t ch
arg
es
7Y
44
34
28
48
6B
ug
AL
Oth
er
str
an
ge
ne
ss o
n p
olicy 1
04
89
73
6Y
28
58
4B
ug
AL
Oth
er
inco
rrect
ID c
ard
s f
or
policy 1
04
082
28
Y
28
48
6B
ug
AL
Oth
er
str
an
ge
ne
ss o
n p
olicy 1
04
89
73
6Y
NA
En
ha
nce
All
Oth
er
Ch
an
ge
vio
latio
n o
rde
r6
Y
NA
En
ha
nce
All
Oth
er
Wh
en
a c
laim
che
ck is s
ave
d w
rite
th
e c
he
ck d
eta
ils t
o t
he
no
tep
ad
5Y
28
50
7B
ug
All
Oth
er
Da
tes in
co
rre
ct
on
Vu
lca
n s
erv
ers
(serv
er
co
nfig
ura
tio
n e
rro
r)6
Y
27
85
2B
ug
All
Oth
er
Dis
pla
y e
rro
r Ite
ms o
nly
fro
m la
test
run o
n n
igh
tly lo
g s
cre
en
s.
7Y
NA
En
ha
nce
All
Other
24 hour backdating
9Y
NA
En
ha
nce
AZ
Oth
er
AZ
Sa
feq
uo
te7
Y
27
71
6E
nha
nce
GA
Oth
er
Inte
gra
te A
uth
id a
nd
Pri
nt
fro
m S
IU7
Y
NA
Bu
gG
AO
the
rLo
g e
rro
r in
GA
5Y
28
58
1B
ug
GA
Oth
er
Sta
te R
ep
ort
ing
issu
e w
ith
da
te6
Y
28
58
9B
ug
GA
Oth
er
Sta
te R
ep
ort
ing
fo
r p
olicy 2
20
22
6Y
27
71
6E
nha
nce
GA
Oth
er
Inte
gra
te A
uth
id a
nd
Pri
nt
fro
m S
IU8
Y
28
48
7E
nha
nce
GA
Oth
er
Ad
ditio
n t
o O
ve
rdu
e D
oc r
ep
ort
6Y
27
62
6E
nha
nce
LA
Oth
er
En
ha
nce
me
nt
- N
ee
d la
rge
r pa
ye
e b
ox o
n c
he
ck
4Y
28
49
0B
ug
LA
Oth
er
Un
ab
le t
o r
eq
uest
Inju
ry L
ett
er
6Y
28
54
1B
ug
MS
Oth
er
Ag
e 7
0+
an
d V
eh
icle
Ag
en
t 1
6+
, 2
6+
issu
es
7Y
28
53
1E
nha
nce
MS
Oth
er
Ne
ed
to
dis
pla
y in
sta
llm
en
t a
mo
un
t in
Sa
fequ
ote
to
Vu
lca
n6
Y
28750
En
ha
nce
MS
Other
CCI apps uploaded with incorrect dates
9Y
28
56
8B
ug
TX
Oth
er
can
no
t ch
an
ge
th
e s
tatu
s o
f sp
ou
se f
rom
no
t liste
d
to e
xclu
de
d6
Y
28
13
9B
ug
TX
Oth
er
Sa
feq
uo
te6
Y
28
56
8B
ug
TX
Oth
er
can
no
t ch
an
ge
th
e s
tatu
s o
f sp
ou
se f
rom
no
t liste
d
to e
xclu
de
d6
Y
NA
En
ha
nce
TX
Oth
er
Bri
dg
e in
fo t
o a
nd
fro
m Q
uic
kQ
uo
te.
7Y
155
812
4
D-
28
19
6E
nh
an
ce
AL
Ra
tin
gch
an
ge
d p
oin
ts9
Y
28
35
3B
ug
AZ
Ra
tin
gR
en
ew
als
fo
r O
ct
up
rate
fo
r te
rr a
nd
sym
bo
ls a
pp
lie
d t
o e
arl
y9
Y
28
55
0E
nh
an
ce
AZ
Ra
tin
gn
ee
d P
O B
ox z
ip c
od
es r
elo
ad
ed
6
Y
27
85
8E
nh
an
ce
AZ
Ra
tin
gA
Z r
ate
re
vis
ion
eff
10
/01
/05
ne
w 1
1/0
1/0
5 r
en
ew
8Y
28
57
3B
ug
GA
Ra
tin
go
ut
of
se
qu
en
ce
en
do
rse
me
nts
8Y
27
08
2E
nh
an
ce
MS
Ra
tin
gM
S M
inim
um
Lim
its In
cre
ase
eff
ective
1-1
-06
4Y
27
08
2E
nh
an
ce
MS
Ra
tin
gM
S M
inim
um
Lim
its In
cre
ase
eff
ective
1-1
-06
4Y
28
54
4B
ug
MS
Ra
tin
gIn
co
rre
ct
rate
s o
n p
olicy 1
06
70
20
7Y
28
59
7B
ug
TX
Ra
tin
gp
olicie
s liv
e 1
01
66
93
an
d 1
08
93
98
8Y
28
50
4B
ug
TX
Ra
tin
gp
olicy 1
08
73
06
du
plica
te p
oin
t ch
arg
es
8Y
28
49
5B
ug
TX
Ra
tin
gb
ad
billin
g a
mo
un
t o
n d
isp
lay a
cco
un
t in
qu
iry f
utu
re b
illin
g a
mo
un
ts 1
07
18
81
6Y
77
81
28
59
8B
ug
AL
Re
ne
wa
lsw
ron
g d
ate
s o
n r
en
ew
al
7Y
28
32
4B
ug
All
Re
ne
wa
lsD
up
lica
ted
re
ne
wa
ls a
re b
ack
8Y
28
58
6B
ug
ILR
en
ew
als
ren
ew
al p
en
din
g o
n c
an
ce
lle
d p
olicy
6Y
27
99
6B
ug
ILR
en
ew
als
ba
d e
xp
ira
tio
n d
ate
on
re
ne
wa
l6
Y
28
55
6B
ug
ILR
en
ew
als
err
or
wh
ile
re
ne
win
g 1
25
26
6-I
L-C
P6
Y
28
11
7B
ug
ILR
en
ew
als
no
n r
en
ew
al n
otice
did
no
t p
rin
t fo
r 0
00
12
88
7Y
40
24
28
00
3E
nh
an
ce
AL
LV
INV
eh
icle
Vin
s6
Y
28
38
6B
ug
GA
VIN
sh
ort
vin
s8
Y
28
57
2B
ug
GA
VIN
sh
ort
vin
s8
Y
28
47
3B
ug
MS
VIN
90
mo
de
l vin
s6
Y
28
53
7B
ug
MS
VIN
No
VIN
--N
ot
Be
ing
Allo
we
d T
o C
om
ple
te P
olicy In
Vu
lca
n7
Y
35
41
D-
