CSCE 492 Syllabus

http://capstone.cse.sc.edu/492syllabus

Academic Bulletin Description

CSCE 492 - Capstone Computing Project II
Credits: 3
Continuation of CSCE 490. Computer system implementation, testing, verification and validation of results. Written reports and oral presentations in a technical setting.
Prerequisites: D or better in CSCE 490 and CSCE 240 and CSCE 350
Note: Graduation with Leadership Distinction: Research

Learning Outcomes

The goals of the course are for you to:

1. Use new technologies such as software platforms, unit and behavioral testing libraries, and continuous integration tools, and use them in the development of a software application. ¹
2. Perform quality assurance analysis on a software application. ²
3. Design and implement a computer-based system, consisting of an appropriate mix of software and possibly hardware components, using the techniques, skills, and tools of modern computer system development practice. ³
4. Work effectively as part of a team. Make significant contributions to the team's work. ⁴
5. Communicate (written and orally) skillfully with peers and with outsiders in a real-world styled environment. ⁵

The learning outcomes are equivalent to those of a face-to-face (F2F) version of the course.

Instructors

Dr. Jose M Vidal <vidal@sc.edu> is the instructor.

To contact me, which you should whenever you have a question or need any sort of help, do the following:

1. Mention me @josemvidal in GitHub in one of the Issues or in your team discussion. I will reply within 24 hours.
2. On USC's teams at teams.microsoft.com if you want to chat or video conference. I will reply immediately if I am online, otherwise we can setup a time to meet.
3. Email me at <vidal@sc.edu>. I will reply within 24 hours.
4. Check my Office Hours to see if you can drop by my office in Storey 2231. Or email me for an appointment.

Teaching Assistants

• Jonathan Sharp <jpsharp@email.sc.edu> @JPSharp. My office is directly across the hall from the Capstone Lab in innovation room 1209, office hours are Monday, Wednesday 11am-12:00, or by appointment.

• Matthew Sharp <mpsharp@email.sc.edu> @MPSharp. Office is at Innovation 1209. Office Hours are Monday, Wednesday 11am-12:00, or by appointment. Please open a github issue or send me an email before coming to office hours.

Preferred method of communication: If you need TA help with your project please create an Issue in your repo and assign it to the specific TA (or to @instructors to get all of us), with the following:

1. Pictures of error/errors you are encountering.
2. Pictures and or videos of the steps you have gone to fix your error.
3. Links to any solutions you might have tried.

Description

This is the second part of a two-semester capstone course in the Department of Computer Science and Engineering for computer engineering, computer science, and computer information systems majors. It is intended to bring together and use many of the concepts and skills learned in other courses in the curriculum.

This class will focus on programming and testing. The teams will build, test, debug, and deploy a professional-quality application. They will also create a website and video to showcase their work and give a live demonstration and presentation to the class.

Communication

We communicate via GitHub.

Our GitHub Organization is SCCapstone. Each team has its own private repo under that org. You will do all your work inside that repo (code, Issues, Wiki).

If you have a question for us just @-mention us (@josemvidal for me, or use @instructors to get both the professor and the TAs). Alternatively, you can create an Issue in your repo with label :question and assign it to @josemvidal. We will reply within 24 hours.

Make sure you are Watching our SCCapstone Discussion repo (also on the top-right of this website). That is were we will post all announcements. You are expected to keep up to date with the discussion.

I have Office Hours during which you or your team can drop by my office in Storey 2231.

I also highly recommend you setup your own private chat app for your team.

Textbook

There are no textbooks or assigned reading materials for this class. All readings/materials comply with copyright/fair use policies.

Meeting Times

This class does not have a scheduled lecture or labs. Everything is done online.

Capstone Laboratory

We have a physical lab! The Capstone Lab is located in the Story building in room 1210. The building and room will be open to you 24/7. You will need to USC ID to get into the lab (and into the building after hours) and only students registered for CSCE 490 or 492 can get into the lab.

The lab has 13 Mac minis, 8 Windows PCs, and 8 Ubuntu Linux machines. You can login to any one of them with the same credentials you use for the Linux labs. You can use the lab for meetings and to work on the project.

We also have Androids and iPhones available to borrow, and a couple of tablets, Alexa dots, etc. You can borrow them if you need them for testing your app. Contact our sysadmin Ryan Austin to setup a time to pick up your phone. You will need to bring you USC ID and make sure you are enrolled in the class.

New Team Member Assignment

Every year a few students receive a special pre-requisite override that allows them to take 492 before 490 (see "Can I take 492 before 490?". These students will be randomly assigned to teams on the first day of classes of 492. I will give preference to teams that lost member and thus have fewer than 4 members. The goal is to have all teams with 4 or 5 members, if at all possible. The assignments will be done randomly, in order to be fair to everyone.

Grading Scale

The final grade for this class will be calculated as follows:

Item	Percentage of Final Grade
Testing	5%
Weekly Report	3%
Beta Release	10%
Release Candidate 1	12%
Quality Assurance	5%
Website	5%
1.0 Release	50%
Final Demo (Video)	10%
Personal Contribution	up to 100%
Firing a Team member	F if you are fired

Milestones are graded as either team, where the whole team receives the same grade, or individual, where each student receives their own grade. Each Milestone webpage tells you whether that Milestone will be graded as team or individual. Click on it to see more details.

Grading Scale

There is no rounding. We floor all values.

90% <= A
88% <= B+ < 90%
80% <= B < 88%
78% <= C+ < 80%
70% <= C < 78%
68% <= D+ < 70%
60% <= D < 68%
60% < F

Grading Feedback

We will give you feedback by writing new Issues in your repo. These Issues will include general feedback about your work, bug reports, feature requests, questions for further clarification (which you should answer in that Issue), etc.

Grades will never be posted on GitHub. We will post your grades at blackboard.sc.edu.

Personal Contribution

Notice that your personal contribution counts for up to 100% of your final grade. Your personal contribution will be determined by me. I will be looking at:

1. the peer evaluation done by all team members on all their team members, submitted at the end of the semester,
2. your Weekly Reports,
3. your git log,
4. participation in chats/GitHub Issues/meetings.

I will assign you a personal contribution grade of: Satisfactory, Poor, or Unacceptable. Typically, the vast majority of students are marked Satisfactory which means they receive the grade as calculated by the Grading formula. Students who score Poor or Unacceptable have their final grade adjusted accordingly, entirely at my discretion. In the rare case where almost all the coding is done by one or two students, while the rest are Unacceptable, then all their grades might be be adjusted up or down, accordingly.

I expect all team members to make significant contributions to their team. Team members that do very little work will fail the class. In CSCE 492 I expect all team members to make significant code contributions, as evidenced by their git log on GitHub. Team members in CSCE 492 who do little or no programming will fail the class.

In other words, it is possible for a student to fail the class even when the student's team project receives an A.

Also, everything you do must be in your GitHub repo. If it is not there under your username then it does not count for this class. See the Academic Integrity section for more details.

You must write Code

This is a software engineering class, so, you must make significant code contributions in order to pass the class. Other contributions do count, but are not enough by themselves.

Q: But, I did all all the CSS/HMTL for our webapp? That is nice, but HTML and CSS are not programming languages; they are not "code". This is a software engineering class. You need to also make significant code contributions. Everyone in the team must demonstrate that they can write code or they will Fail the class. I recommend that the Design work be split among team members, so everyone gets to do a bit of CSS/HTML.

Q: But, I did all all the animations/sounds for our game? That is nice, but this is a software engineering class, not media arts. You will not get credit for doing the art. I recommend that all games use free art assets found in many websites, rather than spend time doing their own art.

Q: But, I manage our website/database? That is nice, but this is a software engineering class, not Information Technology. Yes, programmers need to also know IT basics. Luckily, setting up and maintaining a website/firebase/mongo/etc. should not take longer than a few hours. Do not make it more complex than it needs to be. For example, there is no need to add load-balancing to scale to thousands of simultaneous users. In this class we only care that the software works, not that the infrastructure scales. I do not have the resources to test webapps for scalability.

GitHub Submissions

All the code that you write for this class must be in git and pushed to your team's GitHub repo. You will turn in everything else in your GitHub wiki. In other words, everything you do will be in your github repo. If it is not there, you will not receive credit for it. The academic integrity section explains what happens if you use someone else's GitHub account or commit code that you did not write.

Firing a team member

The steps to fire a team member are:

1. Keep a record of the team member's performance: git log, wiki edits, assigned Issues (all of which are automatically kept for you in github), meeting attendance, etc.
2. Write up the complaint and bring it to me.
3. Come up with some specific Issues (features) that should get done by the team member, within a 2-3 week period: the deadline.
4. I give the student a Formal Warning, and tell them they need to get their assigned Issues done by the deadline.
5. If no significant improvement happens within the deadline then the student fails the class. Yes, the student gets an F in the class.

I recommend you start the firing process early in the semester. If you have a new team member, that is, someone who is taking 492 before 490, that person knows that they are required to be contributed code commits by the end of January. If they are not contributing code by the end of January then you should start the firing procedure as they will likely not contribute anything to your project.

If you don't have the time to devote to this class this semester I recommend you drop it. This class takes a lot of time. It is better to graduate a year later than to get an F and graduate a year later anyway.

Academic Integrity

All students must review the Office of Academic Integrity sanctions. One or more of the following sanctions may be imposed for Academic Integrity violations: 1) Expulsion from the University; 2) Suspension from the University for a period of no less than one semester; and/or Probation. A combination of the above sanctions may be implemented. It should be noted that submitting someone else’s work is cheating and against the Carolina Code. Cheating, or any other Academic Integrity violations, will result in failure of the course for all involved parties. All parties will also be referred to the Office of Academic Integrity for additional retribution. Contact Information: Byrnes 201, 803.777.4333, https://www.sa.sc.edu/academicintegrity

Cheating on a test or copying someone else’s work, will result in a 0 for the work, possibly a grade of F in the course, and, in accordance with University policy, may be referred to the University Committee for Academic Responsibility and may result in expulsion from the University. To avoid academic espionage be careful how you dispose of printed copies of your work and who you show your work to, do not leave disks or thumb drives with copies of your work lying around, and never give anyone else access to you account for any reason.

In this class using someone else's github account, doing a git commit using someone else's identity, or committing code written by a team-mate or someone else, are all considered forms of cheating. This offense will be treated exactly the same as taking a test for someone else. If it is done with the consent of the other person then both people are equally at fault. All cases will result in a formal report to the Office of Academic Integrity, which might lead to expulsion from USC.

Committing code that was written by someone else is considered plagiarism and will also be reported to the Office of Academic Integrity. Of course, you can use third-party libraries and commit them into your repo if needed, but always make sure those files have the original author's name and license (they almost always do). If you do need to paste in someone else's code into your repo then make sure your comments in the code make it clear where the code comes from and who wrote it. Also, try to add all third-party code in separate commits, using the --author= option to give credit to the original author.

Tip

If you borrow a friend's computer then you should create a new account for yourself on it. You can then setup git to commit under your name and not theirs. This will also let you install all the other things you might need, without messing up your friend's setup.

When using bits of code from stackoverflow.com I recommend you add a comment with the URL to the original webpage. It gives credit to the original author. It will also help you later on when you realize that you do need to actually understand how that bit of code does its magic.

Late Work/Make-up Policy

No late or make-up work is accepted. All assignments (Milestones) are due by the deadline as posted on this website, on the first day of classes. Work incrementally. Continiously push your latest changes to GitHub. Turn in whatever you have by the deadline. User error does not qualify you for any kind of postponement.

Incomplete Grades

Incompletes will be granted only in accordance with university policy.

Technologies Used

We use GitHub for all class communications.

Each team will first choose a technology stack (for example, Android Studio with Kotlin and firebase), learn it, and then code their app using their chosen technology stack.

Minimal Student Technical Requirements

This is a Senior Software Engineering capstone project class. By this time you have taken many programming and technology classes. As such, all students are assumed to be competent programmers familiar with several programming languages, able to use an Integrated Development Environment, familiar with coding tools such as git and GitHub, and know how to install software and fix problems with their computer.

Instructional Methods

This is a project class. Each team of 4-5 students meets (online or in-person) with the instructor regularly to receive direct feedback on their progress, and receive any help if needed. The instructor and TAs will also provide feedback on the students' work online in GitHub.

Feedback

You will receive feedback on the content and quality of your work via GitHub Issues posted by the teacher and the TAs. We will post feature requests, but reports, and general feedback on the GitHub Issues for your repo. See the Teamwork lecture for more details.

Grades will never be posted on GitHub.

Expectations of the Instructor

I am expected to facilitate learning, answer questions appropriately, be fair and objective in grading, provide timely and useful feedback on assignments, maintain adequate office hours, and treat you as I would like to be treated.

Diversity and Inclusion

The university is committed to a campus environment that is inclusive, safe, and respectful for all persons, and one that fully embraces the Carolinian Creed. To that end, all course activities will be conducted in an atmosphere of friendly participation and interaction among colleagues, recognizing and appreciating the unique experiences, background, and point of view each student brings. You are expected at all times to apply the highest academic standards to this course and to treat others with dignity and respect.

Accommodating Disabilities

Reasonable accommodations are available for students with a documented disability. If you have a disability and may need accommodations to fully participate in this class, contact the Student Disability Resource Center: 777-6142, TDD 777-6744, email sasds@mailbox.sc.edu, or stop by 1705 College Street Close-Hipp, Suite 102, Columbia, SC 29208 All accommodations must be approved through the Student Disability Resource Center.

Identification of Student Interaction Provisions

• Student-to-Instructor (S2I): Students interact with the Instructor via GitHub, email, online, and face-to-face interactions, as needed.

• Student-to-Student (S2S): Students interact with the other students in their team via GitHub, as well as any other technology they choose to use.

• Student-to-Content (S2C): Students are responsible, with the aid of the teacher, for finding and using any and all resources that will help them learn their chosen platforms, see the Research Milestone.

Schedule

This is a project class. There are no lectures. However, there is a list of Milestones (assignments) with deadlines that all teams must meet, along with some online forms that must be filled out. They are all listed below and in the deadlines page. Click on each one to see it.

January

8^th Monday. If you did not take 490 last semester, then you must email me your GitHub username, so I can add you to a team.

11^th Thursday. I will assign all new 492 students to a team. You will receive my email and GitHub invite.

28^th Sunday. First part of the Testing Milestone due.

February

25^th Sunday. Beta Release Milestone due.

March

31^st Sunday. RC1 Milestone due.

31^st Sunday. I will post the team assignments for the Quality Assurance milestone: who will be testing who.

April

14^th Sunday. Quality Assurance Milestone due.

15^th Monday. I will post the "Senior Survey form", and the "Peer Reviews form."

18^th Thursday. Website Milestone due.

22^nd Monday Final Demo Video Milestone

22^nd Monday. 1.0 Release Milestone due. Second part of Testing due.

23^rd Tuesday. Fill out the Senior Survey form.

23^rd Tuesday. Fill out the Peer Reviews form.

---

1. Assessed via Testing Milestone ↩

2. Assessed via Quality Assurance Milestone ↩

3. Assessed via 1.0 Release Milestone ↩

4. Assessed via personal contribution ↩

5. Assessed via Website Milestone and Final Demo Milestone ↩