Investigating the use of Software Engineering in Computer Science Research

Computer Science and Software Engineering

Return to the investigation page

Questions considered for investigation

Below is the full list of questions considered in the planning stage of this research. Items marked S were considered suitable for a Survey, C were for a case study, O for other research (e.g. literature), and `?' was used to indicate information that it was thought might be hard or imposible to obtain.


Measure in	Metric

S, C	Size of research groups / software development teams

S	Methods of Software Engineering (by their own definition)
	used (open question)

S, C	Experience with Software Engineering methods used

S,C	Life of the project in years

S,C	Life of the project in people turnover

C	Size / Complexity of project (may need to come back to
	relevant people on this as it could be time consuming)
S	Papers published (to come out of research)

S O	Number of references to papers (that came out of research)

S, C	Number of complete re-writes of software

S, C	Number of modification / addition projects to the main
	research (eg summer vacation, honors, post grad projects)

S, C	Time spent in planning the project
	(cf other projects with out SE)

S, C	Time spent on development

S	Time spent in meetings
C	Maybe break down meeting types
	eg planning, general communication, tech review etc



Measure in	Metric (cont)

S	Number of students who continued on with research related
	to the project after finishing their initial involvement
	(eg honors students who went on to do further research)

C	What did they go on with ?

S	Personal satisfaction with project
	more / same / less then projects that didnt use SE
	OR on a scale of 1 to 10 , or possibly both)

C	Break down into what areas they think could have
	been improved

S	Personal frustration with project (as above)

C	What did they try to get around this?
	(eg add people, redesign, start over etc)

S	Do people that use SE feel it helps them ?

S	Looking back would they use more earlier on
	if they had to redo it ?

C	Go into depth

S	Do people who don't use SE feel they need it
	(or something else) to assist them?


Measure in	Metric (cont)

S, C	How many have some past experience of SE?
	Was at a positive or negative experience?
	Describe briefly why it was pos or neg

S	How many have tried it but no longer use any SE?
	(Can be calculated from above.)

S	How many use less then they have in the past? (why?)

S, C	If they stopped using some methods, which ones, and why?

S	Completion rate of Higher Degree by research of people
	involved in project (involved at any stage?
	eg possibly as undergrads?
	or only as part of the higher degree?)

S	Papers per Higher Degree by Research student

C	Operability (useability) (Ellyard and Glasl, 1995)


Measure in	Metric (cont)

C	Portability (modularity, machine independence,
	[ability to reuse - mine])

C	Reliability (consistency, simplicity, ...)
	(Ellyard and Glasl, 1995)

C	Safety (faults, environment...) (Ellyard and Glasl, 1995)

C	Maintainability (conciseness, modularity)
	(Ellyard and Glasl, 1995)
	NB This is the internals, portability might include
	the interface (I think).

S,C	Language(s) used (Ellyard and Glasl, 1995)

C	Load time (Ellyard and Glasl, 1995)

C	Execution time (Ellyard and Glasl, 1995)

C	Complexity of main processing module(s)
	(mine, related to execution time but in a
	more theoretical sense) also (Poels and Dedene, 2000)

C	Documentation (including standards followed)
	(Ellyard and Glasl, 1995)


Measure in	Metric (cont)

C	Processing capacity (Ellyard and Glasl, 1995)

C	Processing capacity growth potential (Ellyard and Glasl, 1995)

C	Security (da Silveira and Meira, 2000)
	(eg of confidential data in the system)

C	Scaleability (da Silveira and Meira, 2000)
	(Beuche, Schroder-Preikschat, Spinczyk and Spinczyk, 2000)

C	Reusability (da Silveira and Meira, 2000) (allows a component
	based approach)

S, C	Reuse, how many/much code was reused when
	building this project

C	* standard classes eg 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
	(eg from GNU)

	* Largely based on an existing framework

	* research was a plug in to another piece of software

	What was reused ?


Measure in	Metric (cont)

S, C	Resilience , Confers high level of fault tolerance
	based on replication feature (da Silveira and Meira, 2000)
	eg multiple levels of assertions and error trapping
	(even though one level should theoretically be enough)

C	Extensibility, extensions should require as little
	modification of existing source code as possible
	(Beuche et al., 2000)

C	Composability, easy to select the right configuration
	for a given set of requirements
	(Beuche et al., 2000)

C	Efficiency, so it runs on the required hardware
	(Beuche et al., 2000)
	and handles large enough data sets

C	Coupling, the more coupling the harder to maintain and the
	lower the possibility of use (Poels and Dedene, 2000)

C	Size measured in Event trigger operations,
	(Poels and Dedene, 2000)
	LOC per class, number of classes etc

C	Compatibility of design documents to programming language
	used (Seen et al., 2000) ie OOA&D and OOPL, using OOA&D for a non
	OO language or for a non OO design gives very low benefits.

C	Observability (Seen et al., 2000) this is meant in terms of design patterns,
	but applies equally well to software,
	particularly if it is intended to be reused.
	A transparent design is as important as a transparent paper.

S, C	Organisational slack (the amount of free resources the
	organisation has) (Seen et al., 2000)

	Were you able to get all the resources you asked for?
	eg programmers, machine time, hardware etc.


Measure in	Metric (cont)

	Interconnectedness, the level of interpersonal links in
	the organisation (Seen et al., 2000) possibly not as relevant
	for small projects, though research groups, past supervisor
	and student etc may be interesting

S	Organisation size, the large the organisation the more open
	to innovation it tends to be (Seen et al., 2000)

S	Centralisation, the fewer people with power the less innovative
	the organisation as a whole will be
	(Seen et al., 2000)

S	Formalisation, the level of rules and procedures. A high level
	of formalism means an innovation is less likely to be accepted,
	but more likely to be quickly and seamlessly introduced once
	accepted (Seen et al., 2000)

	Whose idea was it to use the SE practices used?
	Where did it come from and why did you go for it?
	Is any of it `required'?
C	Do you see advantages in the required elements?


Measure in	Metric (cont)

C	Decomposability (Liping Zhao Kendall, 2000)

C	Composability (Meyer, 1998)

S, C	Understandability (Meyer, 1998)

S, C	Continuity (Meyer, 1998)

C	Protection (Meyer, 1998)

C	Coupling between objects (CBO), Depth of inheritance
	tree (DIT) and lack of cohesion in methods (LCOM)
	(Poels and Dedene, 2000)

C (?)	Functionality (Poels and Dedene, 2000)

C (?)	Propagation measures (Poels and Dedene, 2000)

C (?)	Polymorphism measures (Poels and Dedene, 2000)

References above can be seen in the Bibliography.

Return to the investigation page