PRMS - Revision history

Suhridk: /* Evaluation */

2012-08-16T13:02:52Z

Evaluation

Suhridk: /* Evaluation */

2012-08-16T13:01:46Z

Evaluation

Suhridk: /* Review */

2012-07-16T17:03:17Z

Review

Suhridk: /* Review */

2012-07-16T17:00:39Z

Review

Suhridk: /* Review */

2012-07-16T16:58:50Z

Review

Suhridk: /* Review */

2012-07-16T16:28:03Z

Review

Suhridk: /* Review */

2012-07-16T16:27:26Z

Review

Suhridk: /* Review */

2012-07-16T16:26:43Z

Review

Suhridk at 16:18, 16 July 2012

2012-07-16T16:18:35Z

Suhridk: /* Review */

2012-07-16T16:15:48Z

Review

← Older revision		Revision as of 13:02, 16 August 2012
Line 49:		Line 49:

	* Evaluates the artefact, comparing results expected from the theory (including those for alternative designs) with those obtained in practice		* Evaluates the artefact, comparing results expected from the theory (including those for alternative designs) with those obtained in practice
−
−	* White box testing:
−	* Difficulty in performing white box testing.
−	* Sample EUnit cases.
−
−	* Black box testing for evaluating against user requirements.
−	* Test case with a description against each FR and NFR. Process of executing, screenshots etc.
−
−	* Live User Evaluation

	= Conclusion =		= Conclusion =

← Older revision		Revision as of 13:01, 16 August 2012
Line 49:		Line 49:

	* Evaluates the artefact, comparing results expected from the theory (including those for alternative designs) with those obtained in practice		* Evaluates the artefact, comparing results expected from the theory (including those for alternative designs) with those obtained in practice
		+
		+	* White box testing:
		+	* Difficulty in performing white box testing.
		+	* Sample EUnit cases.
		+
		+	* Black box testing for evaluating against user requirements.
		+	* Test case with a description against each FR and NFR. Process of executing, screenshots etc.
		+
		+	* Live User Evaluation

	= Conclusion =		= Conclusion =

@@ Line 37: / Line 37: @@
 * Often critique comes in the gaps between different papers.
 * Incosistencies between papers are interesting. Why are they interesting ?
 = Design =

@@ Line 33: / Line 33: @@
 * Summarize key points from previous papers - all the while '''building the argument.'''
 * What are the research papers trying to do, or what do they do for your argument, what is their nature/contribution ?
 = Design =

@@ Line 31: / Line 31: @@
 * It '''''provides the rationale''''' for what you do in your project
 ** Start from general considerations, build an argument which ends with your particular problem/topic.
 = Design =

@@ Line 29: / Line 29: @@
 * A critical analysis of a segment of a published body of knowledge through summary, classification and comparison of prior research studies …[and previous] reviews …
 * A lit review for a project is also focussed on '''providing the necessary background''' to your work, not a general survey of the area.
 = Design =

@@ Line 13: / Line 13: @@
 * Make a short oral presentation (assessed) that should accurately summarise their work and demonstrate the end product.
-== Contents of Report ==
+= Overall Report =
 * Rather than describing only a series of events and a final product, try to establish criteria, present arguments, derive principles, pose and answer questions, measure success, analyse alternatives and so on.
-=== Introduction ===
+= Introduction =
 * Defines the project area and its place within the subject.
 * The introduction proceeds from the wider concerns of Computer Science to the specific subject of the report by way of an orderly and natural progression of ideas.
-=== Review ===
+= Review =
 * Reviews the background to the project comprehensively, incorporates relevant issues succinctly, omits the irrelevant.
@@ Line 29: / Line 29: @@
 * A critical analysis of a segment of a published body of knowledge through summary, classification and comparison of prior research studies …[and previous] reviews …
-=== Design ===
+= Design =
 * From the review, explains the rationale behind the design of the work done, '''comparing all alternative designs and justifying the particular choices made.'''
@@ Line 35: / Line 35: @@
 * There is something distinctly ambitious about what has been attempted and the student has carried off the attempt with style, rarely defeated by problems encountered and more typically finding some clever solution.
-=== Evaluation ===
+= Evaluation =
 * Evaluates the artefact, comparing results expected from the theory (including those for alternative designs) with those obtained in practice
-=== Conclusion ===
+= Conclusion =
 * States clear conclusions from the work done, making accurate predictions of results that would be obtained by applying the present work in new areas.
@@ Line 48: / Line 48: @@
 * The limits include all material that is to be marked (including the title page, abstract, tables of contents, body of the report, and marked appendices).
 * Bibliographies and unmarked appendices that are included for completeness (such as program listings and tables of data), are not included.

@@ Line 27: / Line 27: @@
 * Uses the review to identify all the main issues, which are then analysed and developed.
 * The review is a penetrating analysis '''showing an impressive grasp of the subject''' and '''excellent judgement in the selection of previous work that should be applied in the project'''; it gives '''new insights into the project area''' not immediately identifiable from the literature.
 === Design ===