Lecture 5: Writing the Project Documentation Part III.

16
Lecture 5: Writing the Project Documentation Part III

Transcript of Lecture 5: Writing the Project Documentation Part III.

Page 1: Lecture 5: Writing the Project Documentation Part III.

Lecture 5: Writing the Project Documentation Part III

Page 2: Lecture 5: Writing the Project Documentation Part III.

Data PresentationTypes of data you may need to present:

Surveys and Questionnaires Software test results Algorithm speed trials Analysis and Design tools

Page 3: Lecture 5: Writing the Project Documentation Part III.

Data PresentationDescribing such data using text and paragraphs,

makes your report ‘dry’ and not easy to interpret

While using pictures, charts, diagrams and other types of graphics, will give the report more attractive look.

“Picture worth a thousand word” but, if it is not a correct picture, it won’t worth any, and on the contrary it may damage your report, so be aware.

Page 4: Lecture 5: Writing the Project Documentation Part III.

Data Presentation – Charts and GraphsAll figures and tables included in your report

should be labeled with a number and a short description

The most common method is to label each figure and table using serial numbers prefixed by the current chapter number

For example: “Figure 1.4” refers to figure number 4 in chapter 1

Page 5: Lecture 5: Writing the Project Documentation Part III.

Data Presentation – Charts and GraphsYou can label a table and a figure with the

same number, as long as each one is prefixed with either “Figure” or “Table”

Example: “Figure 2.8” and “Table 2.8”

Be consistent, don’t change the way you present a table or a figure from one chapter to another

Page 6: Lecture 5: Writing the Project Documentation Part III.

Data Presentation – Charts and GraphsQuestions to ask about included diagrams:Both diagrams and tables:

‘Does it have a brief but clear and descriptive title?’

‘Are the units of measurement clearly stated?’‘Are the sources of data used clearly stated?’‘Are there notes to explain any abbreviations?’‘Have you stated the sample size?’

Page 7: Lecture 5: Writing the Project Documentation Part III.

Data Presentation – Charts and GraphsQuestions to ask about included diagrams:Diagrams:

‘Does it have clear axes labels?’‘Are bars and their components in the same

logical sequence?’‘Is more dense shading used for smaller

areas?’‘Is a key or legend included (where

necessary)?’

Page 8: Lecture 5: Writing the Project Documentation Part III.

Data Presentation – Charts and GraphsQuestions to ask about included diagrams:Tables:

‘Does it have clear column and row headings?’‘Are columns and rows in a logical sequence?’

Page 9: Lecture 5: Writing the Project Documentation Part III.

Data Presentations – Common MistakesNever include figures or tables just to show

off, they should support certain arguments you make within the text and/or to clarify, in diagrammatical way, the data represented in the report. (Unnecessary inclusion of graphics)

Using wrong type of charts to represent data.

Wrong usage and scaling of charts

Page 10: Lecture 5: Writing the Project Documentation Part III.

Other Data PresentationsYou may need to present your data in other types of data

presentations, such as Program listing, designs, photographs, ..etc. The following tips might need you in this presentation: Try to keep figures and listing in one page. If code listings

spread over several pages then you should consider moving the listing to an appendix and include any short extracts (of interesting algorithms) in the main body of your report

Consider alternative ways of presenting diagrams. For example, rather than including several figures showing the evolution of a system’s interface design, you could include a photograph showing the preliminary sketches of your design.

Present pseudo code and designs in boxes rather than ‘floating’ among the text.

Page 11: Lecture 5: Writing the Project Documentation Part III.

Writing AbstractsThe function of Abstract: Summarize

briefly the nature of:Your research projectIts contextHow it was carried outand what its major findings were

Page 12: Lecture 5: Writing the Project Documentation Part III.

Writing AbstractsWhy it is important?

The abstract provides the reader with an overview of your project and is the basis on which many readers will decide whether or not to read your report at all.

Page 13: Lecture 5: Writing the Project Documentation Part III.

Writing AbstractsRecommendation:

Your abstract should be concise (preferably no more than one half page long), clear and interesting.

Your report’s abstract should be one of the last things you write, when you actually know what you have achieved and what the content of your report is.

Avoid using references in your abstract as the reader will not necessarily wish to search through your report to find them or be familiar with the author(s) you have cited.

Page 14: Lecture 5: Writing the Project Documentation Part III.

Writing AbstractsAbstract Components:

Context: introduces the topic area in which your project resides; it can include coverage of related topics and issues, and generally sets the scene for the reader so they can comprehend your project’s subject area.

Gap: What is the missing in the real environment or in the previous research that you want to fix

Contribution: what does your report contain that fills the gap you have identified or what your report contains in relation to the context you have discussed

Page 15: Lecture 5: Writing the Project Documentation Part III.

Writing Abstracts – Example 1Abstract

With the increasing interactions among companies, their suppliers and customers, the need for management of the flow of products, material and information is increasing, which created the concept of the Supply Chain Management. SCM is an old concept implemented to create integration between these entities for many years ago, but with the emergent of e-business and the widespread of internet technologies, the activities and processes of SCM have been enhanced. This paper gives short description of the concept of SCM, with its two models, Upstream and Downstream. Two case studies are discussed within these concepts. And finally, the impact of e-business evolution on the processes of both models of SCM is discussed.

Context Gap Contribution

Page 16: Lecture 5: Writing the Project Documentation Part III.

Writing Abstracts – Example 2Abstract

The main concerns for organizations managements include hiring highly qualified personnel and retaining highly performed employees. Data mining is a young and promising field of information and knowledge discovery. In this research, Data mining is used to build a model to predict the potential turnover of employees. To build the model, the CRISP-DM methodology was adopted to build a classification model to predict the possibility of turnover. Decision tree method was mainly chosen for this task where several classification rules were generated. To evaluate the model, data were collected from different IT companies and three experiments were conducted. The experiments showed that several factors affect the potential of turnover. The experiments provided fair accuracy in some cases showing that several factors affect the potential of turnover. As a final conclusion we recommend to enhance and use the model in the hiring process of employees and to keep those who think to leave the organization.

Context Gap Contribution