SoftwareEngineering - Revision history

GethinWilliams: Protected "SoftwareEngineering" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

2013-07-05T11:54:27Z

Protected "SoftwareEngineering" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

GethinWilliams: /* OK, but what's Involved? */

2013-06-28T09:26:52Z

OK, but what's Involved?

GethinWilliams: /* OK, but what's Involved? */

2013-06-28T09:21:53Z

OK, but what's Involved?

GethinWilliams: /* What's in it for Me? */

2013-06-28T09:21:41Z

What's in it for Me?

GethinWilliams: /* OK, but what's Involved? */

2013-06-28T09:21:23Z

OK, but what's Involved?

GethinWilliams: /* OK, but what's Involved? */

2013-06-28T09:20:43Z

OK, but what's Involved?

GethinWilliams: /* OK, but what's Involved? */

2013-06-28T09:19:59Z

OK, but what's Involved?

GethinWilliams: /* OK, but what's Involved? */

2013-06-27T14:47:48Z

OK, but what's Involved?

GethinWilliams at 14:31, 27 June 2013

2013-06-27T14:31:51Z

GethinWilliams: /* What's in it for Me? */

2013-06-27T14:19:59Z

What's in it for Me?

← Older revision		Revision as of 09:26, 28 June 2013
Line 21:		Line 21:

	The traditional [http://en.wikipedia.org/wiki/Waterfall_model waterfall model] of software development will espouse the steps of:		The traditional [http://en.wikipedia.org/wiki/Waterfall_model waterfall model] of software development will espouse the steps of:
		+
		+	[[Image:XP-feedback.gif\|250px\|thumbnail\|right\|Feedback loops in Extreme Programming (wikipedia)]]

	# Requirements capture & specification		# Requirements capture & specification

@@ Line 20: / Line 20: @@
 =OK, but what's Involved?=
-The traditional [http://en.wikipedia.org/wiki/Waterfall_model| waterfall model] of software development will espouse the steps of:
+The traditional [http://en.wikipedia.org/wiki/Waterfall_model waterfall model] of software development will espouse the steps of:
 # Requirements capture & specification

@@ Line 14: / Line 14: @@
 Why should you care about extensible and maintainable software?  why should invest time in creating robust and reliable code?  Well, for better or for worse, software tends to hang around.  Once a group of people have some software for doing a job which surpasses some modest level of usability for doing a job, it will tend to get re-used, regardless of whether there is a better or more efficient way of getting the same job done.  An even worse fate awaits software which fails the usability test.  It will be discarded, only to be re-invented in a myriad of time-wasting ways.
-* If you are a PhD student or postdoc, sooner or later you will be tempted to write a quick-and-dirty hack to get a job done '''right now'''.  However, unless that job is a one-off (and hindsight gleefully points out that they rarely are), the ad-hoc nature of that quick-and-dirty hack will soon become apparent.  However, since you invested the time already, you'll persist, trying to retrofit additional functionality.  As time goes on, however, the pain inexorably increases and you will end up wasting more and more time.  [http://en.wikipedia.org/wiki/Boiling_frog| The story goes] that a frog will jump out of boiling water, but will die if the heat is increased gradually.  All of this is an obstacle to progress.  What counts is the amount of research done in a three year period.  The argument is that if you adopt a software engineering approach from the outset, you will have more to show for your time come the end of your project.
+* If you are a PhD student or postdoc, sooner or later you will be tempted to write a quick-and-dirty hack to get a job done '''right now'''.  However, unless that job is a one-off (and hindsight gleefully points out that they rarely are), the ad-hoc nature of that quick-and-dirty hack will soon become apparent.  However, since you invested the time already, you'll persist, trying to retrofit additional functionality.  As time goes on, however, the pain inexorably increases and you will end up wasting more and more time.  [http://en.wikipedia.org/wiki/Boiling_frog The story goes] that a frog will jump out of boiling water, but will die if the heat is increased gradually.  All of this is an obstacle to progress.  What counts is the amount of research done in a three year period.  The argument is that if you adopt a software engineering approach from the outset, you will have more to show for your time come the end of your project.
 * If you are a PI, you will be rewarded for adopting a longer-term perspective.  You will get more bang for your buck if the tools developed for your research enterprise can be used by more than one student or postdoc and you don't end up re-inventing the wheel during each successive funding round.

@@ Line 32: / Line 32: @@
 While many would agree with the actions involved, many would take issue with the static and prescriptive nature of the above approach.  I would argue that these objections accrue additional weight in the academic setting.
-As a counterpoint, more '''agile''' and '''dyanamic''' approaches have been advocated.  These emphasise the virtues of [http://en.wikipedia.org/wiki/User-centered_design | user-centric design], [http://en.wikipedia.org/wiki/Co-design | co-design] and [http://en.wikipedia.org/wiki/Rapid_application_development | rapid prototyping].  [http://en.wikipedia.org/wiki/Extreme_programming | Extreme programming] is one such approach.
+As a counterpoint, more '''agile''' and '''dyanamic''' approaches have been advocated.  These emphasise the virtues of [http://en.wikipedia.org/wiki/User-centered_design user-centric design], [http://en.wikipedia.org/wiki/Co-design co-design] and [http://en.wikipedia.org/wiki/Rapid_application_development rapid prototyping].  [http://en.wikipedia.org/wiki/Extreme_programming Extreme programming] is one such approach.
 The subjects covered by the tutorials in this course all have a place in a software engineer's toolbox.  They will draw your attention to:

@@ Line 32: / Line 32: @@
 While many would agree with the actions involved, many would take issue with the static and prescriptive nature of the above approach.  I would argue that these objections accrue additional weight in the academic setting.
-As a counterpoint, more '''agile''' and '''dyanamic''' approaches have been advocated.  These emphasise the virtues of [http://en.wikipedia.org/wiki/User-centered_design| user-centric design], [http://en.wikipedia.org/wiki/Co-design| co-design] and [http://en.wikipedia.org/wiki/Rapid_application_development| rapid prototyping].  [http://en.wikipedia.org/wiki/Extreme_programming| Extreme programming] is one such approach.
+As a counterpoint, more '''agile''' and '''dyanamic''' approaches have been advocated.  These emphasise the virtues of [http://en.wikipedia.org/wiki/User-centered_design | user-centric design], [http://en.wikipedia.org/wiki/Co-design | co-design] and [http://en.wikipedia.org/wiki/Rapid_application_development | rapid prototyping].  [http://en.wikipedia.org/wiki/Extreme_programming | Extreme programming] is one such approach.
 The subjects covered by the tutorials in this course all have a place in a software engineer's toolbox.  They will draw your attention to:

← Older revision	Revision as of 11:54, 5 July 2013
(No difference)

← Older revision		Revision as of 09:19, 28 June 2013
Line 40:		Line 40:
	* '''Productivity boosting tools'''. These will help speed you to your goal. To err is human and we will all need to find and correct software bugs from time to time. A modicum of knowledge of compilers, debuggers, profilers and documentation tools will repay the time invested in learning them many times over.		* '''Productivity boosting tools'''. These will help speed you to your goal. To err is human and we will all need to find and correct software bugs from time to time. A modicum of knowledge of compilers, debuggers, profilers and documentation tools will repay the time invested in learning them many times over.
	* '''Reproducibility'''. A key tenet of science is that experiments are reproducible. If your experiments involve computers, the task of reproduction is very hard indeed without the aid of a version control system.		* '''Reproducibility'''. A key tenet of science is that experiments are reproducible. If your experiments involve computers, the task of reproduction is very hard indeed without the aid of a version control system.
		+	* '''Testing'''. You wouldn't just switch on a piece of lab equipment and assume that it is working correctly--you'd need to calibrate it first. Likewise, just because a program runs does not mean that it will produce correct results. Tests are an essential part of the code development process, particularly so for science. The more agile development approaches encourage very regular tests. Indeed some methodologies advocate writing the tests before the code itself--the tests form a specification for what the code should do.

← Older revision		Revision as of 14:47, 27 June 2013
Line 33:		Line 33:

	As a counterpoint, more '''agile''' and '''dyanamic''' approaches have been advocated. These emphasise the virtues of [http://en.wikipedia.org/wiki/User-centered_design\| user-centric design], [http://en.wikipedia.org/wiki/Co-design\| co-design] and [http://en.wikipedia.org/wiki/Rapid_application_development\| rapid prototyping]. [http://en.wikipedia.org/wiki/Extreme_programming\| Extreme programming] is one such approach.		As a counterpoint, more '''agile''' and '''dyanamic''' approaches have been advocated. These emphasise the virtues of [http://en.wikipedia.org/wiki/User-centered_design\| user-centric design], [http://en.wikipedia.org/wiki/Co-design\| co-design] and [http://en.wikipedia.org/wiki/Rapid_application_development\| rapid prototyping]. [http://en.wikipedia.org/wiki/Extreme_programming\| Extreme programming] is one such approach.
		+
		+	The subjects covered by the tutorials in this course all have a place in a software engineer's toolbox. They will draw your attention to:
		+
		+	* '''Software re-use'''. A wise developer will look to what others have done before and will strive to create code which can be re-used when, all too commonly, a related task raises it's head.
		+	* '''Code design'''. Software developed with some forethought will often provide elegant solutions for more than just the immediate task at hand. It is also likely to be more robust and efficient than code which was quickly thrown together with just one job in mind.
		+	* '''Productivity boosting tools'''. These will help speed you to your goal. To err is human and we will all need to find and correct software bugs from time to time. A modicum of knowledge of compilers, debuggers, profilers and documentation tools will repay the time invested in learning them many times over.
		+	* '''Reproducibility'''. A key tenet of science is that experiments are reproducible. If your experiments involve computers, the task of reproduction is very hard indeed without the aid of a version control system.

← Older revision		Revision as of 14:31, 27 June 2013
Line 18:		Line 18:
	* If you are a PI, you will be rewarded for adopting a longer-term perspective. You will get more bang for your buck if the tools developed for your research enterprise can be used by more than one student or postdoc and you don't end up re-inventing the wheel during each successive funding round.		* If you are a PI, you will be rewarded for adopting a longer-term perspective. You will get more bang for your buck if the tools developed for your research enterprise can be used by more than one student or postdoc and you don't end up re-inventing the wheel during each successive funding round.

−	=~~Summary~~=	+	=OK, but what's Involved?=
		+
		+	The traditional [http://en.wikipedia.org/wiki/Waterfall_model\| waterfall model] of software development will espouse the steps of:
		+
		+	# Requirements capture & specification
		+	# Design
		+	# Implementation
		+	# Integration
		+	# Testing & debugging
		+	# Installation
		+	# Maintenance
		+
		+	While many would agree with the actions involved, many would take issue with the static and prescriptive nature of the above approach. I would argue that these objections accrue additional weight in the academic setting.
		+
		+	As a counterpoint, more '''agile''' and '''dyanamic''' approaches have been advocated. These emphasise the virtues of [http://en.wikipedia.org/wiki/User-centered_design\| user-centric design], [http://en.wikipedia.org/wiki/Co-design\| co-design] and [http://en.wikipedia.org/wiki/Rapid_application_development\| rapid prototyping]. [http://en.wikipedia.org/wiki/Extreme_programming\| Extreme programming] is one such approach.

← Older revision		Revision as of 14:19, 27 June 2013
Line 11:		Line 11:

	=What's in it for Me?=		=What's in it for Me?=
		+
		+	Why should you care about extensible and maintainable software? why should invest time in creating robust and reliable code? Well, for better or for worse, software tends to hang around. Once a group of people have some software for doing a job which surpasses some modest level of usability for doing a job, it will tend to get re-used, regardless of whether there is a better or more efficient way of getting the same job done. An even worse fate awaits software which fails the usability test. It will be discarded, only to be re-invented in a myriad of time-wasting ways.
		+
		+	* If you are a PhD student or postdoc, sooner or later you will be tempted to write a quick-and-dirty hack to get a job done '''right now'''. However, unless that job is a one-off (and hindsight gleefully points out that they rarely are), the ad-hoc nature of that quick-and-dirty hack will soon become apparent. However, since you invested the time already, you'll persist, trying to retrofit additional functionality. As time goes on, however, the pain inexorably increases and you will end up wasting more and more time. [http://en.wikipedia.org/wiki/Boiling_frog\| The story goes] that a frog will jump out of boiling water, but will die if the heat is increased gradually. All of this is an obstacle to progress. What counts is the amount of research done in a three year period. The argument is that if you adopt a software engineering approach from the outset, you will have more to show for your time come the end of your project.
		+
		+	* If you are a PI, you will be rewarded for adopting a longer-term perspective. You will get more bang for your buck if the tools developed for your research enterprise can be used by more than one student or postdoc and you don't end up re-inventing the wheel during each successive funding round.

	=Summary=		=Summary=