% CSci 487: Senior Project \ Spring 2017 Assignments % **Instructor: H. Conrad Cunningham** % **26 March 2018** | [H. Conrad Cunningham ]() | Professor of [Computer and Information Science ]() | [University of Mississippi ]() | 211 Weir Hall | P.O. Box 1848 | University, MS 38677 | (662) 915-5358 # Assignments ## Professional Conduct As a student in CSci 487, you are obligated to conduct yourself in a professional, ethical, and legal manner according to the applicable policies, procedures, and expectations of the Department of Computer and Information Science, your School or College (Engineering or Liberal Arts), The University of Mississippi, and discipline of computer science (e.g., [ACM Code of Ethics ]()) and to the applicable Federal and State laws. It is your responsibility to carry out the work on your senior project and all of its component assignments with academic integrity. The project is an individual project that you must complete yourself, without assistance from other individuals. You will expected to sign a [Professional Conduct Affirmation ](<487profConduct.html>) statement acknowledging these expectations. ## Selecting a Project The basic idea of this course is to simulate a computer consulting job, where your instructor is the manager of your consulting organization and your project's sponsor is a client who needs a project done. You are the computer consultant who is assigned to complete the project. Your duty is to meet the needs of your client (sponsor) as well as the requirements of your manager (instructor). The only way you can succeed is by actually completing the project by the end of the semester. The following rules, or restrictions, apply to your project: 1. Your project must have one non-student person who agrees to serve as the sponsor of the project. 2. Your sponsor **cannot** be related to you. 3. Except in special circumstances approved in advance by the instructor, your sponsor should be located in northern Mississippi (preferably on campus or in the local community). 4. Even if your sponsor is someone with whom you have, have had, will have, or would like to have, paid employment, your project should involve unpaid labor on your part. 5. This is an individual project. You are responsible for all aspects of the project. 6. You are expected to find a sponsor and develop a project topic on your own. The project should involve nontrivial work requiring the knowledge, understanding, and skills you have attained in the undergraduate computer science program. The total amount of work should be roughly equivalent to a typical three-credit course. 7. You must make sure that your project is approved by the instructor and the sponsor and that the work you undertake satisfies the expectations of both instructor and sponsor. 8. You should identify the hardware, software, data, and reference materials you need to complete your project. Make sure that these are available--or will be available soon enough for you to finish your project by the last day of classes for the current semester. 9. You must carry out your project with academic integrity. You are expected to complete the project yourself, without assistance from other students, tutors, computer consultants, and other individuals. 10. You must ensure that your project conforms to the law and principles of professional ethics. In particular, no aspect of your project may involve any form of software piracy, copying, or plagiarism. During the first few days of the semester, please discuss any questions concerning your proposed topic with the instructor (or teaching assistant). ## Status Reports THIS SECTION WILL BE UPDATED FURTHER Most computing projects in work settings require periodic status reports. These help keep a project on track and the management aware of the progress being made and any problems encountered. Some of these reports are written, others are one-on-one oral reports to the manager or client, and others are reports to a work group. Some reports are informal; others are formal presentations or documents. This course will use two mechanisms for status reporting: - *weekly written reports posted to the Senior Project Journal on Blackboard beginning after Spring Break* A typical posting will consist of a brief paragraph, but it can consist of up to a page if needed. Each should give the current status, the progress made since the previous report, and any significant new problems that you have encountered. After submitting your [Revised Design Specification ](<#design-specification>) assignment, you should relate your status to the timeline and milestones you defined. This journal also enables you to record information during the semester that may be useful in the Final Report and Presentation. Unless otherwise noted in the schedule, each week's report is due before 4:00 p.m. each Monday. The instructor (or a teaching assistant) will check periodically and, if needed, comment on the status reports. - *brief oral reports* to the instructor, a teaching assistant, and/or a work group of classmates. The dates for these will be shown on the schedule or announced in other appropriate ways. Status reports are not separately graded documents, but the status reports will be examined by the instructor during assessment of the various assignments. ## Prospectus The purpose of the Prospectus assignment is to encourage you to define your topic quickly and begin work during the first few days of the term. You should choose an interesting and challenging project that you can complete during the semester and that demonstrates your abilities to the faculty, your fellow students, and potential employers. Before writing the prospectus, you should have one or more discussions of the project with your sponsor. Write a brief description of your project's topic. It may be difficult to include much detail at this point, but try to be as realistic and specific as possible. In particular, the prospectus should include: - what problem you are addressing with the project - what tasks you must carry out to complete the project - what end result or product will you deliver - what risks you face in the project Prepare your prospectus in a **double-spaced** format with a **12-point font** using a word processor or text formatter. The maximum length is **two pages**. The prospectus should also include the following information: - your name - your email address - a telephone number at which you can be reached - the proposed project title - the name, organization, telephone number, and email address of your sponsor Submit your prospectus to your instructor by the due date. Submit both a paper copy to your instructor and a PDF file to Blackboard. The instructor will review your prospectus and suggest changes that may be necessary prior to approval. Your prospectus must be approved by your instructor before you begin the actual work involved in your project. Your prospectus will also be reviewed by your sponsor. ## Design Specification The purpose of the Design Specification assignment is for you to describe your project in more detail than in your prospectus. You should approach your project in an orderly manner by defining the overall requirements and your implementation strategies before you undertake the programming work. This assignment has two parts: a written report and an oral presentation. In your design specification, **clearly define what is needed for the Minimum Viable Product (MVP)** to complete the project successfully. Your MVP must be approved by the instructor. The instructor will use the MVP to evaluate your project at the end of the semester. You may also define other product features that you plan or desire to deliver beyond the MVP. ### Written report If your project consists primarily of the development of a software system, the design specification should describe the following aspects. (If your project has a different nature, please discuss the content of your design specification with your instructor.) Use citations as appropriate. - Project overview -- Describe its context and purpose. - User requirements -- Describe the sponsor's expectations, the different types of system users, and how each type of user will need to use the system. - Development environment -- Describe the hardware, software, and data sets needed for implementation and testing and why you chose this environment. You should use a version control system and appropriate testing tools to support your development. - Deployment environment -- Describe the hardware, software, and data sets needed to support the delivered system and why you chose this environment. Consider what you need to do to install your project's software in the deployment environment. - Architecture -- Describe the structure of your software system. Give the major components and their relationships. You may want to use diagrams to illustrate the architecture. If your project involves a database, you should describe your database design (e.g., using a schema or Entity-Relationship diagram). - Implementation strategies -- Describe the strategies used by others, the strategies that you have considered, and those that you have chosen. Discuss the advantages and disadvantages of each and explain why you made the choices you did. - User interfaces -- Perhaps give user stories, screen shots, transition diagrams, or command descriptions. Consider the different types of users. - Test and integration plan -- Describe how you plan to test the individual components and the overall system. - Project timeline -- Describe the milestones, that is, the major tasks and the target dates for completion. - Bibliography -- List the textbooks, reference books, journal or conference papers, tutorials, Web documents, etc, you reference in this report or you otherwise expect to use in your project. This may include materials describing the application domain of the project. Prepare your design specification in a **double-spaced** format with a **12-point font** using a word processor or text formatter. In general, the document should be **five-to-seven pages** long. (If you give several screen shots or diagrams, you may need a longer document.) Include your name and project title in the heading of the document. Submit your initial design specification to your instructor by the due date. Submit both a paper copy to the instructor and a PDF copy to Blackboard. **Your MVP must be approved by the instructor.** Submit a revised design description at mid-semester that reflects the state of your project resulting from feedback and additional weeks of work. ### Oral presentation The purpose of the design presentation is to help you discover problems with your design and to give you practice in presenting technical material orally. (See the section on the final [oral presentation ](<#oral-presentation>) for more information about presentations in this class.) On the day that the design specification is due, you should be prepared to present your design orally to your instructor and classmates. The presentation should take no more than *10 minutes.* Use audiovisual aids as appropriate. For large classes, the design presentations will be distributed over more than one day according to the schedule set by your instructor. ## License Agreement THIS SECTION WILL BE REVISED AFTER CONSULTATION WITH THE OFFICE OF RESEARCH AND CIS FACULTY. The purpose of the License Agreement assignment is to provide you with informal experience in preparing a license agreement that defines the relationships between, and expectations of, you and your sponsor. The license agreement essentially defines an academic "contract" between you and your sponsor. It should define the items that you will provide to the sponsor and the schedule for delivering them. It should also define what the sponsor will provide you (e.g., regular meetings, access to software, hardware, or data). You may want to define any on-going responsibility that you will have to maintain the project's materials after delivery. An issue that may need to be resolved with your sponsor is what rights you and the sponsor (or his/her organization) have to the project materials (program executables, source code, documents) after delivery. In general, because your sponsor did go to some trouble to sponsor your work, he/she (or his/her organization) should have the right to use, modify, and extend the project software and materials after delivery. The sponsor should also have the right to protect any confidential or proprietary information or components that went into your project. However, since you were not paid to carry out the project, you may also want to retain the right to use it for other purposes, including development of a derivative product. You and your sponsor might want to consider allowing the software to be freely distributed under an "open source" arrangement. See the following for more information: - [The Open Source Definition, Open Source Initiative (OSI) ]() - [Creative Commons ]() - [GNU Licenses ]() - [Debian Social Contract ]() You may want to prepare a license agreement that is closely modeled after other existing agreements but adapted to the specific characteristics of your project. You are responsible for doing this assignment yourself, but the usual restrictions on copying text do not apply. Both you and your sponsor must sign the license agreement before you turn it in to the instructor. This should provide you with one last opportunity to make sure that you and your sponsor understand clearly what expectations are associated with your project. Most sponsors will expect the student to explain clearly and distinctly what the various features of your license agreement mean; some sponsors may in fact refuse to sign the agreement until you clear up any ambiguities. Submit the **signed** license agreement on paper to the instructor by the due date. Attach a statement on a separate page that identifies what other documents you used as models for your agreement. Be sure to keep a copy of your signed agreement to include in your project's final report. Also submit a scanned copy to Blackboard. ## Users' Manual The purpose of the Users' Manual assignment is to encourage you to provide your sponsor and other users with clear and complete instructions on how to *install*, *use*, and *administer* your project's product. This section assumes that your product consists primarily of standalone software. If your project is of a different nature, then you will need to restructure the users' manual appropriately. However, keep in mind that the purpose of this assignment is to explain how to use the product effectively. ### Installation The users' manual should explain how to install and configure your project's product on a computer system. As appropriate for your project, consider the following issues: - What does your product assume about its operating environment? What are its dependencies on other software platforms, tools, packages, libraries, frameworks, files, specialized hardware components, etc. - What information and system privileges does the user need to install the product? - How does the user build (e.g., compile, link) your product? Describe how to use any build scripts you provide. - How does the user deploy your project's files (executables, libraries, configuration files, etc.) to the target system? Describe how to use any installation and configuration scripts you provide. - How does the user configure the system once deployed? - How does the user uninstall the software? ### Use The users' manual should clearly describe the user interface structure and functionality. As appropriate for your project, consider the following issues: - What are the different types of users (e.g., administrator, staff, customer, general public, etc.)? What are the different needs of each? - What about users who are inexperienced (or lack confidence) with computers in general? Users who are lack knowledge of the application area of your product? For these, parts of the users' manual may need to be more tutorial in nature. - What about users who are experienced with computers but use your product infrequently? For these, the user manual may need to support quick access to common "how to" questions. - Is your product accessible to users with physical challenges? Some of these features can, of course, be partially handled within the user interface itself -- by providing an intuitive user interface design, informative error messages and warnings, builtin help facilities, etc. But separate documentation may be needed for some aspects. ### Administration and Maintenance If your product requires routine maintenance or administrative tasks not covered above under Use, you may need to describe those in a separate section. Similarly, you may also want to include a section that discusses how to enhance and extend the product and suggests possible enhancements. ### Assignment Submission and Assessment Prepare your users' manual in an appropriate format for the users of your product. Submit the users' manual to your instructor for evaluation by the due date. Submit both a paper copy to the instructor and a PDF or HTML file to Blackboard. During evaluation of your product, the instructor and other evaluators will examine your users' manual to run your program. They will determine the viability of your project by how much difficulty they have using your program with your set of instructions. Remember the instructor will make no assumptions about the machine or the program. The will do just what this document tells him to do. ## Product Implementation The purpose of the Product Implementation and Documentation assignment is to encourage you to produce a high quality, well-structured, and well-documented program implementation. Your goal is to prepare program source code and documentation that enables some future consultant to maintain and enhance your product readily. Use a consistent programming style that follows the best practices taught in your academic program and learned in internship or job experiences. Good programming style includes: - good choices of algorithms and of data, file, and database structures - use of good program structure and modularization - robustness of the program (e.g., the program checks for errors and handles them appropriately) - use of good development practices (e.g., version control system for source code and documents) - systematic testing of individual units and the overall system (e.g., using a well-defined set of tests and a testing tool) - readable source code (e.g., consistent choice of names, consistent indentation and format, straightforward coding practices) - appropriate internal comments - agreement between the documentation and the actual structure and behavior of the code Because you may be asked to print program listings, make sure the format of the source code both displays on the monitor and prints on paper in a pleasing fashion. Good practices for program documentation include providing the following as either block comments in the source code or as supplemental documentation: - a description of the overall program including such information as the author, objective, program architecture, inputs (including restrictions on values), outputs, side effects, date, and version history - a description of program's key information structures (e.g., global data structures, user-defined types, file formats, database tables and their relationships) - a description of each program unit (e.g., class, method, procedure, function, or module) including such information as the author, objective, relationships to other modules, inputs, outputs, side effects, and version history Use appropriate tools and notations in your documentation. For example, consider using an Entity-Relationship (ER) diagram to describe your database design, a Unified Modeling Language (UML) class diagram to describe your program's class structure, a Backus-Naur Form (BNF) grammar to describe your command language, a documentation markup language (e.g., JavaDoc) to generate documentation from your source code, a transition diagram to describe transitions between program states, etc. Prepare your supplemental documentation with a word processor, text formatter, or other appropriate tools so that it can be presented as a PDF or HTML document. Submit your source code and documentation to Blackboard as a zip-format file. ## Assessment Exam As a part of the Department's evaluation of the undergraduate computer science programs, the faculty administers a summative assessment examination in the Senior Project course. The instructor will schedule this exam near the end of the semester. ## Final Oral Presentation The purpose of the Final Oral Presentation assignment is to encourage you to be able to make short oral presentations in professional situations. Toward the end of the semester, you will be assigned a time slot for the presentation of your project. Your presentation should be 15 minutes long. There will be a question and answer session after each presentation. In determining your grade for the oral presentation, the relevant factors include: - professional appearance and bearing (e.g., prompt arrival, grooming and attire appropriate for a professional job interview, movement and body language during presentation) - logical and effective organization of the presentation - appropriate use of audiovisual aids - audibility and clarity of presentation - correct grammar and pronunciation - appropriate use of computing concepts and terminology - effective explanation of project - careful listening and helpful responses to questions - difficulty of project - mastery of subject matter The presentations are open to the public. In general, your audience includes the other Senior Project students, your instructor, other computer science faculty members and students, your sponsor (whom you should personally invite), and any other interested persons. In consultation with your instructor, your fellow students, and the systems staff, you are responsible for arranging to obtain and set up any needed equipment and software for your presentation. Normally the presentations will be scheduled at 20-minute intervals during the last two regular class periods of the semester. When there are too many students to fit in the class periods, the presentations will be spread over more days and more times. For example, a 42-student class might use the 3:00-7:40 p.m. periods on Monday, Wednesday, and Friday of the last week or perhaps use times on Tuesday and Thursday or the previous Friday afternoon. All students are expected to attend all the presentations. Any student who cannot attend a presentation should obtain the prior approval of the instructor. After the presentation, submit a copy of your presentation materials to Blackboard. Use a zip file if your materials include more than one file. ## Sponsor Evaluation The purpose of the Sponsor Evaluation requirement is to provide your sponsor with an opportunity to evaluate your performance in pursuing your project. Remember that your sponsor is your client or customer. Under the terms of the license agreement, you are to carry out the project and deliver the specified result to your sponsor before the end of the semester. It is your responsibility to ensure the instructor has complete and correct contact information (email address, telephone number, postal address) for your sponsor so that the sponsor can be contacted by the instructor to obtain the evaluation. You should mention to your sponsor that your instructor will contact him or her to evaluate your performance in the course. ## Final Report The purpose of the Final Report assignment is to provide you an opportunity to bring all aspects of your project together into one complete, final document. Be sure to include corrections to each document, as indicated by the instructor. Organize your materials in an attractive format and **bind them in the following order:** 1. title page (name of project, your name, sponsor, class and semester identification, etc.) #. abstract (an overview of the project based on your earlier prospectus) #. report (write a narrative discussion of your project as a whole, in a research paper format) #. users' manual #. TBD license agreement (a signed copy) #. Revised Design Specification submitted at mid-semester (include an addendum, if appropriate, describing variations/changes in the design after submission) #. bibliography #. a copy of the final oral presentation slides or other materials #. program source code and documentation (normally include an electronic copy of your project materials on an appropriate medium) Documents submitted in double-spaced format earlier should, in general, be changed to single-spaced format (which is more attractive and less wasteful of paper). You should bind the materials in a soft-cover binding that is only as thick as needed. To make the report easier to ese and evaluate, Insert tab separator pages between the sections. By using the Department's facilities such as the binding machine, you should be able to produce materials that are attractive and professional. Discuss the use of the binding machine with the Department's administrative support staff. Item 3, the report, is likely only item that is totally new in this assignment. This component is a narrative document that reports your experiences in carrying out your project. In writing this report, consider such questions as: How well were the project's goals realized? What "went right" and what "went wrong" in your design and implementation or in your interactions with your sponsor? What would you do differently if you were to do the project again? What did you learn from the project? What are possible extensions, enhancements, or alternative approaches to the project that can be considered? Etc. If you keep good notes of your work, it will help in writing this report. Once complete, submit a bound copy of your final report to your instructor. TBD You are also required to deliver all your project materials to your sponsor as specified in the License Agreement. ## Finals Week ### Final interview In addition to submission of the final report, you are required to schedule an interview with your instructor to demonstrate and discuss your project. At this time, your instructor may ask detailed technical questions concerning your product, its design, and its usage. The instructor may invite another faculty member or expert to assist with the evaluation of the final projects. ### Exit survey You are also required to complete the Department's Exit Survey. This survey is an opportunity for the faculty and staff to find out what you think about your program, the skills you obtained, and your future plans.