Newsgroups: comp.lang.ada,comp.lang.apl,comp.lang.x86,comp.lang.asm370,comp.lang.awk,comp.lang.basic.misc,comp.lang.basic.visual.3rdparty,comp.lang.basic.visual.database,comp.lang.basic.visual.misc,comp.lang.beta,comp.lang.c,comp.lang.c++ Path: news.daimi.aau.dk!news.uni-c.dk!newsfeed.sunet.se!news00.sunet.se!sunic!mn6.swip.net!plug.news.pipex.net!pipex!tube.news.pipex.net!pipex!lade.news.pipex.net!pipex!tank.news.pipex.net!pipex!peer-news.britain.eu.net!bcc.ac.uk!news From: David Fulton Subject: System Development Survey Message-ID: <1996Mar4.160600.30001@ucl.ac.uk> Date: Mon, 4 Mar 1996 16:06:00 GMT X-Url: news:comp.lang.ada Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 X-Mailer: Mozilla 1.1N (X11; I; SunOS 4.1.3_U1 sun4c) Organization: University College London Lines: 500 Xref: news.daimi.aau.dk comp.lang.ada:48715 comp.lang.apl:17629 comp.lang.asm370:13234 comp.lang.awk:1248 comp.lang.basic.misc:23446 comp.lang.basic.visual.3rdparty:20249 comp.lang.basic.visual.database:24937 comp.lang.basic.visual.misc:69950 comp.lang.beta:10652 comp.lang.c:170780 comp.lang.c++:171503 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: dfulton@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) 6.6) Which tools or techniques do you feel are particularly important (given the project you were working on), and why? 6.7) In your opinion, what are the tool or technique characteristics (for analysis and design) that you feel are particularly important? (for the project you were working on) 6.7.1) Tools/techniques that help us to experiment, attempt different interpretations in order to improve understanding of the design problem or make choices with design alternatives Not Important 1 2 3 4 5 Very Important 6.7.2) Tools/techniques that help to illustrate the underlying models of the system, illustrating system behaviour, structure etc. Not Important 1 2 3 4 5 Very Important 6.7.3) Tools/techniques that give us a concrete idea of the way in which a system can be realised and give a visible impression of what the system will look like Not Important 1 2 3 4 5 Very Important 6.7.4) Tools/techniques that help in communicating important analysis or design information between the designers, or between designers and other participants Not Important 1 2 3 4 5 Very Important 6.7.5) Tools/techniques that help us to explore analysis and design issues, to explore issues of complexity and aid the understanding of complex organisational and technological problems Not Important 1 2 3 4 5 Very Important 7: Problems 7.1) In any given situation, there will be a number of constraints that can hinder the strategy chosen for system development. How applicable were the following situations to your project? 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