Skip to content

CSCE 490 Syllabus

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

Academic Bulletin Description

CSCE 490 - Capstone Computing Project I
Credits: 3

Major team-based software design project to be undertaken in a student’s final year of study; project planning, software requirements analysis, design, and specification. Written reports and oral presentations in a technical setting.

Prerequisites: Prerequisites: CSCE 240, either ENGL 462 or ENGL 463.

Prerequisite or Corequisite: CSCE 350.

Note: Carolina Core Integrative Course, Computer Information Systems, BS
Carolina Core Integrative Course, Computer Science, BSCS
Carolina Core Integrative Course, Computer Engineering, BSE

Graduation with Leadership Distinction: Research

Learning Outcomes

The goals of the course are for you to:

  1. Apply new technologies such as software platforms, libraries, source control tools, or APIs, to the development of a software  application. 1
  2. Design an effective and appealing user interface for a software application using modern design tools. 2
  3. Gather and write requirements for a software application. 3
  4. 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
  5. Work effectively as part of a team. Make significant contributions to the team's work. 5
  6. Recognize professional responsibilities and make informed judgements in computing practice based on legal and ethical practices. 6

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, or create an Issue with label:question and assign it to me. Both result in me getting a Notification. I will reply within 24 hours.

  2. If you need to contact me privately, without your teammates knowing, you can email me at <vidal@sc.edu>. I will reply within 24 hours.

  3. For voice and video calls we use USC's teams.microsoft.com. Just login using your school credentials: the same as you use for the lab machines. You can then contact me directly to phone/video call. We will also have a Channel for each capstone team.

  4. Check my Office Hours to see if you can drop by my office in Storey 2231. Or email me for an appointment. I will reply within 24 hours.

Teaching Assistants

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 first of a two-semester software engineering 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 is a project class and has no scheduled lectures.

Project teams will be formed at the start of the semester, see team formation section. Each team will be responsible for gathering the product requirements, designing the product, implementing it, and demonstrating that it works as required.

At the end of the semester each person will also be asked to submit a peer evaluation of his or her teammates and assess their contributions to the project.

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.

Team Formation

You will talk to your classmates, use the SCCapstone Discussion (top right) and form a team of 4 or 5 students. All teams must be either 4 or 5 students, no more, no less. No exceptions.

Once you have formed your team, one of the people in the team will fill out the Team Creation form (see schedule), where you tell me your team members and your chosen team/repo name. The team name is also your GitHub repo name so.

If you don't want to form your own team, or if you miss the deadline, you don't have to do anything. I will assign everyone who did not submit the form above to a team. I will create these teams randomly, trying to make them all have 4 or 5 students. This might include adding a person to an already-formed 4-person team.

Grading Scale

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

Item Percentage of Final Grade
Form Teams 2%
Weekly Report 2%
Research 5%
Personas and User Stories 4%
Design 10%
Requirements 10%
Architecture 3%
Source Control 2%
Ethical, Legal, Security Considerations 2%
Proof of Concept 50%
PoC Demo 10%
Personal Contribution up to 100%
Firing a Team member F if you are fired

Most Milestones receive a team grade, meaning everyone in the team receives the same grade. Others are individual, everyone gets an individual grade. Click on each Milestone above to see this and other details about that Milestone.

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.

August

20th Tuesday. Submit your GitHub username form.

September

1st Sunday. Submit your team creation form. If you do not submit the form then I will assign you to a team, by Tuesday.

8th Sunday. Form Teams. Start posting your Weekly Report.

15th Sunday. Personas and User Stories Milestone

29th Sunday. Design Milestone

October

13th Sunday. Requirements Milestone

13th Sunday. Research Milestone

20th Sunday. Architecture Milestone

27th Sunday. Source Control Milestone

November

3rd Sunday. Ethical, Legal, Security Milestone

December

6th Friday. Proof of Concept Milestone

6th Friday. PoC Demo Milestone

9th Monday. Peer Reviews Form

  1. Assessed via Research Milestone and Source Control Milestone. ↩

  2. Assessed via Design Milestones. ↩

  3. Assessed via Requirements Milestone. ↩

  4. Assessed via PoC Demo Milestone. ↩

  5. Assessed via personal contribution. ↩

  6. Assessed via Ethical Milestone. ↩