Brief Description - Revision history

Gousiosg: Revised edition

2009-07-16T11:55:26Z

Revised edition

← Older revision		Revision as of 13:55, 16 July 2009
Line 1:		Line 1:
	Our goal is to provide a tool that will enable other researchers and		Our goal is to provide a tool that will enable other researchers and practitioners to conduct Software Engineering research and practice in a far more innovative and efficient way. To do that, we want to make Open Source Software (OSS) computable.
	practitioners to conduct Software Engineering research and practice in
	a far more innovative and efficient way. To do what, we want to make
	Open Source Software (OSS) computable.

			Currently, there is a growing interest in software engineering research to use data originating from OSS projects. It could be argued that, apart from the software landscape, the OSS movement has also changed the way the study of software is being done. OSS projects make their Source Configuration Management (SCM), mailing lists and Bug Tracking Systems (BTS) publicly available. The wealth of combined process and product data has attracted the interest of many researchers, as this is the first time that large-scale empirical studies can be performed with real data outside the walls of large software organizations. However, even though they are free to use, OSS data come with a cost for researchers:
	There is a very large (and growing) amount of OSS on the web right
	now. This software can be used for all kinds of empirical analyses,
	quality assessments, testing of hypotheses on Software Engineering
	theories and methods. This potential is hampered by two factors:

	* Although OSS code is available, those wishing to analyse it have to download the code from the primary repository; then they typically have to write code that analyses it, for instance by computing some metrics on it; and then they have to run it.		* Although OSS code is available, those wishing to analyse it have to download the code from the primary repository; then they typically have to write code that analyses it, for instance by computing some metrics on it; and then they have to run it.

	* The above steps are usually repeated as often as somebody else wants to analyse the same piece of software. That is, a metric calculator for a certain OSS project is not usually available (or known) to other people wishing to do research on the same project. One may wonder how different wc implementations for different OSS projects have been written the last few years.		* The above steps are usually repeated as often as somebody else wants to analyse the same piece of software. That is, a metric calculator for a certain OSS project is not usually available (or known) to other people wishing to do research on the same project. One may wonder how different wc implementations for different OSS projects have been written the last few years.

	* During a lifetime spanning multiple decades, several OSS projects have amassed gigabytes of data worth studying. The computational cost for processing such large volumes of data is not trivial. For fast experiment turnover, researchers must design their analysis tools to exploit modern multiprocessor machines. However those efforts are often not enough, as the ~~capacities~~ of ~~single machines are~~ easily ~~saturated by~~ the ~~processed~~ ~~data~~ ~~volumes~~.		* During a lifetime spanning multiple decades, several OSS projects have amassed gigabytes of data worth studying. The computational cost for processing such large volumes of data is not trivial. For fast experiment turnover, researchers must design their analysis tools to exploit modern multiprocessor machines. However those efforts are often not enough, as the processed data volumes easily saturate the capacity of single machines.

	* Each project uses its own combination of SCM, mailing list, BTS and other project management tools, such as Wikis and documentation systems. Without the appropriate abstractions, it is challenging to build tools that can process data from various projects at the same time.		* Each project uses its own combination of SCM, mailing list, BTS and other project management tools, such as Wikis and documentation systems. Without the appropriate abstractions, it is challenging to build tools that can process data from various projects at the same time.

	* ~~Empirical studies~~ are often conducted in several phases, and a diverse set of tools can be applied in each phase. Intermediate results must be stored and retrieved efficiently in formats suitable for use by chains of tools.		* Studies are often conducted in several phases, and a diverse set of tools can be applied in each phase. Intermediate results must be stored and retrieved efficiently in formats suitable for use by chains of tools.

			Moreover, people developing metric measuring tools are often the same people who will use the metrics. This is not necessary.We propose to separate the two concerns: having the ability to ask questions on a piece of software is an enabler for research and innovation on Software Engineering. We also want to go one step further: asking questions should be so easy that researchers should be able to do it interactively in an exploratory manner.
	Moreover, people developing metric measuring tools are often the same
	people who will use the metrics. This is not necessary. We propose to
	separate the two concerns: having the ability to ask questions on a
	piece of software is an enabler for research and innovation on
	Software Engineering. We also want to go one step further: asking
	questions should be so easy that researchers should be able to do it
	interactively in an exploratory manner.

	WolframAlpha is an interesting example of what can be achieved by		WolframAlpha is an interesting example of what can be achieved by making information computable. In the same vein, we want to make Software Engineering knowledge, taken from OSS repositories, computable. Researchers should be able to ask questions like:
	making information executable. In the same vein, we want to make
	Software Engineering knowledge, taken from OSS repositories,
	executable. Researchers should be able to ask questions like:

	* What is the metric X for project P?		* What is the metric value X for state S of project P?

	* How does metric X for project P correlate with metric Y for project P?		* How does metric X for project P correlate with metric Y for project P?
Line 42:		Line 27:
	and so on.		and so on.

			To make such a tool meaningful, the set of metrics that could be calculated should be open-ended. In fact, the tool should be developed in such a way that interested researchers could easily create their own metrics and offer them to the tool, so that the set of metrics offered by the tool will be increasing with the number of people using and contributing to it. At the same time, the execution of contributed metrics should take into account security issues. Virtual machines and sandboxing should be employed to make them safe to execute.
	To make such a tool meaningful, the set of metrics that could be

	calculated should be open-ended. In fact, the tool should be developed
			===What we need from you===
	in such a way that interested researchers could easily create their
			The <PROJECTNAME> project is a research proposal being submitted for the first time. We plan to carry out the major parts of the write-up using our own resources, although help from partners will be greatly appreciated. We expect our partners to contribute their opinions in areas of their particular expertise and to formally review the proposal before it is being submitted.
	own metrics and offer them to the tool, so that the set of metrics

	offered by the tool will be increasing with the number of people using
			===Further information and communication===
	and contributing to it. At the same time, the execution of contributed
			This proposal is initiated by the Software Engineering and Security Group of the Department of Management Science and Technology of the Athens University of Economics and Business, directed by Diomidis Spinellis (http://www.dmst.aueb.gr/dds).
	metrics should take into account security issues. Virtual machines and

	sandboxing should be employed to make them safe to execute.
			Our web site: http://istlab.dmst.aueb.gr/content/groups/g_sense-details.html.
			Contact us by email at {gousiosg, louridas}@gmail.com

Gousiosg: Copyin() stuff from my phd thesis

2009-07-01T15:20:05Z

Copyin() stuff from my phd thesis

← Older revision		Revision as of 17:20, 1 July 2009
Line 12:		Line 12:

	* The above steps are usually repeated as often as somebody else wants to analyse the same piece of software. That is, a metric calculator for a certain OSS project is not usually available (or known) to other people wishing to do research on the same project. One may wonder how different wc implementations for different OSS projects have been written the last few years.		* The above steps are usually repeated as often as somebody else wants to analyse the same piece of software. That is, a metric calculator for a certain OSS project is not usually available (or known) to other people wishing to do research on the same project. One may wonder how different wc implementations for different OSS projects have been written the last few years.

			* During a lifetime spanning multiple decades, several OSS projects have amassed gigabytes of data worth studying. The computational cost for processing such large volumes of data is not trivial. For fast experiment turnover, researchers must design their analysis tools to exploit modern multiprocessor machines. However those efforts are often not enough, as the capacities of single machines are easily saturated by the processed data volumes.

			* Each project uses its own combination of SCM, mailing list, BTS and other project management tools, such as Wikis and documentation systems. Without the appropriate abstractions, it is challenging to build tools that can process data from various projects at the same time.

			* Empirical studies are often conducted in several phases, and a diverse set of tools can be applied in each phase. Intermediate results must be stored and retrieved efficiently in formats suitable for use by chains of tools.

	Moreover, people developing metric measuring tools are often the same		Moreover, people developing metric measuring tools are often the same

Louridas at 18:05, 25 June 2009

2009-06-25T18:05:46Z

← Older revision		Revision as of 20:05, 25 June 2009
Line 1:		Line 1:
			Our goal is to provide a tool that will enable other researchers and
	One page description to be written here.
			practitioners to conduct Software Engineering research and practice in
			a far more innovative and efficient way. To do what, we want to make
			Open Source Software (OSS) computable.

			There is a very large (and growing) amount of OSS on the web right
			now. This software can be used for all kinds of empirical analyses,
			quality assessments, testing of hypotheses on Software Engineering
			theories and methods. This potential is hampered by two factors:

			* Although OSS code is available, those wishing to analyse it have to download the code from the primary repository; then they typically have to write code that analyses it, for instance by computing some metrics on it; and then they have to run it.

			* The above steps are usually repeated as often as somebody else wants to analyse the same piece of software. That is, a metric calculator for a certain OSS project is not usually available (or known) to other people wishing to do research on the same project. One may wonder how different wc implementations for different OSS projects have been written the last few years.

			Moreover, people developing metric measuring tools are often the same
			people who will use the metrics. This is not necessary. We propose to
			separate the two concerns: having the ability to ask questions on a
			piece of software is an enabler for research and innovation on
			Software Engineering. We also want to go one step further: asking
			questions should be so easy that researchers should be able to do it
			interactively in an exploratory manner.

			WolframAlpha is an interesting example of what can be achieved by
			making information executable. In the same vein, we want to make
			Software Engineering knowledge, taken from OSS repositories,
			executable. Researchers should be able to ask questions like:

			* What is the metric X for project P?

			* How does metric X for project P correlate with metric Y for project P?

			* How does metric X for project P correlate with metric Y for project P?

			* Where does metric X in project P exceed value V?

			and so on.

			To make such a tool meaningful, the set of metrics that could be
			calculated should be open-ended. In fact, the tool should be developed
			in such a way that interested researchers could easily create their
			own metrics and offer them to the tool, so that the set of metrics
			offered by the tool will be increasing with the number of people using
			and contributing to it. At the same time, the execution of contributed
			metrics should take into account security issues. Virtual machines and
			sandboxing should be employed to make them safe to execute.

Louridas: New page: One page description to be written here.

2009-06-25T14:21:00Z

New page: One page description to be written here.

New page

One page description to be written here.