System Development Survey
Dear Reader,
This survey is part of a PhD research study looking at the links between the
organisational context in which a system is developed, the problem being
tackled and the system development strategy utilised. Currently, knowledge of
the type of pressures and problems faced by developers is fragmented across
case studies particular to individual disciplines (HCI, Safety-related etc). I
am looking for input from system development professionals from a range of
disciplines in order that parallels (and contrasting interpretations) across
different areas of system development can be drawn.
Those of you with form-compatible WWW browsers are cordially invited to
contribute to this research by accessing a survey web-page at:
http://boom.cs.ucl.ac.uk/staff/dfulton/survey.html
For those who are interested in the research but do not have form-compatible
web browsers, a text version follows which can be returned to:
·······@cs.ucl.ac.uk
Many thanks!
David Fulton
--------------------------------------------------
Please fill in all sections in as much detail as possible. The form should take
around 10-15 minutes to complete.
Personal details are only recorded so that we can get back to you - if
required. Otherwise, individuals remain anonymous and your input is kept
confidential.
Your name:
Organisation:
Email Addr:
1: The Project
You are asked to complete this questionnaire in relation to a recent (or
current) project with which you are familiar.
1.1) What was the title of the project?
1.2) Please give a brief description of the project? (if possible):
1.3) What system characteristics did the product incorporate? (more than one of
the options can be ticked by marking them with an 'X'):
___ Interactive
___ Safety-Related *
___ Real-Time
___ Embedded *
___ Defence
* Safety-related projects being developments where safety (in whatever form) is
an important non-functional requirement. Embedded projects being software
systems that are used to run hardware
2: Focus of Analysis/Initial Statement of Objectives
2.1) Please mark the development paradigm used by the project:
___ In-house development- for another part of the company
___ Contract-based development- for an outside client
___ Generic/Shrink-Wrap development- for general use
2.2) Which of the following most closely describe the starting point for the
project?
___ The project started out without a clear view of the system
to be developed, or of the underlying problem to be tackled
___ The project started out with an explicit problem to tackle
but without a clear definition of the expected application
___ The project started with an explicit problem to ameliorate
and a clear definition of the expected application
___ The project started with an explicit problem to solve and a
clear definition of the expected application. In addition,
the client has set the acceptance criteria for the project,
and penalty provisions if criteria were not met
3: Development Pressures
3.1) Was the system to be developed designed to replace an existing manual or
automated organisational system?
___ Yes?
___ No?
3.2) Which of the following describes the development pressures (in generating
and using requirements) faced by the project?
NB: Only make a choice here if the system was to be used by a user/operator and
had an identifiable user population.
___ Users/Representatives had little or no experience with a
system of this kind. As a result, they were unable to offer
tangible requirements or ideas until a concrete
representation (prototype) was available
___ Users/Representatives had some experience with similar
systems in the past and they were able to put forward ideas
and requirements for future systems
The next section looks at the skills of developers and the degree to which
their familiarity with the application being developed contributed to their
knowledge of a suitable definition.
3.3) Which of the following, in your opinion, describes the degree to which
developers (in general) were experienced in this type of development?
___ Developers had limited experience in developing a system of
this kind and some experimentation was required to evaluate
technical options
___ Developers had some experience of developing similar
systems in the past and had a limited ability to predict
changes or other types of uncertainty
___ Developers were experts in a particular problem domain
and had a clearer understanding of technical options and
possible solutions
4: The Organisational Context
In considering the organisational context, we are really looking at the context
within which the project is based, and are therefore looking at the structures
and processes (specific to the project) within the developer organisation, the
client organisation (if the two differ), and developer/client communication.
4.1: Structure of the project
4.1.1) Which of the following most closely describe the job roles within the
project?
___ Responsibilities and job roles were explicitly defined.
No-one on the project could carry out tasks for which they
did not have authorisation
___ While there were notional job roles and responsibilities,
project personnel tended to carry out a range of tasks when
they were required to do so
4.1.2) Which of the following most closely describes the manner in which
changes or requests for verification were addressed?
___ All requests for changes had to be routed via the project
manager or to personnel at a higher level in the project
structure.
___ Possible changes would generally be discussed by the
appropriate parties before action was decided (on an
informal basis).
4.2: Processes within the project
4.2.1) Which of the following describe the degree of stability in
project-related processes?
___ Processes were largely stable. Interaction between
stakeholders in the project occured at pre-determined
times.
___ Processes were subject to change. Interaction between
stakeholders in the project was random - occured as and
when needed.
5: System Development Strategy
5.1) In your opinion, which of the following points most closely summarise the
system development strategy that was taken?
___ The emphasis was on a constantly changing specification,
adaptive code and minimal use of design documentation.
___ The emphasis was on the use of experimental methods,
including evolutionary or iterative prototyping.
___ The emphasis was on producing a robust design and
implementation, but allowing limited flexibility and
ability to react to change.
___ The emphasis was on the production of error-free code
and an accurate transformation of the specification into
design material.
5.2) Which of the following most closely match the model of development used?
___ Stage-based models of development: A variation on the
waterfall software life-cycle model is used
___ Iterative models of development: Spiral or iterative build
models of development are utilised
5.3) Which of the following most closely match the emphasis of the development
strategy?
___ Emphasis on high-level design: Design activities are
closely regulated and monitored
___ Emphasis on a mixture of high and low-level design:
Although some procedural restrictions may be in place,
low-level design tasks are largely unregulated
___ Emphasis on low-level design: There was little regulation
of day to day practice
6: Outstanding issues
6.1) As far as you can recollect, what forms of changing requirements had a
particular impact on the project and what was the extent of that impact?
Answers on the bi-polar scale refer to how confident you are with options at
each end of the scale. If you feel that there is a 'major impact' choose the
option on the far right. If you felt there was some impact, but you don't feel
you could define it using either of the opposing labels, then choose one of the
options in-between
6.1.1) Mutable Requirements: Changes brought about by changing organisational
goals and environmental turbulence eg. change because of organisational
restructuring mid-way through the project
Negligable impact 1 2 3 4 5 Major impact
6.1.2) Consequential Requirements: Changes brought about as a consequence of
particular design decisions, or through the testing of prototypes eg. change
when users discover new ways of working etc, change when technical staff
discover a new way of solving a technical problem
Negligable impact 1 2 3 4 5 Major impact
6.1.3) Migration Requirements: Changes when there are difficulties in moving
from the current state to the desired state eg, change when considerations have
to be made for the technical platforms the working version will have to work
on, data management etc
Negligable impact 1 2 3 4 5 Major impact
6.1.4) Emergent Requirements: Changes when participants slowly develop a better
understanding of what they really want eg, Users clarifying what they really
want and negating previous requirements
Negligable impact 1 2 3 4 5 Major impact
6.2) Was a method or methodology used in order to aid the analysis and design
of the system?
___ Yes?
___ No?
6.3) If the answer to the last question was 'Yes', which method(ology) was
used?
___ Information Engineering
___ SSADM
___ Yourdon (or SA/SD)
___ A Systems approach (SSM, ETHICS etc)
___ An Object-Oriented Method
___ Jackson Structured Design
or other (please specify)
6.4) if the answer to question 6.2 was 'yes'- Was the method used in its
entirety?
___ Yes?
___ No?
If not, what aspects of the method were not used, and why?
6.5) Which of the following tools or techniques were used on the project? (A
number of selections can be made)
___ Structure Charts
___ Data Flow Diagrams
___ Entity-Life Histories
___ Brainstorming
___ JAD Workshops
___ Prototyping Reviews
___ Entity-Relationship Models
___ Rich Pictures
___ Flow-Charts
___ Class diagrams
___ State Transition Diagrams
___ Storyboarding
or other (please specify)
7.1.1) New requirements or changing requirements were coming in at too fast a
rate for us to cope effectively
Not Applicable 1 2 3 4 5 Very Applicable
7.1.2) It would have been nice if we could get together with the user
representatives on a more regular basis, as it was, we were just getting too
little feedback
Not Applicable 1 2 3 4 5 Very Applicable
7.1.3) We had a number of difficulties in fitting the approach we took with the
quality assurance procedures that we had to follow
Not Applicable 1 2 3 4 5 Very Applicable
7.1.4) Turnover of staff (with connections to the project) was a major problem
and distrupted the project.
Not Applicable 1 2 3 4 5 Very Applicable
7.1.5) Too much attention was paid to user interface issues and not enough to
the underlying functionality of the system
Not Applicable 1 2 3 4 5 Very Applicable
7.1.6) Getting agreement on changes was a time-consuming process, even when the
change seemed to be very minor.
Not Applicable 1 2 3 4 5 Very Applicable
8: General Comments
Are there any other aspects of development practice that you feel are
particularly important and haven't been covered within this survey? Are there
any other points that you would like to make?
9: On completion of this survey would you like a summary of results?
___ Yes?
___ No?
Many thanks for taking the time to fill in this form!
David Fulton
Department of Computer Science
University College London