CSC 1060 Term Project Playbook - individual project

Objectives - So far, we\'ve written several small programs in C++ to get a handle on the languages and make meaningful comparisons with other languages we already know. For the rest of the semester, you will work independently towards a substantial C++ project of your design. \"What\" the project i...

Objectives - So far, we\'ve written several small programs in C++ to get a handle on the languages and make meaningful comparisons with other languages we already know. For the rest of the semester, you will work independently towards a substantial C++ project of your design. \"What\" the project is not essential, but it is exciting and fun for you so that you are motivated to work hard until the end of the semester. - Using imagination/being creative, describing a program, and working it through to completion. - Develop new classes to fit your needs. - Using the C++ libraries - Designing & testing a program - Evolving a program - Creating documentation for users and implementers - Programming a more extensive problem set -- not a small, predefined problem - Make something that is fun! There are six parts to this project: ------------------------------------ 1. Project proposal 2. Intermediate deliverables 3. Alpha overview 4. Final source code 5. Video presentation 6. Peer Evaluation Overview You will work on a project that will extend until the end of the semester. We will begin in Week 4. This leaves 11 weeks of course time for the project (classes, labs, dedicated homework time), ending with video presentations on the second to last day of class. You will be designing and implementing a game/program of your choice. Develop a game/program driven by user commands involving moving between different locations or game states. The final game should be fun and have some goal -- some way to win it. The game may be for one person working against what is built into the program, or it may involve several players. Start by brainstorming and thinking of ideas: do not dismiss ideas at this point. That is what brainstorming means - having your internal critic going inhibits creativity. After you have a long list from brainstorming, it is time to think more practically, settle on one basic situation, and feel a large inventory of features you would like it to have. Order the features, considering the importance, apparent ease of development, and what depends on what else. Get something simple working, and then add a few features at a time, testing the pieces added and the whole project up to that point. Test, debug, and ensure the program works completely before using your experience to decide what to add next. This may be different than what you imagined! Early stages (alpha) do not need to be full-featured but ensure that you build up to a version you can win, including interesting features. You should end with a game with enough instructions for the user so that someone who knows *nothing* of your implementation process or intentions can play the game successfully. Your implementation should also be documented, assuming a new team of programmers is about to take over after your departure and is looking to create another version. the process =========== 1. Break out specific goals for the project. How are you heading for your overall purposes? Are you biting off a significant and manageable amount? Before moving very far, you should check in with me on parts 2 and 3. This will be new for most of you. 2. Plan and organize the necessary parts and the interfaces between the parts. 3. Write the flowcharts, pseudocode, and IPO charts first. Do not get gung-ho; take off and start writing code before you have documented interfaces. I have seen it happen; lots of code must be rewritten later. Think first code last! 4. Do unit tests on your work, fix them, and test again\... You are strongly encouraged to follow modern programming practice, which involves splitting each formal version into smaller steps that can be completed and tested following a similar process. Order pieces, so you only need to code more before testing and combining with elements that already work. This is enormously helpful in isolating bugs! **This is important**. If you thought you spent a long while fighting bugs in your small homework assignment, that is nothing compared to the time you could spend on a large project, mainly if you make many haphazard changes at once. Project proposal ================ This file should be in the Assignments section in D2L by the due date. You will need to produce a written project proposal: a proposed description of the application your team will be building. This deliverable intends to (a) make sure that your project idea meets the requirements, (b) get some feedback on your idea, and (c) make sure you start thinking about the program \"early\"! While you can iterate and adjust aspects of the project during development, you should decide on the basic goals of the project for this proposal. Your proposal will be a short-written document (around a page of writing, plus some pictures) describing your project, including a medium-to-high fidelity mockup/prototype to illustrate the design and usage of your app. Overall, this proposal aims to communicate what app you will be building and what it will be used for so that others (i.e., your professor) clearly understand what you will be creating. Program Description ------------------- Your proposal should contain a written, non-technical description of what you will build. Your description should be specific and concrete: it should explain exactly what your program will do, who will use it, and why. The description must only be long enough to clearly define the app\'s functionality and purpose (probably around a page). intermediate deliverables ========================= This folder should be in the Assignments section in D2L by the due date. 1. Include parts 2-4 listed below, but an intermediate version needs not run and does *not* need to have the code working 100% yet -- **using stub files, it should compile**. 2. Have documentation of your project: 1. Pseudocode, flowchart, and class diagrams 2. Unit test cases 3. Functions/Methods, including summary description and description of parameters and return values. 4. Source code thus far 3. Where are you planning to go from here? 4. Review the deliverables list again and ensure your collection is complete. Alpha Presentations =================== The alpha presentation will be a quick (no more than two minutes) stand-up to the class on your project thus far. Each person must speak about the project. Final compiled source code ========================== 1. One zipped file, LastNameCSC1060FinalProject.zip, including ALL source code files and user instructions, was uploaded to the D2L assignments folder **Final Project.** 2. **A file called User instructions.txt**. You will create a file that tells the user how to run your program. Include any messages built into the beginning of the program and mention the file name of such external documentation if you have it. 3. **Programmer documentation**. Document the public interface for all methods in **comments** directly before the method heading. Add implementation comments embedded in the code that adds clarity (not just verbosity). Optional: You may have a separate overview document. Include "Overview" in the file name. 4. Project Executable (.exe) file or link to your replit uploaded to Discussions area. 5. Video Presentation ================== A **five-minute** presentation **video** of your work will be shown to the class on the second to last day of class. Upload video to the Discussions area A few sample questions: Explain your code and how your program works. What was the overall idea? What was the overall organization? What did you learn beyond the regular class topics others might find helpful? What were your biggest challenges? Explain your design process and code and show specific bits that gave you trouble or are instructive if you like. Peer evaluation =============== A peer evaluation form must be completed and submitted for each presentation. ** **CSC 1060 Final Term Project code will consist of: ====================================================== 1. A flowchart or Pseudocode of the design of the program 2. IPO Chart 3. Class diagrams for each class used 4. Your code must use the separation of the public interface and detailed implementation well. A minimum of three files: main.cpp (**a minimal main**), CustomClassName.h, CustomClassName.cpp 5. Use of function overloading 6. Use of Abstract Data Type 7. Use of objects & classes 8. Use at least one exception handling (try, catch, throw) 9. Use of pointers 10. Use of Input/Output files 11. Use of arrays/vectors 12. Use of built-in functions and, at a minimum, two user-defined functions 13. User instructions 14. Consistent well-commented code. 15. Source code in Replit OR uploaded to D2L 16. Video presentation uploaded to discussions one hour before class starts 17. Peer Evaluation grading RUBric ============== All **six** tasks below must be completed to pass the course. If a final, correctly compiled source code AND a video presentation of the project are not submitted by the due date, a final term project will not be accepted or graded. This project is required to demonstrate knowledge of course competencies. Failing to submit items means failing to demonstrate knowledge, which means not passing the course! Tasks: Points ---------------------------- --------- ---------- Project Proposal 50 24% Intermediate Deliverables 25 12% Alpha Presentations 25 12% Final compiled source code 50 24% Video Presentation 50 24% Peer Evaluation 10 5% **TOTAL POSSIBLE** **210** **100%**