An Initial Study of Attitudes to CASE Tools in Agile
Development
A.J.Cowling
Dept of Computer Science,
University of Sheffield,
Regent Court,
Sheffield, S1 4DP, UK,
+ 44 0114 22 21823
A.Cowling@dcs.shef.ac.uk
J.S.Karn
Dept of Computer Science,
University of Sheffield,
Regent Court,
Sheffield, S1 4DP, UK,
+44 0114 22 21800
J.Karn@dcs.shef.ac.uk
Abstract
Research into software modelling/notations and CASE tools was carried out on the
Genesys Solutions software-company; a company committed to the XP management
development methodology. Information pertaining to the student’s background,
experiences and career plans was collected to see what effect this had on choice of
development tools/methodologies. Of particular interest was the overall impression the
Genesys students had regarding CASE tools. Initial findings presented indicate that
proponents of “agile” methodologies still find many aspects of traditional software
engineering useful. This is apparent from the ratings given to certain modelling
notations and certain CASE tool features.
Keywords
CASE tools, Empirical Software Engineering, eXtreme programming, modelling
notations
1. Introduction
There are now many different and in many cases competing software development
methodologies. These range from what have been termed “agile” methods, to traditional
so-called “heavy” models. The agile methods place less emphasis on design
documentation and processes and more emphasis on simple design and open workspace.
The traditional methods on the other hand place great emphasis on design documentation
and on systems analysts to determine and document detailed user requirements.
Extreme programming (XP) is perhaps the most well known agile methodology.
Founded in 1996 by Beck [1], XP has been at the heart of many heated, often
acrimonious debates between traditional software engineers and XP proponents. There
have been many claims and counter claims including “XP is undisciplined hacking”,
“Proponents of XP are trying to destroy the foundations of software engineering”[2].
Then on the XP side we have almost sanctimonious diatribes that are put forward by XP
proponents, here are some examples “The methodology allows the user to change the
requirements because that is real! XP expects to achieve many small but useful
1
deliverables to meet the speed of change in an Internet world.” [3]; “XP is "extreme" in
that it takes 12 software development "best practices,"and applies them to the extreme.”
[4], “If XP is not perfect, at least its heart is in the right place.” [5].
The full extent of this debate is outside the scope of this report as is any attempt at
rapprochement between the major protagonists.
In comparison with the well-established traditional methods; agile methods are still in
their infancy. So it is therefore logical to state that empirical research into agile methods
is also in its infancy. This presents opportunities for empirical software engineers.
The University of Sheffield has developed a facility where agile methods can be studied.
Fourth year and MSc students in the Department of Computer Science at the University
of Sheffield run a professional software house known as Genesys Solutions [6]. The
academics ultimately responsible for driving the Genesys projects introduced the students
to XP several years ago. It is Genesys Solutions and other undergraduate group projects
that make up the “Software Engineering Observatory”. The observatory is a place where
empirical researchers can observe, question or interview software developers working on
real industrial projects. The existence of this observatory allows many empirical studies
to be carried out. Several PhD students from the Verification and Testing research group
have carried out empirical studies of XP. These include Holcombe et al’s comparative
experiment involving XP and traditional design led approach [7], and Holcombe et al’s
initial observation of student impressions of XP [8].
2. Background
XP was designed to implement a simple, yet effective way to enable groupware
development [3]. XP attempts to improve a software project in four ways;
communication, simplicity, feedback, and courage. One of the fundamental ideas of XP
is that there is no process that fits every project as such but practices that should be
tailored to each individual project [9]. In 1999 Beck was forced to admit that XP was not
suitable for all projects, he also admitted that all of XP’s limits had not been identified. It
is clear from the admissions of Beck that more empirical research must be carried out in
this area.
XP is aimed at small to medium sized teams. The physical environment is also
important; communication and co-ordination must be maintained at all times. Business
culture is another focal issue in XP. If there is any resistance against XP principles on
behalf of project members, management or customers, then it may fail the entire process.
A full description of the 12 core activities of XP can be found in Beck’s book “eXtreme
Programming eXplained: Embrace Change”. [9]
Genesys Solutions operates along the following lines. Typically in each academic year at
the University of Sheffield there are between 5 and 8 Genesys teams working on separate
software projects. Each project has a real industrial client, so professional standards are
2
not only encouraged they are expected. The students are a mixture of fourth year
Sheffield students working on Genesys for the completion of their degree or students
taking a taught MSc in which Genesys is the core element of the programme. The MSc
students are from many different universities, this means there is a lot of diversity in the
backgrounds of the Genesys students.
As the Genesys Company is using an agile method it is interesting to see which, if any
features of traditional software engineering are important to them. This is crucial because
the estimation of resources for XP driven projects needs to be considered in a different
way from traditional projects. As a result of this the students are starting from a position
where they need to think about things rather differently [8]. In spite of the XP emphasis,
the Genesys students are still under obligation to produce requirements documentation as
this is expected from the clients. This means that XP in its purest form is not being used
by Genesys; alternatively it could be argued that Genesys are following Beck’s advice
when he stated that only the XP practices that could be tailored to a particular project
should be used.
3. Qualitative Technique Used
Empirical software engineers now face the kind of challenges that social scientists have
been trying to circumvent for years. That is they are dealing with the most unpredictable
phenomena around-human beings.
Software development presents a number of unique management and organisational or
“people problems”, that need to be addressed and solved in order for the field to progress.
In the words of Seaman “ It could be argued that human behavior is one of the few
phenomena that is complex enough to require qualitative methods to study it” [10]. It is
crucial to keep in mind this insuperable fact if one wishes to achieve valid results from
empirical research. An informative starting point that gives a good insight into human
factors of software engineering is the work of DeMarco and Lister [11], they address a
wide range of social issues, this work is useful to all software development managers.
Certain aspects of software engineering are open to quantitative methods; this was kept in
mind at all times during this research project. As a result of this a questionnaire was
designed that would elicit both quantitative and qualitative responses from the Genesys
students.
4. Objectives of Study
There were three overall objectives in this work. The first was to get some idea about the
background of Genesys students. This background information would provide the
foundation for the rest of the project. Only by finding out about the student’s
backgrounds could analysis be made as to whether certain types of people will hold
differing opinions with regards to CASE tools and modelling notations. Gender,
ethnicity, previous country and previous university are all variables that could possibly
have an effect on the attitudes of the subjects involved.
3
The second objective was to ascertain the general feeling of the Genesys students with
regards to CASE tools and the effect of the aforementioned tools on software
development. An important part of this objective was to classify opinions on prominent
features of CASE tools.
The third objective involved prompting the students into giving ideas of how CASE tools
could be improved. Ultimately this objective sought to find out whether students would
be interested in using re-designed CASE tools.
5. Justifications for Research Method Used
A questionnaire was the chosen method for gathering data in this project. This choice
was made primarily because this study represents a starting point for a broader area of
research and because a questionnaire represents the least expensive option in terms of
time and resources when seeking a response from a large number of people.
Questionnaires are usually quick and therefore cost effective to administer and to score
and a lot of data can be gathered by using questionnaires as surveys. Interviews and/or
participant observation were not deemed to be good starting points for this project, as
they tend to be more personal and involve a lot more time. These techniques will be used
later in the research. Getting hard, quantitative data about user attitudes or opinions is
good, but this is never the whole story. In addition, one should also ask more intense
questions to elicit high quality qualitative data. This means interviewing the students and
observing them.
Questionnaires are not free of problems. The major problem is low feedback. This is a
massive problem in the case of postal surveys. This is verified by Gibson who states
“Low response rates are a problem for postal surveys (less than 10% is not uncommon)”
[12]. In this project low feedback was more of a minor hindrance then a serious
stumbling block. A 63% response rate was achieved. This figure may look impressive
compared to the disastrous response rates of some postal surveys but it is slightly
misleading. Most students completed the questionnaire as soon as they received it. The
problem was the students who didn’t do this; they tended to not fill it in at all. There are
two possible explanations for the 37% of students who did not fill in the questionnaire.
The first reason is that it could be attributed to the pressures students were facing in their
projects as opposed to insipidity in the face of empirical software engineering research.
The second reason has more negative undertones; the people who did not fill in the
questionnaire could be the same students about whose progress the Genesys management
has expressed concerns. If this is the case then it is no big surprise that they failed to fill
in a research questionnaire. The 63% response rate turned out to be a representative
sample. 53% of the students who responded were Sheffield students, i.e. all of their
previous experience in higher education had taken place at the University of Sheffield.
So this left us with 47% non-Sheffield students, one had to be pleased with this response
as it was almost an equal split between people with different backgrounds. In all the
response rate caused no serious problems.
4
6. Design of Questionnaire
The final questionnaire was essentially tri-partite in nature. The first part was concerned
with the background of students. Of particular importance in this section were the
previous country and previous university questions. These questions would allow
comparisons to be made between students whose previous university education had taken
place at the University of Sheffield with those who had been educated at other institutions
of Higher Education.
The second part of the questionnaire dealt with the career aspirations and IT background
of the Genesys students. With luck this would allow us to establish such things as to
whether people who aspired to be programmers had less experience with and were less
comfortable with modelling notations/software then those who aspired to be software
engineers or systems analysts.
Each student’s experience with modelling
software/notations and management development methodologies was scrutinised in this
section.
Crucially features of modelling software/notations and management
development methodologies that the students found helpful and unhelpful could be fully
discussed in this section.
The final part of the questionnaire dealt with attitudes towards and prior experience with
CASE tools. Students with prior experience were then asked to rate CASE tool features
on a scale of 1-10. This would help to establish any propinquity between features.
Students were then asked what effect CASE tools have had on the development of
software, choices ranged from “Made Developing Software Much Easier”, to Severely
Hindered Software Development”.
Students were then asked if any other factors influenced their decision as regards the
effect of CASE tools on software development. Of particular relevance were people with
negative experiences of CASE tools. It was hoped that this would give some insight into
the limitations of current CASE tools. Logically following on from this was a question
probing for opinions, which could improve the usability of current CASE tools. This
sequence of questions came to its logical conclusion by asking the students whether they
would be interested in using re-designed CASE tools. Those who showed no interest
were cordially invited to express the reasoning behind their intransigent attitude towards
CASE tools.
5
7. Students Background
7.1 Previous University and Career Preference
Of the 30 Genesys students who completed and returned the questionnaire 16 had
completed their previous education at the University of Sheffield and 14 had completed
their previous education at other universities. The other universities ranged from ones in
the UK such as Essex to places as far-flung as India and Mexico.
Out of the Sheffield students 8 people expressed an interest in programming as a career
choice. This was compared to 11 who expressed an interest in software engineering.
One Sheffield student showed an interest in research as a career choice, whilst one
specified that they would seek a career outside the milieu that is IT.
A similar pattern emerged amongst the non-Sheffield students. Again software
engineering proved to be the most popular career choice with 7 students showing an
interest in this field. The overall advantage of software engineering as a career choice
was more tenuous amongst the non-Sheffield students. This was primarily because 6
people expressed an interest in programming and 3 expressed an interest in systems
analysis. One student chose Database Administrator as a career choice. Overall the nonSheffield students seemed to favour a wider range of career options.
7.2 Modelling Software/Notations Used
Every Sheffield student had experience with UML and Discovery. Two Sheffield
students also had experience with Z [13]. UML, Discovery and Z are all part of the
undergraduate degree in Sheffield. The surprising aspect here is that so few people
mentioned Z. This could be because the students did not really see a formal method like
Z as a modelling notation or because they had either forgotten it or not taken the Z
module.
The non-Sheffield students once more showed more diversity with modelling notations
used. UML was a popular notation, yet none of these students had had contact with
Discovery [14]. This was not surprising as the main architect of Discovery is Dr. Tony
Simons a lecturer from the University of Sheffield and as yet it has not been widely used
outside of the University of Sheffield. Structured analysis notations were prevalent
amongst the non-Sheffield students. Two classical structured analysis notations;
Yourdon [15] and SSADM [16,17] had been used by 5 of these students.
6
7.3 Management Development Methodologies Used
XP was chosen by over 90% of the students. These findings were inevitable, after all XP
was the chosen methodology for the Genesys projects. Only one other development
methodology was mentioned, this was the Microsoft Solutions Framework [18].
7.4 Helpful/Unhelpful Features of Modelling Software/Notations
7.4.1 Sheffield Students
It would be perverse not to mention the near reverence in which many of the Sheffield
students held certain principles of UML. One student said all of UML was helpful,
others highlighted the modelling notation. Use Cases and class diagrams were also held
in high regard. Overall UML diagrams were overwhelming seen as a helpful feature of
modelling notations. The student’s strong endorsement of UML principles gave insight
into how aspects of this particular modelling notation would have been a good aid during
their undergraduate years. This does not mean that the students were all fully in favour
of the finer details of UML; all it means is that certain aspects of the UML notation have
proved to be helpful.
The Sheffield students did not however issue a blank cheque in favour of modelling
notations. Discovery took heavy criticism from some quarters and was even dismissed as
“nonsensical” by one disgruntled user. Typically criticisms of Discovery ranged from
“complicated notations”, to “lack of clarity”. Other students levelled criticism at
notations in other modelling methods, saying they were unclear and “strange”. In spite of
these aberrations the central theme that shone like a beacon was that certain UML
principles had proved to be very helpful.
7.4.2 Other Students
The diagrammatic approach of UML was seen as a helpful feature of modelling notations
by many of the non-Sheffield students. Comments such as “UML is helpful” and
“Systematic Diagrammatic Approach of UML” highlighted the zeal that the students had
regarding these features of UML.
There was only one criticism levelled at modelling notations/software by this set of
students. This solitary criticism stated that it was “Not always easy to create class
diagrams”. In response to this it must be observed that no one has ever suggested that
designing software was always going to be a straightforward affair.
7
7.5 Helpful/Unhelpful Features of Management Development Methodologies
7.5.1 Sheffield Students
The results in this section are essentially based on one methodology, namely XP. Helpful
features included pair programming, and exhaustive requirements lists. Certain features
of XP were deemed to be very helpful. However no student issued a blank cheque stating
that all of XP was helpful.
The helpful features of XP contrasted sharply with the students who found XP unhelpful.
Whereas the people who found aspects to be helpful highlighted them appropriately, the
people who criticised XP levelled blanket denunciations at this methodology. Inimical
comments about XP included “XP is unhelpful” and “Do not Understand Meaning of
XP”.
7.5.2 Other Students
All of the results in this section also pertained to XP. Pair programming was seen as a
favourable feature, and one student claimed that XP as a whole was helpful. Bizarrely
the student, who stated that XP was helpful, also stated “XP can also be unhelpful”. It is
best left to the discretion of the individual readers of this report as to what to make of this
unusual response.
8 CASE Tools Experience
There was a marked difference between the Sheffield and non-Sheffield students when it
came to prior CASE tool experience. For the Sheffield students 69% had some prior
experience with CASE tools. By contrast the results for the non-Sheffield students
showed that only 23% of them had prior experience with CASE tools. This result could
suggest that many of the non-Sheffield students have not had much experience with
courses that emphasise requirements engineering and systems design.
Percentage of Sheffield
Students Who Have Used
CASE Tools
Other Students Experience
with CASE
23%
31%
No
No
Yes
Yes
69%
77%
8
8.1 Usefulness of CASE Tool Features On a 1-10 Scale
Most CASE tools include a selection of, or have all of the following features: Data,
Process and State Modelling, Bug Tracking, Enforcement of Standards, Help Authoring,
Real-Time Multi-Task Design, Regenerability of Code, UML Modelling (specific to
UML not to all modelling notations), Quality Code Creation, and WYSIWYG Screen and
Report Building. What follows is a synopsis of the results regarding the aforementioned
features.
8.1.1 Data, Process and State Modelling
This proved to be a helpful feature of CASE tools. 5 students rated this feature as 7 or
above and 2 people even rated it as 10. It was seen as an average feature (5 or 6) by 4
students, only 2 students rated it as lower than average. 3 people had not used this
feature during previous usage of CASE tools; as a result of this it was impossible for
them to assign a rating to this feature.
A ll S tu d e n ts R a te D a ta , P r o c e ss
a n d S ta te M o d e llin g
3
0
T im e s
R a t in g
S e le c t e d
4
2
5
1
6
7
0
0
4
5
R a t in g
6
7
8
8
1 0
1 0
( 1 -1 0 )
8.1.2 Bug Tracking
Overall respondents had either not used this feature or rated it as less than average. 6 of
the 7 people who had used this feature rated it as 5 or less.
A ll S t u d e n t s R a t e B u g T r a c k in g
T im e s
R a t in g
S e le c t e d
6
5
4
3
2
1
0
0
2
3
4
0
2
3
4
5
5
8
8
R a t in g ( 1 - 1 0 )
9
8.1.3 Enforcement of Standards
This was viewed as a very helpful feature by certain students (rated 8 or 9). Other
students seemed indifferent; the highest number of students had not used this feature.
A l l S tu d e n ts R a te E n fo r c e m e n t
O f S ta n d a r d s
T im e s
S e le c t e d
4
0
3
3
2
4
1
5
6
0
0
3
4
5
6
8
9
8
R a t in g ( 1 - 1 0 )
9
8.1.4 Help Authoring
It was difficult to form any opinions about the usefulness of this feature. This was
primarily because over half the relevant students had not used this feature. There were
some extreme differences amongst the people who had used it, one person gave it the
lowest possible mark 1, whilst another gave it a 10.
A ll S tu d e n ts R a te
A u th o r in g
H e lp
8
T im e s
R a t in g
S e le c t e d
7
6
5
4
0
1
2
3
2
1
0
5
6
0
1
2
5
R a t in g
6
1 0
1 0
(1 -1 0 )
8.1.5 Real-Time Multi-Task Design
A mixed bag of results was recorded as regards this feature. Results ranged from 1 to 9.
However the majority of the marks rated as less then average. This suggests that the
students did not view this feature as positively as certain others.
A l l S tu d e n ts R a te R e a l-T im e
M u lti-T a sk D e sig n
0
1
T im e s
R a t in g
S e le c t e d
4
3
2
1
2
3
4
5
0
0
1
2
3
4
5
6
7
6
9
7
R a t in g ( 1 - 1 0 )
9
10
8.1.6 Regenerability of Code
This was a decidedly average feature. Most of the marks fell within the 4, 5 and 6 range.
The two extremes for this feature were 2 and 9.
A ll S tu d e n ts R a t e
R e g e n e r a b ilit y o f C o d e
T im e s
R a t in g
S e le c t e d
4
0
3
2
2
4
1
5
0
0
2
4
5
6
7
6
9
7
R a t in g ( 1 - 1 0 )
9
8.1.7 UML Modelling
The results showed that this was clearly a helpful feature. 6 people rated this as 8 or
above, 2 people even gave this feature the maximum 10.
A ll S t u d e n t s R a t e U M L
M o d e llin g
0
3
T im e s
R a t in g
S e le c t e d
3
2
5
1
6
7
0
0
3
5
6
7
8
9
8
10
9
R a t in g ( 1 - 1 0 )
10
11
8.1.8 Quality Code Creation
Initial results indicate that this is one of the least useful CASE tool features, at least in the
opinion of Genesys students. 5 people even rated this feature as 2 or 1, this suggests that
rather than helping this feature could have severely hindered these people. This result
baffled the researchers involved with this paper. Either the students did not really
understand the meaning behind this feature or they prefer to take 4-5 hrs writing code by
hand as opposed to a 15 minute job when a CASE tool would create the code needed. It
is hoped that the negative feedback regarding this feature has more to do with lack of
clarity on the researchers part rather than hostility from the students.
A ll S t u d e n t s R a t e Q u a lit y C o d e
C r e a t io n
Selected
Times Rating
5
0
4
1
3
2
2
5
1
7
0
0
1
2
5
7
8
8
10
10
R a t in g ( 1 - 1 0 )
8.1.9 WYSIWYG Screen/Report Building
Along with UML modelling and Data, Process and State modelling this was seen as a
very useful feature. 5 people rated it as a 9 or 10. Although overall it was seen as
helpful, to some people this didn’t seem to be the case at all. A sizeable minority only
rated this feature as a 3.
A ll S tu d e n ts R a te W Y S IW Y
S c re e n /R e p o rt
5
T im e s
S e le c t e d
4
0
3
3
2
6
1
7
0
0
3
6
R a t in g
7
9
1 0
(1 -1 0 )
12
9
1 0
8.2 Effect of CASE Tools on Software Development
The sample was divided into Sheffield and non-Sheffield students. Each student with
prior experience was asked how the use of CASE tools had affected past software
development projects.
8.2.1 Effect for Sheffield Students
The responses elicited from Sheffield students seemed to indicate that CASE tools had on
the whole propagated a positive effect on the development of software. Three people
claimed that CASE tools hindered software development, this compares to 6 people who
claimed CASE tools made developing software easier. Two people were indifferent and
stated explicitly that CASE tools made no difference.
S h e ffie ld S tu d e n ts O p in io n O n
E ffe c ts o f C A S E T o o ls
6
5
4
3
2
1
H in d e r e d
S o ftw a r e
D e v e lo p m e n t
M ade
D e v e lo p in g
S o ftw a r e
E a s ie r
Not M ade Any
D if f e r e n c e
0
8.2.2 Reasoning Behind Sheffield Choices
Sheffield students praised the way CASE tools helped the design of software and that
they were very good for large-scale projects. The students who were more cautious
pointed out that the learning curve involved with CASE tools and project size influenced
their decisions.
8.2.3 Effect for non-Sheffield Students
The result yielded here could be regarded as the zenith for proponents of CASE tools.
All students stated that Case tools made developing software easier. Before the CASE
tool advocates start to have utopian delusions, it must be kept in mind that this result
must be treated with a degree of equanimity. The total number of non-Sheffield students
with CASE tool experience was small in comparison to the Sheffield students.
13
Other Students: CASE Effects
4
CountOfEffect
of CASE
Tools on
Softw are
3
2
1
0
Made Developing
Softw are Easier
8.2.4 Reasoning Behind non-Sheffield Choices
One student gave an explanation to indicate why they made the choice they did. The
reasoning was that CASE tools helped to clarify the structure of a system.
8.3 All Students Features that Could Improve CASE Tools
Only 10% of the students who completed the questionnaire gave any sort of response to
this question. The most useful issue raised was that CASE tools should do one or two
things well, instead of trying to be all things to all men.
8.4 Interest in Re-Designed CASE Tools
All students regardless of prior experience were asked if they would be interested in
using re-designed CASE tools. All information given in this project and follow on
projects would help to gather a set of requirements, based on the students own
experiences.
8.4.1 Sheffield Students Interested in Re-Designed CASE Tools
Generally speaking the Sheffield students tended to broach this subject with a safety-first
approach. Only 2 students emphatically stated that they would be interested in using redesigned CASE tools. The overwhelming majority of Sheffield students gave “maybe”
as their answer to this question.
Total
S h e ffi e l d : I n te r e ste d i n U si n g R e D e sig n e d C A S E T o o ls
7
6
5
4
3
2
1
0
M aybe
No
Ye s
M aybe
No
Ye s
C h o ic e s
14
8.4.2 Non-Sheffield Students Interested in Re-Designed CASE Tools
In sharp contrast to the Sheffield students, this set of students broached this subject with a
lesser degree of trepidation. The majority of non-Sheffield students were in favour of
using re-designed CASE tools. Only one student upset the almost total state of equipoise
and stated that he/she would not be interested in using the aforementioned tools.
Others Interested In ReDesigned CASE Tools
10
8
Total
8
6
4
4
1
2
0
Maybe
No
Yes
Choices
8.5 Reasons for No Interest in Re-Designed CASE Tools
On first glance it appears that students who answered this question had very differing
agendi. On the one hand there were people who gave responses such as “ Never used
them”, and “Don’t Understand them”, whereas other people claimed that “Negative
Experiences” had put them off. This response seems reasonable, as negative aversions to
certain things are a primal feature of human and indeed animal behaviour. One
respondent quipped that each software designer could use his/her own notation that is
made up on the fly. Another querulous response simply stated, “CASE tools do not work
with XP”.
9 Evaluation and Future Directions
The results of this project support the idea that modelling notations and CASE tools are
effective when used in the design phase of the software lifecycle. The subjects were all
involved in agile projects so these initial results show that certain phases of the traditional
software development process are still seen as useful and/or helpful by the majority of
students. It must be kept in mind at all times that not all of the Genesys students
responded; therefore it is unwise to make generalisations. But from the students who did
respond a representative sample was achieved.
Future work will involve researching into more depth the general feeling about the
analysis and design phase of software development, and what students find difficult or
enjoyable in these areas. This will give an idea of the meaning student’s give to terms
like “software engineer” or “systems analyst”. All of the time this is going on students
15
will be prompted for ideas on how to make software design easier. This will help future
research when drawing up requirements analysis and requirements specification
documentation concerning the theoretical design of a CASE tool used to aid agile
developers.
Another angle for future research is concerned with the initial background section.
Students who see software engineering or systems analysis as a career choice may have
different working habits than those who see themselves as programmers. Further
research into this area would involve looking at the personality types of people involved
in Genesys and ascertaining whether or not certain personalities work well in software
projects. It will be particularly interesting to get feedback from students working in these
software groups regarding the personality (or lack of) and working habits of their fellow
team members. This would give us an idea of how to achieve a cohesive, happy group.
Something that all software managers attempt to achieve.
10 Discussion
This project provided a useful starting point that could metamorphose into several
legitimate avenues of empirical research. The information gathered regarding the
background and career aspirations of Genesys students could be used as the foundational
level for further projects that will address in detail issues such as group and individual
personality types, and how they affect software development teams.
The information gathered that related to attitudes towards and experience with CASE
tools is also excellent foundational data. This forms the basis from which requirements
analysis and requirements specifications documents could be written to work with the
process of completing a theoretical design of a CASE tool. The responses from the
participants show what features should be paramount when the time came to carry out
this design. Modelling notations were overwhelmingly seen as helpful and as a useful
feature of a CASE tool. This was true for Data, Process and State Modelling and UML
Modelling. When one combines this with the high ratings given to WYSIWYG
Screen/Report building it becomes apparent that participants are keen to use modelling
notations and they would like to see how their design is progressing by using WYSIWYG
techniques. Any future design of a CASE tool must take these features into account. An
interesting conclusion that can be drawn from the popularity of modelling notations and
WYSIWYG features is that when designing software the participants would prefer to
work at a much higher level of abstraction than source code. This would suggest that
many of the participants are still interested in traditional development techniques that
take advantage of modelling notations, rather than using the rather crude measure of
basing software design purely on source code. The opinion that participants would prefer
to work at a higher level of detail than source code is vindicated by the low ratings given
to CASE tool features such as bug tracking and code regenerability. Again this suggests
that working purely with code; even within a CASE environment is neither desired nor
realistic to certain sections of Genesys Solutions.
16
Future research along similar lines is needed to substantiate the results presented in this
paper. This research may not be confined to Genesys Solutions but could also take in
other students from the University of Sheffield and even outside industry. Of particular
interest is to what extent features of traditional development are seen as useful by agile
developers and which traditional features they feel could improve their current
development process.
Another area of future research is the issue of group and individual personalities and to
ascertain whether the psychological make-up of people and groups has an effect on the
software development process. This could yield useful results in terms of how software
development teams should be organised, it could also highlight how certain personalities
favour traditional or agile methods.
The aspects mentioned in this discussion need not be carried out in isolation; there is a
strong possibility that an amalgamation of the areas could take place. More detailed
questionnaires dealing with software engineering techniques and psychological tests are
legitimate extensions of this research. A closer examination of the area(s) under study
would also require interviews and observation. To be successful this research would
require the use of triangulation, the effective use of more than one research technique.
This would improve the research skills and investigative analysis of any person involved
in any area of research.
Acknowledgements
We would like to thank Mike Holcombe and Marian Gheorghe for allowing us to carry
out research into Genesys Solutions. Also to thank them for allowing the students time to
fill in the questionnaire.
References
1. About the Author: Kent Beck,
http://c2.com/ppr/about/author/kent.html
2. P. McBreen, Questioning Extreme Programming,
http://www.mcbreen.ab.ca/talks/ICE2002Questioning.pdf
3. Extreme Programming the New Zealand Way, Why XP?
http://www.xp.co.nz/WhyXP.htm
4. J. A. Kanbay, Extreme Programming,
http://www.serverworldmagazine.com/webpapers/2002/01_kanbay.shtml
5. I. Alexander, The Limits of Extreme Programming,
http://www.computer.org/SEweb/Dynabook/AlexanderCom.htm
17
6. Genesys Solutions,
http://www.genesys.shef.ac.uk
7. M Holcombe, M Gheorghe and F Macias, Empirical Experiments with XP,
http://www.xp2002.org/atti/Macias-Holcombe--EmpiricalexperimentswithXP.pdf
8. M Holcombe, M Gheorghe and F Macias, Teaching XP for Real: Some Initial
Observations and Plans, XP 2001 Conference Procedures, pages 14-17
9. K Beck, Extreme Programming Explained: Embrace Change. Addison Wesley
Longman, Reading Mass, USA 2000.
10. C Seaman, Qualitative Methods in Empirical Studies of Software Engineering, IEEE
Transactions on Software Engineering ,25.4, July/August 1999, pages 557-572
11. T. De Marco, T. Lister, Peopleware:Productive Projects and Teams 2nd Edition,
Dorset House Publishing, NYC, NY, USA, 2000.
12. N. Gibson, Manage Feedback from Customers,
http://www.commstrade.com/editorial/ItemDetail.asp?ItemID=3610
13 M. Spivey, The Z Notation: a reference manual 2nd Edition, Prentice-Hall, NYC,
NY, USA, 1992
14. Tony Simons, Discovery Homepage,
http://www.dcs.shef.ac.uk/~ajhs/discovery/
15. E Yourdon, Modern Structured Analysis, Prentice-Hall, Upper Saddle River, New
Jersey, USA, 1989
16. M Eva, SSADM Version 4: A User’s Guide Second Edition, The McGraw-Hill
International Series in Software Engineering, The McGraw-Hill Book Company,
Maidenhead, Berkshire, UK, 1994
17. M Goodland, C Slater, SSADM Version 4: A Practical Approach, The McGraw-Hill
Book Company, Maidenhead, Berkshire, UK, 1994
18. Microsoft Solutions Framework,
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/tandp
/innsol/Default.asp
18