You are on page 1of 5

Recommended Outline for Software Development Projects Title Page Executive Summary Table of Contents List of Figures, List

of Tables, List of Notations Introduction Project Context Purpose and Description Objectives Scope and limitations Review of Related Literature/Systems Technical Background Methodology(see A.3) Requirements Specification Analysis Design Development and Testing Recommendations Implementation Plan (Infrastructure/Deployment)

Appendices may include the following Relevant Source Code Evaluation Tool Sample input/output/Reports Users Guide Curriculum Vitae

---------------------------------------------------------------------------------------------------------------------------------------------Recommended Outline for all types ITP Final Document for Capstone Project Title Page Approval Sheet Acknowledgement* Executive Summary Table of Contents List of Tables List of Figures List of Notations Chapter I. Introduction 1.1 Project Context 1.2 Purpose and Description 1.3 Objectives 1.4 Scope and Limitations Chapter II. Review of Related Literature/Review of Related Systems This section discusses the features, capabilities, and limitations of existing research, algorithms, or software that are related/similar to the project. The reviewed works and software must be arranged either in chronological order, or by area (from general to specific). Observe a consistent format when presenting each of the reviewed works. Part of the contents of this section is lifted from Chapter 2 of the Proposal. Additional materials gathered during final document Writing stages must also be included. Chapter III. Technical Background -Technicality of the project -Details of the technologies to be used

-How the project will work This section discusses the theories and concepts to be used in the course of designing or developing the project. Include only those concepts that you feel will be needed. Chapter IV. Methodology (please see A.3 for more info) Requirements Specification Analysis Design Development and Testing This section lists and discusses the specific steps and activities that will be performed by the proponents to accomplish the project. The discussion covers the activities from pre-proposal to Final Document Writing. This section also includes an initial discussion on the theoretical/conceptual framework to be followed. Examples of activities include inquiry, survey, research, brainstorming, canvassing, consultation, review, and interview, observe, experiment, design, test, document, etc. The methodology also includes the following information: who is responsible for the task the resource person to be contacted what will be done when and how long the activity will be done where will it be done why should be activity be done Chapter V. Recommendations Implementation Plan (Infrastructure/Deployment) This chapter gives an assessment of what happened in this project. It presents explanations and justifications on how the objectives of the project were met, to what extent and why some objectives were not met. This chapter also includes a discussion of possible improvements that can be made on the software, as well as future directions of the research topic in general. This serves as a springboard for projects that may be done by capstone project proponents. Appendices may include the following Relevant Source Code Evaluation Tool Sample input/output/Reports Users Guide Curriculum Vitae References (see Section A.1) USERS MANUAL (see Section A.2) A.1 Format for References, Citations, and Quotations Reference and citation Format for the Communications of the ACM By Dr. Andy Dong The Association for Computing (2003, Mueller et al., 2003) Machinery is the pre-eminent professional body dealing in all aspects of information technology. This is a style guide for their reference and citation format. Note that there are some slight stylistic differences between the format for the magazine Communications of the ACM (per the style in EndNote) and the ACM conference proceedings reference format (per the style in the ACM conference proceedings template). This document will describe the Communications of the ACM style. In practice, adherence to a single, consistent style is satisfactory. References Section The References section appears at the end of the paper. All references appear alphabetically by the lead authors last name and are numbered consecutively. A clear header should be used to indicate the start of the References. Example: References 1. Bless, H. The Interplay of Affect and Cognition. in Forgas, J.P. ed. Feeling and Thinking: The Role of Affect in Social Cognition, Maison des Sciences de l'Homme and Cambridge University Press, Cambridge, 2000, 201-222. 2. Garcia, A.C.B. and Howard, H.C. Acquiring design knowledge through design decision justification. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 6 (1). 59-71.

Citation As you write your report, you will cite your references. A citation to a reference in the body of the text is indicated by a bracketed number corresponding to the reference number in the References section. Example: During high stress periods, individuals should focus on the situation-specific tasks rather than rely on general knowledge structures. [1] Reference Formats GENERAL INSTRUCTIONS A complete reference should contain the name(s) of the author(s) and/or editor(s), the title of the article, the name of the book or conference proceedings where appropriate, and bibliographic information about the article such as the name of the publisher, the city of publication, and the page numbers. The basic concept is that the reference should be sufficiently complete so that the reader could readily find the reference and can judge the authority and objectivity of the reference.

All author names appear as Lastname, Initials. For example, if Andy Dong is the primary author and Alice M. Agogino is the second author, the correct appearance of the author names would be: Dong, A., and Agogino, A.M. THIS IS THE REFERENCE FORMAT FOR A BOOK. Authors. Title. Publisher, City of Publication, Year of Publication. Example: 1. Fogg, B.J. Persuasive technology: using computers to change what we think and do. Morgan Kaufmann Publishers, Boston, 2003.

THIS IS THE REFERENCE STYLE FOR AN ARTICLE WHICH APPEARS IN AN EDITED BOOK. Authors. Title. in Editors Title of edited book, Publisher, City of Publication, Year of Publication, Pages. Example: 1. Fischer, G. and Nakakoji, K. Amplifying designers creativity with domain-oriented design environments. in Dartnall, T. ed. Artificial Intelligence and Creativity: An Interdisciplinary Approach, Kluwer Academic Publishers, Dordrecht, 1994, 343-364. THIS IS THE REFERENCE STYLE FOR A JOURNAL OR MAGAZINE ARTICLE. Authors. Title. Journal or magazine name, Volume (Issue), Pages. Example: 1. Hirsh, H., Coen, M.H., Mozer, M.C., Hasha, R. and Flanagan, J.L. Room service, AI-style. IEEE intelligent systems, 14 (2). 8-19. THIS IS THE REFERENCE STYLE FOR A CONFERENCE PROCEEDINGS. Authors, Title. in Title of conference, (Location of Conference, Year), Publisher, Pages. Example: 1. Leclercq, P. and Heylighen, A. 5,8 Analogies per hour: A designer's view on analogical reasoning. in 7th International Conference on Artificial Intelligence in Design, (Cambridge, UK, 2002), Kluwer Academic Publishers, 285-303. THIS IS THE REFERENCE STYLE FOR ELECTRONIC MEDIA (ARTICLES, IMAGES, ETC.) RETRIEVED FROM THE WEB. FOLLOW THE REFERENCE FORMAT FOR A JOURNAL ARTICLE AND THEN INCLUDE INFORMATION ABOUT THE WEB SITE AND THE DATE WHEN YOU RETRIEVED THE RESOURCE. NOTE THAT THE DATE OF PUBLICATION AND THE DATE OF RETRIEVAL OF THE ARTICLE MAY NOT BE THE SAME. WHEN THERE IS NO DETERMINATE DATE OF PUBLICATION, USE (N.D.) IN THE DATE FIELD. WHERE POSSIBLE, INCLUDE THE NAME OF THE ORGANIZATION HOSTING THE WEB SITE. Examples: In the following example, the Cornell Chronicle is a regular newsletter which is published online. Thus, we follow the journal/magazine format and include the volume and issue. Steele, B. Look, Ma, no wires! Cornell class project tests wireless networking, Cornell Chronicle, 31 (35). Retrieved February 15, 2004, from Columbia University: The following Web page has no evident author, but the Revised date in the footer gives us the date of publication. MIT Project Oxygen: Overview, 2004. Retrieved March 15, 2005, from Computer Science and Artificial Intelligence Laboratory, Massachusetts Institute of Technology: FOGG, B. J. (2003) Persuasive technology : using computers to change what we think and do, Amsterdam ; Boston, Morgan Kaufmann Publishers. MUELLER, F., AGAMANOLIS, S. & PICARD, R. (2003) Exertion interfaces: sports over a distance for social bonding and fun. Proceedings of the SIGCHI conference on Human factors in computing systems. Ft. Lauderdale, Florida, USA, ACM.

A.2 Users Manual All software systems are required a USERS MANUAL. Most of the contents of the Users Manual are based from chapter 4 of the main project document (specifically on the system functions and features). The difference lies in the manner of presentation. Chapter 4 of the main project document is oriented towards highly technical systems designer, thus it gives an overview of the major modules of the system and their interactions. On the other hand, the Users Manual is oriented towards end users, who might be nave users. Therefore, it gives a detailed step-by-step instruction on how to use each function and feature of the system.

The suggested outline of the Users Manual is as follows: Title Page (see Section xxx, but add the line USERS MANUAL below the project title) Table of Contents 1.0. Introduction This section gives an overview of the system. It includes the following subsections: 1.1. System Requirements This section lists the minimum hardware and software requirements needed to properly execute the system. 1.2. Installation This subsection contains instructions on how to install the system, and the list necessary files and their respective directories. 1.3. Convention This subsection presents the convention used in the manual, e.g., text in boldface for emphasis on important concepts, text in italics are inputs from the users, etc. 2.0. Getting Started This section tarts with instructions on how to run the system, and the initial screen that will be displayed. It then explains the major components of the system, e.g., tool bars, menu options, status bar, etc. 3.0. <Module / Feature 1> Succeeding sections, from 3.0 to N-1, focus on the major modules or features of the system. Each section contains detailed instructions on how to use the particular modules, the available features and limitations of the module. : N.0. Messages This section lists all system messages error message, status message, information, and instruction message that the user may encounter while using the system. For each message, include a brief description and the possible courses of action that the user may take in response to the message. Below is a sample format: <Message Text> Description: Action: The messages must be arranged in ascending order, and may be grouped into subsections (e.g., N.1 Error Messages, N.2 Status Messages, etc.). A.3 5parts of Methodology Methodology (choose only the parts that are applicable to your capstone) 1 Environment (only for org-specific capstone project) Locale Population of the Study Organizational Chart/Profile 2 Requirements Specifications Operational Feasibility o Fishbone Diagram o Functional Decomposition Diagram Technical Feasibility o Compatibility checking (hardware / software and other technologies) o Relevance of the technologies Schedule Feasibility o Economic Feasibility o Cost and Benefit Analysis o Cost Recovery Scheme Requirements Modeling o Input o Process o Output o Performance o Control o Either of the following two (2) or combined, whichever are applicable: Data and Process Modeling Context Diagram Data Flow Diagram System Flowchart Program Flowchart (highlights only) Object Modeling Use Case Diagram Class Diagram Sequence Diagram Activity Diagram Risk Assessment/Analysis

3. Design



Output and User-Interface Design o Forms o Reports Data Design o Entity Relationship Diagram o Data Dictionary System Architecture o Network Model o Network Topology o Security Development Software Specification Hardware Specification Program Specification Programming Environment o Front End o Back End Deployment Diagram Test Plan o Test data Verification, Validation, Testing Unit Testing Integration Testing o Compatibility Testing o Performance Testing o Stress Testing o Load Testing System Testing Acceptance Testing (must be done after the Oral Defense)