From: David Fulton
Subject: System Development Survey
Date: 
Message-ID: <1996Mar4.181517.97389@ucl.ac.uk>
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