Project Deliverables

Overview of Project Deliverables

1. Project Quarter 1: Technical Paper Draft 1
   • Draft 1 must be in the proper paper format.
   • It must include an appropriate title, an abstract, an introduction, project requirements, and literature review citing appropriate references.
   • Note: Having an early delivery of project material is not new. Professor Frederick P. Brooks, University of North Carolina, has long advocated this approach, see for example Keynote Address, EDSIG 2015 where he recommends an early delivery of the complete project followed by strong criticism and a "do it over!", as well as the delivery of a programming manual after one month. Roger Pressman in his 2014 book Software Engineering: A Practitioner's Approach also advocates early delivery.
2. Project Quarter 2: Technical Paper Draft 2 and Midterm Project PowerPoint Presentation
   • Draft 2 must include a list of key terms, essentially finalized literature review, a methodology, and preliminary findings/results.
   • If a system is being developed, the system should be essentially complete (80-20 rule).
   • If experiments are being performed, preliminary results should be presented and discussed.
   • The PowerPoint presentation should summarize the content of the paper.
3. Project Quarter 3: Technical Paper Draft 3
   • Draft 3 must contain all sections and be essentially complete except for final updates.
   • If a system is being developed, the system should be essentially complete except for final updates.
   • If experiments are being performed, essentially completed results should be presented and discussed.
4. Project Quarter 4: Final Technical Paper and Final Project PowerPoint Presentation
   • The final technical paper must be in final form for the conference proceedings.
   • The PowerPoint presentation should summarize the content of the paper.
5. Project System User Manual - required if a system was developed and the technical paper did not contain full instructions

Technical Paper for Publication in the Proceedings of Seidenberg's Research Day Conference

• Typical sections include:
  • Introduction (some material can come from the course website project description)
  • Briefly introduce and describe the current study (the major problem or issue being investigated)
  • Literature review - describe similar work and cite the references
  • Discuss relevance of this work in the context of previous related work
  • Build a case for the usefulness of the current study
  • Show how the current investigation will advance understanding and explain why this matters
  • Methodology (e.g., condense material from the system design or user manual)
  • Results - usefulness, etc. (document any results, describe utility of system, etc.)
  • Conclusions, Implications, Recommendations for future work, and Summary (make projections)
• The paper must be double-column in IEEE format and limited to 8 pages. Just use the IEEE format template and cut and paste pieces of your document into the template. The main IEEE requirements are:
  • Type-style and Fonts. Times or Times Roman font.
  • The Main Title should be centered in Times 24-point, non-boldface type. Initially capitalize nouns, pronouns, verbs, adjectives, and adverbs; do not capitalize articles, coordinate conjunctions, or prepositions (unless the title begins with such a word).
  • Author's Name(s) and Affiliation(s) are to be centered beneath the title and printed in Times 11-point, non-boldface type.
  • The Abstract is to be in fully-justified Times 9-point, boldface, single-spaced type, and limited to 250 words.
  • Main Text. Type main text in 10-point Times, single-spaced. Do NOT use double-spacing.
  • References. Number and list the references alphabetically by the last name of the first author (this differs from some IEEE publications that require references listed in the order cited). Use 8-point Times, single-spaced, at the end of your paper. When citing references in the text, enclose the citation number in square brackets, for example [1].
• Guidelines
  • The number of pages is limited to 8, including appendices. Only a page or at most two pages should be devoted to the introduction and backbround material.
  • The abstract should summarize the paper, emphasizing the important aspects, such as the results and conclusions, and should be the last section reviewed and finalized after completing the paper.
  • The paper should be clearly written and flow smoothly. All team members should read the paper carefully to find and correct all errors of technical content and of writing (organization, spelling, grammar, clarity, etc.). In particular, the style of writing should be consistent and it should not read like different portions of the paper were written by different team members.
  • Grammar and word usage
    • Minimize the use of the words "very", "most", and other flowery and exaggerating adjectives.
    • Avoid the term "project" in the paper, instead use other terms - for example, "The study (or work or effort) focused on ..." (This item is specific for the Technical Paper in this course.)
    • In technical writing, for lists of items separated by commas, do not omit the comma before the last item as is often done in non-technical writing. For example, we have the following items: one, two, three, and four.
    • Other grammar and word usage recommendations can be found in The Elements of Style by Strunk and White (see Internet summary).
  • Figures and tables
    • Each figure and table must be numbered, described in a caption, centered in the column, and cited in the text. Figure and table citings and captions can easily be checked by searching on "fig" or "table".
  • References and citings
    • All references must be alphabetized by the first author's last name using the format:
      [1] A.B. Bones and C. Roberts, "Article Title", Journal, Publisher, Date, pp. 1-10.
      [2] D.G. Carson, Book Title, Publisher, Date.
      Alphabetize a URL either by the author or site name - for example, Google, http://www.google.com/ is alphabetized under "G". A URL reference must include the date last accessed - for example,
      [3] Google, http://www.google.com/, accessed November 2008 (month and year are sufficient).
    • Each reference must be cited in the text.
    • Avoid putting URLs in the text: when citing an online document, put the URL into a reference and cite it in the text by number in the usual manner.
    • When material (sentences, phrases, etc.) is taken verbatim from a reference, the material must be placed in quotes and the reference cited. Copying material without quotes and a reference is plagiarism. If the material is paraphrased, it is sufficient to cite the reference.
    • When citing a reference at the end of a sentence, the citing should precede the sentence-ending period, such as [1].
  • All statements that are not obvious must be supported by references or by supporting arguments. For example, a statement like, "Keystroke biometric systems measure typing characteristics believed to be unique to an individual and difficult to duplicate." must be supported (who says this is true, etc.).
  • Instructor's editings of sections of the paper are done using the "Track Changes" tool in Microsoft Word and the changes are easily accepted by clicking on "Accept All Changes in Document." The editing is intended to fix a few things and to give you an indication of how to edit, and should not to be interpreted as fixing everything in the paper.

Users Manual

• This is a standard manual instructing users how to use the system
• If any systems or subsystems need installation, the manual must have a section on "System Installation" that specifies the environment and installation procedures necessary to install the system. For example, given the client-server architecture of many of your project systems, this entails specifying the required server hardware and software, ditto for a client machine, the files that must be uploaded to the server (include a disk containing the files), and any installation procedures that must be followed. In other words, a client given this information should be able to install your system in another (presumably the customer's) environment that has the specified equipment. (A graduate assistant, QA team, or your instructor will likely test your installation procedures by trying to install your system either on another server or in a different folder on the development server.)
• Include screen shots for a Web interface