|
|
|
General Information | Resources | Weekly Schedule | Credits | Lecture Notes | Example Code | Read-Only Board |
I. General Information |
Instructor:Dr. Yoonsuck Choe |
TA:Noah Larsen |
Peer teacher:Grant Uland |
This class is intended for students who have completed CSCE 314 - Programming Languages, and are concurrently taking CSCE 313 - Intro to Computer Systems. It is meant to be somewhat of a "capstone" course for the lower-level computer science courses, before taking courses in the upper-level tracks.
MTWRF 2:00pm–3:35pm, HRBB 126The course is listed as 2-credit lecture, and 2-credit lab, however it has been intentionally scheduled for 3-credit per week of lecture (as well as the lab). A normal load during a 5-week course during the summer is 1:15 hours per lecture, 5 days a week. To adjust for the course load, the following schedule will be used:
- First three weeks: We will meet every day of the week (5 days - memorial day holiday = 4 days).
- Fourth week: We will meet MWF, 2:00pm-3:35pm.
- Fifth week: There will no lectures. Labs will meet on the regular schedule.
- This gives roughly (actually a bit more than) 2/3 of the full 3-credit hour load.
Final exam period will be used for project presentation.
MTWR 4:00pm–5:20pm, RDMC 111C.Due to similar reasons, the lab will meet MTWR, but the time reduced to 1 hour 15 minutes per day to adjust for the credit hour. You can use the remaining time for team activity.
This course is intended as an intensive programming experience that integrates core concepts in Computer Science and familiarizes students with a variety of programming/development tools and techniques. Students will primarily work in small teams on a couple-of-week-long projects emphasizing different specializations within computer science. The course focuses on honing good programming techniques to ease code integration, reuse, and clarity.The primary goal for this class is to have students emerge with strong programming skills, able to address both individual and team programming challenges competently. The class is meant to allow students to improve their programming skills through significant practice.
The expected accomplishments of the students are as follows:
- Become a confident software developer experienced in the full software development cycle.
- Become a capable and effective member in a small software development team.
- Become an effective communicator within the context of software projects.
The students who take this course should be able to demonstrate the following upon the completion of this course.
- Knowledge of programming and debugging tools.
- Knowledge of various programming paradigms.
- Ability to design and refine large software systems based on rough system requirements.
- Ability to implement and test software system design.
- Ability to work as a member of a software project development team.
- Knowledge of various software development paradigms.
- Ability to manage software development projects.
- Ability to write technical documentation regarding software systems.
- Ability to communicate the overall design and details of software systems.
- Introductory-level knowledge in database systems, artificial intelligence, and software engineering.
We will be using the following textbook:Other books that may be drawn from, and that might be useful references include both the first edition of Code Complete, as well as:
- Code Complete, 2nd edition, by Steve McConnell, Microsoft Press, 2004.
Book web page
- The Practice of Programming, by Brian W. Kernighan and Rob Pike, Addison Wesley, 1999.
- Code Craft, by Pete Goodliffe, No Starch, 2007. (Note: this book is available to read online for free through TAMU).
Among the topics to be covered in lecture periods are:Though many topics will overlap, this course is not intended to be as in-depth or comprehensive as a standard software engineering course, which focuses more on project management - students may take the software engineering class after taking this class.
- Style considerations in writing code
- Design of software sytems and APIs
- Coding beyond the single component
- Basic collaborative software coding practices
- Design for portability, performance, testability
- Specification and documentation
- Basic software tools and their use
- Object oriented design
- Design patterns
- Testing
- Subject-specific topics related to the team projects
Note: You should expect to spend a significant amount of time (>20 hours/week) outside of class time on programming projects. This may require meeting with team members outside of the class/lab periods. Note that during the regular semester, each project runs for one month. Although the scope of the projects will be scaled down, you still need to complete each project within 2 weeks or so, so your absolute committment to this course is mandatory.
See the Weekly Schedule section for more details.
There will be three major projects in the course, each counting for 28% of the overall grade. Specific grading practices for each project will be announced when that project is given out, but the grade may include factors such as evaluation of code clarity, teamwork, etc. Peer evaluation may be used as a significant contributing factor to these grades. The remaining 16% of the grade will be an individual grade based on individual exercises, quizzes, participation in the course survey, and an evaluation of class participation (which might include participation in code reviews).The 16% of the grade will start off as being based totally on instructor judgement of class participation and effort. As the course progresses, any quizzes given out, individual assignments given out, or other specific graded material will note the portion of this individual grade which that quiz/assignment/etc. affects. The remainder of the individual grade will be based on the subjective class participation and effort grade. For example, if there are 8 quizzes at 1% each, one individual assignment at 4%, and participating in the course evaluation is 2%, then the remaining 2% is based on the subjective evaluation.
The grading scale expected to be used is A (>=90%) B (>=80%) C (>=70%) D (>=60%) F(<60%).
AGGIE HONOR CODE: An Aggie does not lie, cheat, or steal or tolerate those who do.Upon accepting admission to Texas A&M University, a student immediately assumes a commitment to uphold the Honor Code, to accept responsibility for learning, and to follow the philosophy and rules of the Honor System. Students will be required to state their commitment on examinations, research papers, and other academic work. Ignorance of the rules does not exclude any member of the TAMU community from the requirements or the processes of the Honor System.
For additional information please visit: http://www.tamu.edu/aggiehonor/
For this class, certain aspects of the honor code need to be clarified.
If there are any questions or concerns about whether an action is appropriate, you should check with the professor or teaching assistant first. If in doubt, assume that it is not appropriate.
- There may be times in this course where you or your team make use of external code/software/libraries. Whenever this is done, you must make sure that, in addition to following any restrictions on that code itself, you clearly document what the source of the external code was, and how it was used.
- There may be cases in this course where you or your team seeks outside assistance related to one of the projects. Any assistance received from people other than members of your team, the professor, teaching assistant, or peer teacher needs to be clearly documented.
- You will be working in team environments in this course, and your work as a team will be used to determine grades. As such, it is your responsibility, when asked, to:
- accurately describe the work that you have done on a team project. Claiming credit for work that you have not done or that others did instead is a violation of the code.
- accurately describe (to the best of your knowledge) the performance of other team members. "Covering" for another team member (claiming they did more work than you know they did) or "spiking" them (claiming they did less work than you know they did) are examples of honor code violations.
- prevent (as best you can) or report (known) violations of the honor code by your other team members. You share responsibility when a project is turned in; if you are aware of a teammate having violated the code in his/her work on the project, and do not report it, you are claiming credit for that violation yourself.
- Attendance: Attendance is mandatory in the course, and may be recorded in both lectures and labs. 16% of the course grade will be based on individual evaluation of assignments and class participation, and repeated absences may negatively affect the grade. In addition, students might miss quizzes, which will not be made up without prior approval. Students with absences should notify the instructor ahead of time about any planned missed classes or labs. Unapproved absences may result in a lower course grade (2% penalty per violation).
- Late Submissions: Each project will have a specified date and time at which it is due, and dates and times for which various intermediate parts of the project are due. Projects that are turned in late will have a penalty applied to the overall project grade, which will affect the grade given on that project for all team members (if individual reports are late, those will affect only the grade for that team member). Per minute penalty will apply, equivalent to 1% (of max score) per hour. So, if you're late by 24 hours, 24% will be subtracted from your grade for that late submission.
- Quizzes: The instructor may give out small quizzes online to ensure that students are continuing to follow course material. Any quizzes will be short and simple, related to recent course discussions or reading assignments. Quizzes will affect only the 16% "individual" grade portion on the class. Makeup quizzes will not be offered without prior approval.
- Communication: A class web page (this web page) will be maintained throughout the semester. Students are responsible for checking both the web page and email (your official neo email) regularly for class updates.
- Code Documentation: A key part of this class is understanding the importance of clear code construction and documentation. So, when assignments are graded, a significant portion of the grade may be based on an evaluation of how well the code is written, and how easy it is to follow. Just producing code that "works" is not sufficient; it will be your responsibility to produce code that the grader can follow.
The Americans with Disabilities Act (ADA) is a federal anti-discrimination statute that provides comprehensive civil rights protection for persons with disabilities. Among other things, this legislation requires that all students with disabilities be guaranteed a learning environment that provides for reasonable accommodation of their disabilities. If you believe you have a disability requiring an accommodation, please contact the Department of Student Life, Services for Students with Disabilities, in Cain Hall or call 845-1637.
II. Resources |
III. Weekly Schedule and Class Notes |
|
|
|||||
1 | 6/2 | Introduction; Project 1: Database ; [Reading: Chapter 1 and 3, 9.1 and 9.2] | Project 1 design | Project 1 announced | slide01 slide02 slide03 |
|
1 | 6/3 | API design; Software Design Principles | Setting up GIT; Project 1 Basic parsing [Reading: Chapter 23] |
slide07 slide08 |
||
1 | 6/4 | Project 1: SQL; DB implementation | Unit testing; Project 1 table storage, table formatting; |
Project 1 design docs due | slide04 slide05 slide06 |
|
1 | 6/5 | Testing; Test-Driven Development | Naming/Style/Commenting; IDE, Debugger [Reading: Chapter 11.1, 11.2, 31]; |
slide09 slide10 lab01 lab02 lab03 |
||
1 | 6/6 | Debugging; Software Design Approaches [Reading: Chapter 5.1, 5.2, 5.3, 8.1, 8.2, 8.3] | --- | slide11 slide12 |
||
2 | 6/9 | Agile Development | Project 1 status check | Project 1 parser code due | slide13
|
|
2 | 6/10 | Project 2: Introduction to AI | Project 1 status check | slide14 slide15 |
||
2 | 6/11 | Project 2: Game search | Project 1 status check | slide15
|
||
2 | 6/12 | Project 2: Network protocols and Socket programming (Socket programming slides are by Jon A. Solworth at UIC) | Project 2 design preview | solworth-sockets
|
||
2 | 6/13 | Machine Learning; Advanced AI: Neuroevolution; [General Reading: Chapter 6.1–6.4] | --- | Project 2 announced | Project 1 DB core function code due | slide16 slide16-ml |
3 | 6/16 | Collaborative Software Development; Design patterns [Reading: Chapter 21] |
Makefile; gcc, gdb |
Project 1 final version due | slide17 slide18 |
|
3 | 6/17 | Code portability; Code performance; Code tuning [Reading: Chapter 24, 25, 26] | Project 2: Socket library | slide19 slide20 slide21 |
||
3 | 6/18 | Project 3: Intro to Android development (slides are from Dr. Jaerock Kwon @ Kettering University, former student, TAMU CSE) | Project 2 AI game-search | Project 2 design docs due | kwon-android01 kwon-android02 |
|
3 | 6/19 | Project 3: Android development (cont'd); XML | Android SDK installation and usage | kwon-android03 slide22 |
||
3 | 6/20 | SOLID principles; Web-programming case study |
--- | slide23 slide24 |
||
4 | 6/23 | --- | Project 2 client-server (use of telnet)@ | Project 2 game mechanics code due | ||
4 | 6/24 | Project 1 |
Android SDK IDE; Project 2 client-server code |
|||
4 | 6/25 | Project 2 code review |
Android SDK: User Interface; Project 2 status check |
|||
4 | 6/26 | Project 3 announcement | Android SDK: graphics; Project 2 status check |
|||
4 | 6/27 | --- | --- | Project 3 announced | Project 2 AI code due | |
5 | 6/30 | --- | Project 3 status check | Project 2 final version due (includes client-server) | ||
5 | 7/1 | --- | Project 3 status check | |||
5 | 7/2 | --- | Project 3 status check | Project 3 design docs due | ||
5 | 7/3 | --- (last day of class for 1st term) | Project 3 status check | |||
5 | 7/4 | --- | --- | Project 3 user interface code due |
||
6 | 7/7 | Final: Project presentation 3:30--5:30pm, HRBB | --- | Project 3 final version due |
IV. Credits |
Most of the course content and lecture slides were originally developed by Prof. John Keyser. Thanks to Long Mai and Allen Hurst at Improving Enterprises for valuable feedback.