The USE CSR Project is looking at the approach people take to Computer Science Research (in a university setting) and whether altering this approach can result in tangible benefits. Computer science research of interest to this project is any research taking place in a computer science (or similar) department that involves the production of code to test, prove, apply or try out a theory / algorithm / concept or other research idea. In short, any research involving the production of software of any type (e.g. proof-of-concept software right through to commercial or open source public release software).

Aims of the use CSR project (and who should complete this survey)

Ethics

Ethics approval has been granted for this survey by the Human Ethics Committee of Monash University. Further information about the research, how you can make complaints to the committee if there is anything you don't like about this survey and how you can contact the researcher and supervisors is provided at the end of this page (below the survey).

Time to Complete

This Questionnaire should take under 15 minutes to complete for a single project, There is an option to complete one part of the survey (that part relating to a project) more than once, this will take a little longer but would be very useful for the research.

Your time on this survey is greatly appreciated, and we hope the outcomes will be of interest and use to all to us.

Questionnaire

You are strongly encouraged to complete questions preceded by a "*".

* Country where most of your education has taken place: * Country where most of your research has taken place: * My position can best be described as: Academic LecturerAcademic ResearcherPost Doctoral ResearcherPhD StudentIndustry ResearcherGovernment ResearcherHonours StudentOther   If you answered other to the question above, please elaborate: * The field I trained in can best described as: Computer ScienceSoftware EngineeringEngineeringSystems AnalystMathematicsScience (other than Computer Science)Programming / ComputingOther   If you answered other to the question above, please elaborate: * I work at (name of: University or Company or Organisation): * I am affiliated with the following department(s) / fields: * I have been involved in the software development / software research area professionally for: less than 5 years5 to less than 10 years10 to less than 15 years15 to less than 20 yearsover 20not professionally * Have you taught a Software Engineering Subject Yes No * Have you studied software engineering either as part of a degree or on your own (e.g. through books or papers) ? Yes No * Have you used graphical models to design programs ? Yes No * Which of the following tools / methodologies do you know and / or use? Functional Specifications Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Flow Charts Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Data Flow Diagrams Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Entity Relationship Diagrams Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Class / Package Diagrams Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Interaction Diagrams Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always State Diagrams Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always State Transition Diagrams Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Booch Notation Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Use Cases Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Use Case Diagrams Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Unified Modeling Language Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Specification Language Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Waterfall SDLC Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Fountain SDLC Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Spiral SDLC Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Rapid Application Development Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Technical Reviews Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Black Box testing Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always White Box Testing Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Unit Testing Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Integration Testing Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always JavaDoc Commenting Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Systematic Internal Comments Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Meaningfully named variables Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Rational Rose Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Structured A&D Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Design Walk through Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Code Reviews Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Requirements Reviews Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Prototyping Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Formal Methods Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always MS Project Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Compiler Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always Debugger Don't know thisKnow but don't useUse rarelyUse sometimesUse oftenUse always   1) Other SE tool you know:   2) Other SE tool you know:   3) Other SE tool you know:   1) Other SE tool you use:   2) Other SE tool you use:   3) Other SE tool you use: * Why do you use the methods you use ? Saves time in the long run Helps me clarify my ideas Makes communicating easier across the team Makes communication easier between projects Assists with producing better quality software   Other reasons for using these techniques / methods / tools * Why don't you use (more often) the methods you described as "know but don't use" or "use rarely" in the question above? Never thought about it Don't know about them Cost of learning them is too high They are not appropriate for my work Cost of using them is higher than the pay off Organisational Policy against spending time on them Other   Other reasons for not using other techniques / methods / tools * Have your usage patterns changed over time ? Used to use none now use a lot Used to use none, now use a little Used to use some now use more No change Used to use a little but stopped or decreased my use Used to use a lot now use a little Used to use a lot now use none * I expect to use Less in the future The same amount in the future More in the future   Comment: The following questions are project related. Your answers here may need to differ from your answers in the above questions. Please choose 1 project you have been involved with and answers your questions in relation to this project. After submitting this form you will be given the options of ending the survey or entering another project. If you intend entering more than one project it would be useful for comparison if one of these had significantly better outcomes than the other(s) * Project's Name * Institution / Company where it was carried out * The year the project was started   The year the project was completed (or is scheduled to be completed). * The department in the organisation you were working in had: Under 30 people in it Under 50 people people in it Under 100 people people in it Under 200 people people in it 200 or more people in it * Project management was controlled by: Individual team members setting their own schedules or delivering goods when they completed them The project group by consensus The project leader with little input from organisational management The project leader with some input from organisational management Organisational management * The organisation had: No formal policy for approach to projects A limited amount of formalism e.g. project applications, interim reports, final reports A large amount of formalism e.g. specification of design languages and programming languages to be used and types of documentation to be created (e.g. design, testing, user manuals etc) * Which best describes the project's approach to Analysis and Design: Analysis & Design was done before coding was started Analysis & Design was done while coding Analysis of the problem took place after the project was completed Analysis & Design was not explicitly done Analysis prior to coding, design not possible (due to the projects nature) (please explain why this was so below) * Given more time and / or money, would you go back and create / update design documents after coding Yes No   If you indicated `design not possible' above, please explain why * Which best describes the projects approach to documentation: Detailed and useful documentation was started before coding (e.g. Analysis and / or Design documents) and kept Some useful documentation was started before coding (e.g. a useful project proposal) and kept Some useful external documentation was created during coding and kept (design documents, Javadoc, etc) The only documentation on the project code is by way of papers relating to the project (and a users manual / inbuilt help). * The projects development was modeled on a software development life cycle model: Waterfall Fountain Spiral RAD The development was according to some other explicit model The development was not planned or systematic * How many different people worked on the project at one point or another (in total) * At its peak, how big was the project team * Roughly how much funding did the project receive (in total) * Number of complete re-writes of software * Time spent in planning the project (in months): * Time spent on development (In months): * Meeting Frequency: Monthly Fortnightly Weekly Daily * Meeting duration on average: 30 minutes 1 hour 2 hours Half day All day * Reuse, how many/much code was reused when building this project standard classes e.g. template libraries, Java standard library some code of a previous version of the software Some small components that developers already had Some small components that developers found (e.g. from GNU) Largely based on an existing framework Research was a plug in to another piece of software * Were you able to get all the resources you asked for ? e.g. programmers, machine time, hardware etc Yes No * Personal satisfaction with project outcomes Much less then other projects Less than other projects about the same More than other projects Much more than other projects * Personal frustration with project process Much less then other projects Less than other projects about the same More than other projects Much more than other projects * Looking back would you use more things (e.g. analysis, design, documentation, reviews, testing etc) earlier on if you had to redo the project ? Yes No * Papers published as a result of this project: * Number of modification / addition projects to the main research (e.g. summer vacation, honors, post grad projects) * Number of students who continued on with research related to the project after finishing their initial involvement (e.g. honors students who went on to do further research) * Number of Students involved in project as part of a higher degree by research * Average papers published per Higher Degree by Research student relating to the project and their work on it * Is there a user group for the software produced Yes No * What grants were attracted * What is/was the value of these grants ($AUS) * How do you rate the success of the project ?   I would like further communication with this survey: Contact when the results are collated only (a link to summarised results will be provided) Contact me if needed to clarify my answers or if a followup survey is conducted, as well as notifying me when results are collated Do not contact me again regarding this survey   Comment: The following question are to enable further communication in relation to this research. If you wish to remain anonymous, feel free not to answer them.   Email Address   Name: This is used only in communication to you by e-mail

Please report any problems with this questionnaire to the researcher: Andre.Oboler@csse.monash.edu.au.

I am currently engaged in research that aims to assess how computer science research is conducted in a university setting. My name is Andre Oboler , and I am trying to discover if there is a role for Software Engineering methods, or something similar, in academic computer science research, and if this could provide the sorts of improvements that software engineering has been aiming for in industry since its conception in the 1960s.

I am working under the supervision of Dr. David Squire and Dr. Kevin Korb in the School of Computer Science and Software Engineering towards a Bachelor of Computer Science (Honours) at Monash University.

I am looking for people involved in computer science research projects (primarily in a university environment, but other environments would be useful too for comparison) who are willing to fill out a questionnaire which asks about their knowledge of, use of, and attitudes towards various software engineering techniques.

The questionnaire is available on the World Wide Web. It will take about 15 minutes to complete. Since the questionnaire is on-line, it is not possible for us to identify who has filled it out, although it does provide fields for an email address and Name, should the subject wish to be contacted regarding the results or follow-up studies. I stress that the completion of these fields is voluntary: the mode of survey ensures that it is anonymous unless the subject chooses otherwise.

No findings which could identify any individual participant will be published. Only my supervisors and I will have access to the raw survey data, which will be stored for at least five years as prescribed by the university regulations.

Subjects who agree to participate may withdraw their consent at any time. They may do this by simply not completing the questionnaire, or by notifying me by phone or in writing. Subjects can also submit questionnaires with some questions left unanswered.

If you have any queries or would like to be informed of the aggregate research finding, please contact Dr. David Squire by telephone on +61 3 9903 1033, or fax at +61 3 9903 1077.

Thank you.

Andre Oboler
Phone: +61 3 9903 1033
Email: mailto:andre.oboler@infotech.monash.edu.au