Commit b297b87a authored by Jared Sexton's avatar Jared Sexton
Browse files

add SPECIFICATIONS.md

parent a22dee25
# CPTR 142: Group Project
## Project Introduction
The goal for this project is for you to learn though experience, to learn teamwork on project development and to build your confidence in problem solving.
Finally, you are to show the instructor what you have learned thorugh this project.
Plus ... it's just fun to be turned loose and be creative with all you have learned and then some!
| Topics | Date | Grading |
| --------------------------------- | ------------- | --------- |
| Project Introduction | February 2 | |
| Ideas Presentation | February 5 | |
| Groups Announced | February 7 | |
| Proposal | February 14 | S/N |
| Specifications | February 21 | EMRN |
| Check In | March 12 | |
| Group Code Review | March 15, 16 | EMRN |
| Project Implementation | March 18 | EMRN |
| Presentation and Demonstration | Final Period | EMRN |
This is intended to be a group project (3-4 persons).
## Ideas Presentations
Individuals will give an elevator pitch for their project idea.
* 1-2 minute pitch
* What is the project and why it should be a group project.
Students will submit their top two project choices.
## Groups Announced
The instructor will accounce the group projects and members.
## Proposal
The proposal states the basic idea and who will be working on the project.
* List of __group members__.
* Provide a __clear problem definition__.
What is required of the system?
What must it accomplish or provide?
Do you make any assumptions?
* Create a __repository in gitlab__ and give all group members access.
Please name the repository "cptr142\_group\_project".
___Submission___
Create a _PROPOSAL.md_ file in your repository with the above information.
E-mail the professor a link to your gitlab repository.
## Specifications
The specifications outlines the project design specifications and project management.
This is done BEFORE CODING!
* ___Complete UML diagrams___ of classes, member variables, member functions, and relationships between classes.
What structures and menus will be required?
* ___Procedural Flow Diagram___ The logical flow of your program
* ___Anticipated challenges___ and how will you address them?
* ___Project Management Plan___
* Name __individual group member tasks/responsibilities__.
Split up the tasks and implementation into portions per group member.
* __Timeline__ of individual and group delivery dates.
___Submission___
Create a _SPECIFICATIONS.md_ file in your repository with the above information.
## Check In
During class, each group will give a short status update on their project.
* How is the project progressing?
* What issues have they run into?
* Is there anything holding you back from completing the project on time.
## Group Code Review
* Review the project and share the code you wrote.
* 20 minutes group review to reflect your understanding of concepts used in your project.
* Quick overview of the project.
* Individual sharing and code questions.
___Individual Group Member Summary___
* The individual participation write-up from each student will be submitted on [D2L](http://class.wallawalla.edu).
* What did you contribute to the project?
* How did the group work together?
* What would you do differently another time?
## Project Implementation
* Your project implementation MUST include the following:
* Use the [CS Department GIT Repository](http://gitlab.cs.wallawalla.edu) for version control and submission.
* __Object-oriented programming__ with classes.
* __Separate interfaces (headers)__, __implementation files__, a __main driver__, and __test driver__.
* __File I/O__.
Include some form of file use even if only to capture results.
* __Well-commented, “clean”, and well-organized code__.
* __Well-tested code__ with a driver file.
* __README.md file__ complete with known bugs and user operation instructions.
* You should __employ__ the following concepts _as appropriate_ to the program: vectors, pointers, dynamic memory, string manipulation.
* __Quality of the code__ and the problem __level of difficulty__ will be considered.
* __To make an E on this project__, you must reach into advanced concepts and present quality code solution.
Top projects designs show ingenuity, creativity, and efficiency.
Demonstration that you have shown initiative, going above and beyond basic course coverage into utilization of advanced concepts.
For instance, inheritance, polymorphism, recursion, graphics libraries, some other more advanced data structures of the STL Library (e.g. linked lists, stacks, queues, binary trees, etc.)
## Project Presentation & Demonstration
* 5 – 10 Minutes __max__! Present in a __professional, polished style__ as though in industry.
Note – You want to make a succinct and direct presentation.
You will __lose points__ if you go over 10 minutes for the presentation and demonstration!
* PowerPoint or presentation package to include (Maximum 6 slides):
* Problem definition
* Itemized requirements and challenges
* Class hierarchy diagram (UML Class Diagram)
* Procedural flow diagram
* Distinctive aspects of your approach (the “cool” factor)
* Brief demonstration of working program
# Feedback and Grading
The instructor will give feedback creating and editing a _FEEDBACK.md_ in your repository.
Please look at this file for project grade information.
# Project Ideas
___What to do? ... Some Project Ideas___
You should pick something that you are interested in or that is a nice fit with your major.
This is a project, if well-done, can be used in a portfolio and showed in interviews.
The following are just some ideas.
___You are NOT limited to these ideas.___
Your problem should be of equal or greater complexity than these suggested problems.
* Look through your __text__ for advanced problems or other texts for more ideas.
* __Model/simulation__ –
Simulations make for a great project because they present real, practical problems easily modeled yet with complexity.
Implement a program that simulates a real-life scenario.
Examples are simulating an airport air traffic control scheduling, processes of a hospital, a manufacturing floor, movement of aid for a natural catastrophe,
* __Interactive tutoring project__ –
Implement a program that creates an interactive tutoring for children or high school students.
Include some degree of “intelligent” tutoring – in other words, adjust your questions or difficulty of questions according to user responses.
Related: games with educational purposes.
* A __Business application__ -
For instance, a system for a small business might use a number of files and calculate profits (as per purchases, sales, expenses).
It might calculate payroll, track accounts payable, accounts receivable, customer purchases, bank accounts, etc.
* __A text-based game__ of your choice.
If it’s commonly available on the Internet -
Make it your own. For instance, be creative on approaches, components, functionality.
Or pick a different game...
* __An Interdisciplinary Application.__
For instance, a physics model, a bioinformatics model, a biological model, a societal or anthropological issue, scientific problems, an economic model.
* __Other ideas__ ... Bring it to me!!
## Specifications
The specifications outlines the project design specifications and project management.
This is done BEFORE CODING!
* ___Complete UML diagrams___ of classes, member variables, member functions, and relationships between classes.
What structures and menus will be required?
* ___Procedural Flow Diagram___ The logical flow of your program
* ___Anticipated challenges___ and how will you address them?
* ___Project Management Plan___
* Name __individual group member tasks/responsibilities__.
Split up the tasks and implementation into portions per group member.
* __Timeline__ of individual and group delivery dates.
___Submission___
Create a _SPECIFICATIONS.md_ file in your repository with the above information.
* ___Complete UML diagrams___
INSERT DIAGRAMS (Teacher, Student, Question)
* ___Procedural Flow Diagram___
* Loads data from text file from previous runs (users, progress levels, etc.)
* Ask the user for a username (after this point the interface will be different for teacher or student)
* _Student_
* A menu is displayed ("Practice Level #_", "Log Out")
* If they choose to practice, then the problems will start coming. They answer questions.
* At a certain point (if they have been getting questions right), before displaying another question it will ask if they want to test out of their current level ("yes" or "no")
* If "no", they will continue practicing, and it will ask again some questions later (3-5).
* If "yes", they will enter testing mode. The questions will be the same difficulty, and they will be given a set number of them (10, 15, 20).
If they get enough right, they will be congratulated, and advanced to the next level (the original menu will display again to "Practice" or "Log Out").
* _Teacher_
* A menu is displayed ("View Class Progress", "Add Students", "Adjust Student Progress", "Set Exit Code" "Log Out")
* If "View Class Progress", A table will be displayed that shows their students and the current level that they're on, as well as other relevant data.
Teacher has the option of outputting this table to a file for their records.
* If "Add Students", the teacher can create a new student user and set a progress level for them to begin at.
* If "Adjust Student Progress", the teacher will input an existing student and can edit their current progress level (either advance or push back).
* If "Set Exit Code", the teacher can change the code to close the program (from the login screen).
* If the exit code is entered, the program will save all changes to the text file and close.
* ___Anticipated challenges___
* _Saving data to file:_ This can be addressed by the section in the textbook about file I/O.
* _Generating enough problem types:_ This can be addressed by finding ways to keep the question types as similar to each other in implementation as possible, while still being different for the user.
For example, there may be only counting-type, addition-type, subtraction-type, and word problem-type problems, which would just get more difficult with bigger numbers.
* _Keeping every team member up to date:_ Some aspects of the program may carry over to other aspects (such as certain variable names, and function return types).
We need to stay up to date on how other people are using the code that we write and how we use code that others write. This can be accomplished by liberal saving to the gitlab repository,
and vigilance to changes that others make and how that will affect your own code.
* ___Project Management Plan___
* Name __individual group member tasks/responsibilities__.
Split up the tasks and implementation into portions per group member.
* __Timeline__ of individual and group delivery dates.
\ No newline at end of file
# Code Review Rubric
## CPTR 141: Fundamentals of Programming I
| Criterion | Excellent | Good | Adequate | Developing |
|---|---|---|---|---|
| **Program Specifications / Correctness** | No errors, program always works correctly and meets the specification(s). | Minor details of the program specification are violated, program functions incorrectly for some inputs. | Significant details of the specification are violated, program often exhibits incorrect behavior. | Program only functions correctly in very limited cases or not at all. |
| **Readability** | No errors, code is clean, understandable, and well-organized. | Minor issues with consistent indentation, use of whitespace, variable naming, or general organization. | At least one major issue with indentation, whitespace, variable names, or organization. | Major problems with three or four of the readability subcategories. |
| **Code Efficiency** | No errors, code uses the best approach in every case. | N/A | Code uses poorly-chosen approaches in at least one place. | Many things in the code could have been accomplished in an easier, faster, or otherwise better fashion. |
| **Documentation** | No errors, code is well-commented. | One or two places that could benefit from comments are missing them or the code is overly commented. | File header missing, complicated lines or sections of code uncommented or lacking meaningful comments. | No file header or comments present. |
| **Assignment Specifications** | No errors | N/A | Minor details of the assignment specification are violated, such as files named incorrectly or extra instructions slightly misunderstood. | Significant details of the specification are violated, such as extra instructions ignored or entirely misunderstood. |
### Program Specifications / Correctness
This is the most important criterion. A program must meet its specifications and function correctly. This means that it behaves as desired, producing the correct output, for a variety of inputs.
### Readability
Code needs to be readable to both you and a knowledgeable third party. This involves:
* Using indentation consistently (e.g., every block's body is indented to the same level)
* Adding whitespace (blank lines, spaces) where appropriate to help separate distinct parts of the code (e.g., space after commas in lists, blank lines between blocks of related lines, etc.)
* Giving variables meaningful names. Variables named `A`, `B`, and `C` or `foo`, `bar`, and `baz` give the reader no information whatsoever about their purpose or what information they may hold. Names like `principal`, `maximum`, and `counter` are much more useful. Loop variables are a common exception to this idea, and loop variables named `i`, `j`, etc. are okay.
* The code should be well organized. Code should be organized into groups of related statements.
### Documentation
Every file containing code should start with a header comment. At the very least, this header should contain the name of the file, a description of what the included code does, and the name of its author (you). Other details you might include are the date it was written, a more detailed description of the approach used in the code if it is complex or may be misunderstood, or references to resources that you used to help you write it.
All code should also be well-commented. This requires striking a balance between commenting everything, which adds a great deal of unneeded noise to the code, and commenting nothing, in which case the reader of the code (or you, when you come back to it later) has no assistance in understanding the more complex or less obvious sections of code. In general, aim to put a comment on any line of code that you might not understand yourself if you came back to it in a month without having thought about it in the interim.
### Code Efficiency
There are often many ways to write a program that meets a particular specification, and several of them are often poor choices. They may be poor choices because they take many more lines of code (and thus your effort and time) than needed, or they may take much more of the computer's time to execute than needed. For example, a certain section of code can be executed ten times by copying and pasting it ten times in a row or by putting it in a simple for loop. The latter is far superior and greatly preferred, not only because it makes it faster to both write the code and read it later, but because it makes it easier for you to change and maintain.
### Assignment Specifications
Assignments will usually contain specifications and/or requirements outside of the programming problems themselves. For example, the way you name your files to submit them to the course website will be specified in the assignment. Other instructions may be included as well, so please read the assignments carefully.
\ No newline at end of file
# CPTR 142-B Group Projects
All seven students who submitted a preference list (by saving their edits from Cloud9 to GitLab) got their first choice. One was assigned to the project that sudent proposed, giving four teams of two. The remaining four students were allocated among the four teams. So, every team has two who expressed a strong interest in that project.
I've tried to keep the teams relatively balanced with respect to how students are doing on homework and quizzes.
I haven't indicated any leaders, but since each team has the person who proposed the project, there should be a good start on ideas for what the project is trying to accomplish.
### Note
The follow teams have been created based on interest in proposed projects.
The project may change as you work with your group to make a __proposal__.
Remember the proposal must be accepted by the instructor.
## Text-based RPG
* Stefan Hess
* Austin Meservia
* Phong Pham
## Jeopardy Game
* Miles Kim
* Andrew Nascimento
* Sienna Pierre
## 1st Grade Tutoring
* Andrew Binder
* Eddy Marinez
* Jared Sexton
## Text-based Story
* Cody LaCourt
* Shamarli Nero
* Savannah Sexton
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment