COP-2939 — Programming Capstone Syllabus

COP-2939 Course syllabus
  Resources  (examples and links)   Instructions for Project Instructions for Case Study  


Spring 2020

Course policies
Time & Place: Ref. No. 36116:  Orientation to be held on Thurssday 5/17/2012 at 4:00 PM, room DTEC-404, or by appointment
Instructor: Name:  Wayne Pollock
E-mail:  Internet:
Office & Phone:  DTEC–404, 253–7213
View my Office Hours.
Skype ID:    
Homepage URL:
Text: John F. Dooley, Software Development, Design and Coding, second edition, © Nov. 27, 2017, by Apress.  ISBN-13 # 978-1-4842-3152-4

HCC bookstore on-line

Please read the entire textbook and refer to it frequently as you develop your project and work on your case study.

Description: (This course is 3 credit hours long.)  “The capstone course is designed for the student to demonstrate his/her knowledge and skills applicable to the degree core competencies and outcomes.  The course is designed as a project-based experience.  The student's project requirements will be designed in concern with his/her area of curriculum emphasis.”

All Students must access the course in Canvas and complete the Week 1 (Module 0) assignments/activities by 8/26/2020.  Failure to show attendance (login to course) and participation (completion of assignments/activities) in the course by this date will result in withdrawal for non-attendance.  A student will lose all tuition and fees paid for a class from which they are withdrawn for non-attendance.  The course orientation will introduce you to the course.

This is a distance learning course.  There are no course meetings scheduled.

This course includes up to three on-line video or telephone meetings during the term, usually via Zoom.  There is also a mandatory demonstration meeting near the end of the term, usually via Zoom.  This course also includes content and communication using Canvas.

Objectives: “Upon successful completion of the course the student will be able to:
  1. Demonstrate proficiency in performing data file activities.
  2. Demonstrate proficiency in performing analysis activities.
  3. Demonstrate proficiency in performing coding activities.”

Upon completion of this course, the student will be able to demonstrate proficiency in designing, developing, testing, and implementing a sophisticated computer program, one that requires substantial programming effort, and that draws on key technical areas covered in previously taken courses.

Prerequisite: Permission of the instructor.  (The student should be ready to graduate.  You must have successfully completed at least 45 hours of college credit, and been approved as eligible to take this course by the dean's office.  Contact the program manager, your instructor, or the dean, for details on enrollment.)  Students enrolled in a degree or college credit certificate program must complete all prerequisites.
Registration Procedure: The course is opened for each student individually, once they've been approved.  First, a student must complete all required coursework.  The capstone should be one of the last courses taken.  When ready to register, contact our program manager, Dr. Hubbard.  He in turn will ask that you contact the A.S. academic adviser, Ms. Livingston, who will need to review your transcript and confirm you are eligible.  The program manager will then increase the maximum enrollment on COP-2939 by one seat (or create the section, if you are the first student this term), so you can then register normally.  You should review this syllabus for COP-2939, especially the sections on the project and case study.  Then you will need to meet with the instructor during office hours in the first week of the term, to discuss the course and your specific project and case study.
Facilities: All assignments can be performed on any computer that includes the appropriate development software and utilities, for the language chosen for each student's project.  These include the HCC open computer lab on Dale Mabry, room DTEC 462.  (This will be discussed at the orientation session.)  Note that some software may be available to enrolled students free of charge, such as Microsoft Visual Studio IDE.

You can use HawkNet (WebAdvisor) to obtain your final grade for the course.  You can use your assigned Hawkmail (Hawkmail365) email address if you wish to discuss your grades via email.  (Note, it may be possible to setup your Hawkmail account to forward all received emails to some outside email account; but you still must send mail from Hawkmail to discuss grades.)

Most college systems use a single sign-on user ID, known as HCC “NetID”.  Visit to register and to update your credentials.  (Your initial password is your uppercase first name initial, lowercase last name initial, and your seven digit student ID number.)  Note, the quickest way to resolve login issues is the HCC Live Web Portal (

The college provides wireless network connections for students and guests on Dale Mabry campus.  For students, select the network “HCC_Wireless” from the list of available networks.  Follow the on-screen steps by entering your HCC email address and network password.  For HCC guests: Select “HCC_Guest” from available networks.  Follow the on-screen steps to complete registration.  This network will be available between 7:00 AM and 10:00 PM.  These are the only official HCC networks; don't use others that may appear.

Hawk Alert text messaging service allows you to receive important information regarding campus closures or emergencies.  You may also sign up for financial aid notifications and registration and payment deadlines.  This is a free service, although some fees may be applied by your cellular service provider or plan for text messages.  To sign up, or for more information, visit

HCC's Student Assistance Program (SAP) offers resources tailored to student life, providing you with the right tools to help you through some of life's toughest challenges.  The college has contracted Baycare Health Management to provide free, professional, confidential counseling by telephone and in person.  A wide range of topics may be addressed through this program, including mental health counseling, budgeting, and financial concerns.  Please call 800-878-5470 or send email to for further information.

HCC DM Open Lab
Computers with all needed software for this course are located in the Open Lab in DTEC 462 (Dale Mabry campus, Technology building, 4th floor).  A maximum of 12 students are allowed in the lab at a time.  Additional help is available via phone, email or other distance means.  Call 813.253.7330 for details.  Lab hours are:

Dale Mabry campus open lab hours
Monday – Thursday8:00 AM to 8:00 PM
Friday 8:00 AM to 4:30 PM
Saturday 8:00 AM to 4:30 PM

(Note:  Lab technicians (“Lab Techs”) are not teaching assistants or tutors, and shouldn't be expected to help you with your coursework.)

Rules for Using HCC Facilities

  1. No food or drinks near computer equipment.
  2. Students bringing their own laptops need to use the wireless network only.  Students cannot disconnect network cables from classroom's computers to connect their personal devices.
  3. Students are not allowed to disconnect monitors or computers to power their personal equipment.
Grading Policy
Project proposal: 30 points
Analysis and Requirements (requirements document): 70 points
Test Matrix (acceptance tests): 50 points
Preliminary (high-level, artitecuture) design: 100 points
Detailed design: 100 points
Unit test suite (and code skeleton): 100 points
Implementation (source code and documentation):  50 points
Final project presentation: 300 points
Case Study (code review): 200 points
Total Points Possible: 1000

Grading scale:  A=90-100,   B=80-89,   C=70-79,   D=64-69,   F=0-63

It is expected that at least 70% of students will successfully pass the project with at least 70% or higher, and that 70% of students will successfully complete the case study with a 70% or higher.  (See Project and Case Study below for more details.)

  • During the orientation period a project, a development language, and a schedule of deliverables will be developed.  This may take several meetings.  In general, the student can pick the development language and tools most familiar to them, and suggest their own project.
  • There are no set meeting times for this course.  Any meetins will be via phone, Zoom, or other remote methods, at a time arranged with the student.
  • The student will submit each deliverable by email prior to the deliverable's due date.  You must submit using Canvas.
  • Students can go to the open computer lab anytime they are open to work or to submit assignments.  Be sure you should leave yourself sufficient time to complete your work.  (So don't show up at 9:50 PM when the lab closes at 10:00 PM!)
  • A student shall not, without my express authorization, make or receive any recording, including but not limited to audio and video recordings, of any class, co-curricular meeting, organizational meeting, or meeting with me.  Further you do not have my permission to post on the web or otherwise distribute my class lectures and other course materials.  (You can distribute freely any materials I make publicly available from the HCC (or the website, without asking permission, provided you give me credit for the work and don't alter it.  Any other use will require expressly given permission.
  • You must abide by the HCC Acceptable Use Policy (AUP) for computers and services.  In particular, you must not run network scanners, or attempt to obtain administrator (“root”) privileges or otherwise disrupt HCC computers and services.
  • You must follow the academic honesty policy and the student code of conduct for HCC.  A second cheating offense will result in an “F” for the course, and your name will be turned over to the dean for further handling.  I take these matters very seriously.  You have been warned!
  • Communications Policy:  I will respond to your emails within 48 hours or two business days.  HCC policy is that grades can only be discussed in person or via email only if you use your assigned HCC HawkNet (Hawkmail365) email account.

    Students wanting help from their instructor during office hours should first send an email.  A follow up can be arranged during office hours for a Microsoft Teams meeting, a Zoom meeting, or by other means.  During office hours, expect quick email responses.

  • If you are having difficulty with some aspect of your project please feel free to ask me about it (well before the due date).  You can send emails of questions and/or your work-in-progress, to receive feedback and suggestions.
  • All discussions and agreements reached between a student and their instructor must be documented, preferably in emails.  It is up to the student to ensure this happens.
  • No appointment is necessary to see your instructor during scheduled, on-campus office hours.  You can just “walk-in”.  You can make appointments for other times as long as I'm available. 
  • Occasionally my office hours will be canceled on short (or no) notice, for example if the dean calls me for a meeting.  Before driving out to campus just for my office hours, you can contact me the night before to make sure I still plan to be there.
  • Late Policies:  Late assignments (projects or exams) generally will not be accepted.  An assignment is late if not turned in by the due date and time agreed to with the student's project schedule.  Don't wait until the last minute to submit an assignment or project; if a problem arises, you may miss the due date.

    Late assignments will be accepted late only if you obtain the instructor's permission prior to the due date of the assignment, or for a documented serious medical reason.  All late assignments are subject to a late penalty of at least one letter grade (10%) regardless of the reason for the delay.

    Work later than one week will receive a more severe late penalty; very late assignments without adequate excuses will receive a grade of F (0).  However if you have a very good reason your instructor may waive any or all of the late penalty.  (Examples of good reasons include extended illness that prevents working, being out of town for work, or military service.  Remember documentation will be required.)

  • The danger of spreading flu or other disease requires some changes to normal policies.  HCC is implementing the recommendations for institutions of higher learning of the CDC.  (See and for guidance from the CDC.)  You won't need documentation if you miss class due to the flu.  (But if you think you have the flu, you should see a doctor as soon as you can.)  In the unlikely event of a school closure due to the flu, some plan to make up the missed work will be made.

    If you think you are sick, stay home.  Do not come to HCC until 48 hours after your fever has broken.  People are infectious to others for a day or so before they have any symptoms.  Flu is spread by touching doorknobs, computer keyboards, railings on stairs, etc., that were touched by someone with the flu.  Avoid shaking hands; use the “fist shake” (touching of fists) if you must use a physical greeting.  The most effective way to prevent catching the flu is to wash your hands frequently, especially after touching something that was touched by others.  Avoid unnecessary touching of eyes, nose and mouth.  While not as good as properly washing hands, hand sanitizers have been installed throughout the campus; use them often.

    HCC Covid-19 Policies — See the HCC COVID Statement for distance learning classes (PDF).

Project: The goal of the capstone project is to demonstrate fluency with the tools of scholarship and professional practice in your field, an ability to independently plan and carry out a non-trivial piece of work, and an ability to present your work in written and oral formats.  The capstone project is expected to require at least 80 hours of effort over 6 to 8 weeks.  (The project should be completable by a single student working about 10-12 hours per week on this course, before the end of the term.)

Each project is different, but all will include a project proposal, detailed requirements, a clear design, unit test framework, and a quality implementation that includes security and safety (as needed, for example to protect personally identifiable information), robust features, best practices, and quality comments.  All projects must include a user interface of some sort.  All projects must include persistent storage (files and/or a database).

The student is expected to pick their own project, which must be approved by the faculty advisor.  If a student selects a topic that requires a substantial technology-related learning curve, (such as learning a new language or operating system, etc.), then that portion of the effort is over and above the effort expected for the capstone project itself.  The project can take many forms, depending on your interests.  It must be educational, have a research component, and relate to your major.  It should also have a clear focus and well-defined success criteria.  You should analyze a problem, research known solutions and products that address the problem, develop a design and a plan, choose some interesting or challenging portion of the problem to implement and test.

Note that a simple CRUD application (that is, a user-interface wrapped around some data) is generally not acceptable as a project.  Example of such unacceptable projects include a program where a user clicks a button or link to view some information such as a zip-code or area-code finder, or an asset tracking system.

Examples of acceptable projects (feel free to use one of these) include:

  • The communication layer of a multi-player network game
  • Parsing National Automated Clearinghouse Association (NACHA) electronic payment files
  • A GUI for database creation and maintenance
  • Implementing a standard game (but should be more complex than “Minesweeper”)
  • A defect tracking system
  • On-line testing system for multiple choice tests
  • Empty Parking Space Detector — A system would detect the location of empty parking spaces and report them to people entering the parking lot.  Various types of sensors could be used to detect the location of empty spaces.  Perhaps video cameras could detect the location of bare pavement.  Some type of display device at the entry of the parking lot would show the locations of empty spaces.  (This could be a cell phone app, one that might have commercial applications!)
  • Music Transcriber/Comparator — A computer program that would take an audio source of music (probably a solo instrument), analyze which notes were played and when, then create a transcription of the song.  Additionally, this could compare a performance to a “correct” performance and give feedback to the musician about what errors were made (wrong notes, wrong times, etc.)
  • Restaurant menu and order smart phone app — The customer can order food and pay their bill right from their phone, so no touching menus, pens, etc., making customers safer.
  • E-medical records management systems.  (You could research standards in this area and implement a patient record management system.)
  • Secure registration system for some website.  (Could be a smart phone app.)  Doing this well is non-trivial and will take some research.
  • A Ticket System for College Football Games — It should set prices based on where you want to sit and applies appropriate discounts for Students,Alumni, Military and Seniors.
  • Office Schedule Visualization Project — Allows the manual entry of employee work schedules.  Program will display the availability in a chart that allows for easy visualization of gaps.  Easily shows where scheduling conflicts may occur, and will even recommend a schedule based on the number of employees, the productivity peaks, and the day of the week.  (At HCC, Faculty office hours are subject to several constraints, so not all schedules are acceptable.  A good program should enforce any constraints.)
  • Personal Medical Management Tool — This application allows for manual storage of medical reminders (cell, text, call, fax, email, ping, etc.) such as for medication refills, appointments, test result availability, medical-related phone numbers, and other pertinent data to a patient's well-being.  When medical services and organization can be difficult, this program allows the patient to stay reminded of important medical times and dates, as well as help inform approved friends or family members when updates are made or if appointments are missed.
  • There may be some problem in your work environment that needs attention, is related to your major, and is of particular interest to you.  Many students choose such projects.  One example is a process for remote collaboration in a geographically dispersed development team.  The project involved interviewing participants, evaluating and choosing tools, installing the tools and developing a process around them, and finally using the new process on an ongoing project.
  • There are many existing open-source projects that need developers.  You could contribute to some Mozilla project (e.g., Firefox), Apache project, Linux project, or any open-source project on GitHub or elsewhere.  Note such a contribution is generally not a complete program, but just a portion of one: a complex issue to resolve, adding a significant feature, refactoring a large but badly designed codebase, etc.

The final project will comprise a functioning original computer software project of significant scope and complexity.  It shall draw upon key technical areas covered in previously taken courses.  Various deliverables (milestones) will be required during the design and development of this project.  These are completely described in each of the assignment directions. 

While object-oriented projects are preferred, you may attempt a non-OO project with your instructor's permission.  The deliverables' directions attempt to cater to both styles of software.

Briefly, these deliverables include:

  1. Project Proposal — The proposal document shall clearly describe the planned final project’s end product.  This document should contain graphics, images, or tables, which can be produced using other applications to clarify your intent.  It must be written using complete English sentences and have been spell- and grammar-checked.  The document must unambiguously describe what the proposed system will do.

    The document must include the following topics: working title of project, purpose of the project, platform (e.g., Windows, Mac, iOS), intended customer/user (that is, who the program is for), source of the idea for the project, development environment and/or tools to be used, development language(s), limitations or risks anticipated, tentitive schedule (built around the course milestones), estimated number of lines of code, documentation, user training and/or user documentation, and a delivery/installation plan.

    The document should also include anything not mentioned above that will be relevant or helpful when evaluating the proposal.  A typical proposal document will be 1-3 pages in length.  Your document should be saved in Microsoft Word format or as a PDF.

  2. Requirements Document — Once the proposal is done and approved, you will submit a detailed and complete written copy of the proposal requirements.  Detailed "use cases" describing all functional requirements.  Any non-functional requirements (such as performance requirements, e.g., response time to a keypress) must be documented as well in this document.  Use cases are often graphical using UML notation, but that is not required.  A typical requirements document will be 5-8 pages in length.  Your document should be saved in Microsoft Word format or as a PDF.
  3. Test Matrix — Once your proposal and requirements documents unambiguously describe everything that your project will do, it is time to produce a test matrix.  Use only the provided Excel spreadsheet to capture all of your system’s testable requirements.  Each row of the spreadsheet will contain one of the system’s requirements; note that some use-cases from the requirements document will become multiple test items here.  For example, if your system is supposed to allow up to ten simultaneous users doing queries, then the requirements would say, “User successfully performs a query" and "Ten simultaneous users”.  Doing this allows you to easily list all of the system’s requirements so that you’ll remember to design and test each one.  The Test Matrix, once approved, will be “frozen” and used during the final demonstration to ensure that each requirement has been adequately fulfilled.  This means test matrix serves as your project's acceptance test suite.  Make sure you include all of your requirements in this matrix.

    Remember that the Test Matrix will be used as a grading tool when you demonstrate your project at the end of the term.  For each item in the list, you must clearly describe what the feature or function does and also clearly describe how it will be tested or verified (will something be measured?  Will a file be checked?  Should something happen within a certain period of time?  Etc.).

  4. Preliminary Design — The preliminary design (also known as the system architecture or the high-level design) document describes the preliminary or top-level design of the system under development.  The document shall be saved in Microsoft Word format or as a PDF.  For non-object-oriented projects, it shall include flowcharts, hierarchy charts, and pseudocode.  It can also include any other graphical or tabular features useful for communicating a software system’s design to a reviewer such as class diagrams.  (UML is encouraged but not required for diagrams.)  Remember that the design of the system relates to its internal structure and architecture (in other words, the design shows how the program is built internally, as well as the parts that users will see.)

    A typical non-object-oriented preliminary design document will be 8+ pages in length and will contain many diagrams and visual depictions.

    For object-oriented designs (OOD), the system architecture is described (such as "MVC", "client-server", "micro-services", "3-tier", and so on.  No pseudocode or flowcharts are needed at this point, however you should document any design decisions made at this time such as which testing framework to use, your persistence choice, etc.  A typical object-oriented preliminary design document will be 2-5 pages in length.

    In both OO and non-OO design, you should describe your intended testing framework, development workflow, and your development/build environment here.  For example, for a Java project you might say “I will be using JUnit for testing, Maven for dependency management, Git for version control, and using  test-driven development workflow.”

  5. Detailed Design — The detailed design expands the preliminary design document.  It shall incorporate any revisions or updates from the preliminary design document feedback.  It shall also describe the detailed design of the system under development.  A detailed design should capture the name, purpose, inputs, outputs, and details of every module/class/method/function that the system will contain (it doesn't contain the code for each of the modules/methods/function; the code comes after the detailed design document.)

    A detailed design document is a comprehensive document that could be used to assign programmers the job of coding individual modules/methods/functions.  The document shall be submitted in Microsoft Word format or as a PDF.  It shall include flowcharts, hierarchy charts, pseudocode and/or any other graphical or tabular features useful for communicating a software system's detailed design to a reviewer.

    A typical non-OO detailed design document will be 10-20 (or more) pages in length and will contain many diagrams and visual depictions.  It must document every package/module/class/method/function that will be in your final implementation.

    For object-oriented development, there is usually no detailed design document!  (The detailed design is developed through test-driven development and won't be known until you've completed a substantial part of the project implementation.)  None-the-less, you are required to submit something for this once you've worked out some of your design choices.  Note if you do not use test-driven development (or some equivalent), you will need to have the same sort of detailed design document as for non-object-oriented projects: class and other diagrams and method pseudocode.

  6. Unit Test Suite (and code skeleton) — In this phase you translate your design into a skeleton program, which typically means a set of classes or modules with functions (depends on your programming language) with stub public methods (methods with a correct signature/prototype and return statement, but no implementation at all).  The skeleton should include comments based on the design.  Building a test database (or test data files) is also part of this phase.

    You will probably need some simple user interface (for example, a PHP web interface) to be able to examine and update your data.  This "scaffolding" code is in addition to your actual project code, as is any testing code and deployment scripts.  Then build and deliver a unit test suite, based on the design and requirements.  You can use any test framework approved by your instructor, but here are recommendations:  For Java, use JUnit.  For C#, VB, or any .net language, use NUnit.  For other languages, find an appropriate testing framework (which you should have your faculty advisor approve).

    Remember, the purpose of the unit tests is to ensure the implementation properly fulfills the design.  You need enough test cases for this.  (At this point, none of your tests are expected to pass.  You work on making each test pass, one at a time, in the implementation and testing phase.

    Note for object-oriented, test-driven development, tests and the detailed design (and the implementation) are all developed at the same time.  Your instructor understands that, but for grading purposes you need to submit a test suite before the implementation is done.  You are allowed to expand your test suite later.

  7. Implementation — After the initial unit tests are built, you enter the major phase of your project, implementation and testing (this is the phase where you write and test your source code and make your unit tests pass).  During this phase, you may decide you need to revise your design.  (You are required to keep your faculty advisor informed as to your progress and to make any design changes.)  You will also likely need to add to your test suite as you implement code.

    If your implementation is complicated, it can be split into two or more milestones, each of which is a deliverable.  During this phase, it is strongly recommended that you use a version control system (VCS) such as Git.  Such tools are often built into IDEs or are available as add-ons.  The deliverable for this phase is a document containing all of your documented source code as well as all of your user documentation (manuals, instruction guide, help files, etc.)  Note every module/package, every class, and every public member (or public function) must contain suitable documentation as comments.  For example, in Java you will use "doc-comments" and run "javadoc" tool to generate final API documentation.  Additional documentation (including user manuals or other help) are also due at this phase.  (It is not expected such additional documentation will be complete or in its final form, but do not ignore documentation!)

  8. Final Project Demo and Presentation — The final project shall include these deliverable components: (a) an executable computer program, (b) a demonstration of that program on the system’s target platform, and (c) a documentation package containing all of the program’s source code as well as the final version of the design documents.  (Remember that the Test Matrix will be used as a grading tool during the demo.)  It shall also contain user or other technical documentation to accompany the program.

    A demonstration of a substantially working computer program is critical for success in this class.  Without a demonstration of a substantially working computer program, the best grade possible in the course is a C.

    The demo is typically via Zoom screen sharing, but other means can be arranged if necessary.  It is up to the student to communicate with their faculty advisor when ready, to schedule the presentation before the end of the term.

Project Evaluation: Each deliverable will be evaluated separately and each will contribute to your overall grade.  Other evaluation criteria include completing deliverables on time.  It is expected that students already know what is expected for each deliverable (such as coding style), but if unsure you should speak with your instructor early enough to be able to succeed.
Case Study: The case study involves a detailed, professional-quality code review of several hundred lines of code.  Students should take some time to find source code (not written by them) they wish to review.  (This is a great opportunity to participate in open source development; You can review some code found on GitHub (or elsewhere), and if you find any improvements, you can submit them as pull-requests.)

Some sites you can search that host open source projects include:

If a student fails to find code on their own to review, then code will be assigned by the instructor, who will try to choose code written in a language familiar to the student.

The student is expected to review the code, noting both positive and negative aspects, of areas such as

  • design,
  • comments (and other documentation),
  • code readability,
  • safety,
  • security,
  • performance,
  • test code,
  • logging,
  • metrics generation, and
  • compliance.

Note all projects will have all of these aspects, but if (for example) logging is missing, and you feel that the code should include logging, you must make note of that in your review.  Likewise, if some objects are added to a collection, make sure those classes are correctly designed, with appropriate methods.  (In Java, that would be equals, hashCode, and toString, as well as correctly implementing all appropriate interfaces such as Comparable or Cloneable.)  Code should be designed with best practices, for the given implementation language.  For example, in most object-oriented languages, you should prefer to create immutable classes when appropriate.

Note each area has several points; for example, code readability includes the use of proper naming conventions (and no names you can't figure out, e.g. “RsFadCtl”), proper use of white-space, appropriately short methods, no commented-out code (that's what revision control systems such as CVS are for), no sign of copy-and-paste, no “magic numbers” in the code (use named constants instead), and so on.  Test code might include unit test suites, implementation testing (e.g., in Java, use of assert statements), etc.  Security includes appropriate testing of method arguments (pre-conditions), not trusting user data directly in an SQL statement, appropriate use of exceptions, correctly accessing files and other external resources, and so on.

Try a Google search for Code Review Checklist or similar searches, for more items to examine in your review.  Several code review links are included in the code review resources.

You will present your review orally, using printouts, handouts, or projections of the code or presentations you create.  This will be done in-person or via Zoom.  Submit your code review notes, before the oral presentation of your code review.

Submitting Assignments: Documentation deliverables should be PDF files when possible.  Make sure your instructor approves alternative formats (such as Visio files) before submitting.  Your code (plain text files) should be included as a zip archive.  (For example, you can simply zip your Visual Studio, Eclipse, or NetBeans project folder and submit that; but make sure it is completely self-contained, as often data sources are created by default elsewhere.)  The code should include project documentation, which must include deployment directions.

All assignments are due on the dates indicated in the course schedule posted in Canvas.  You must submit your assignments using the assignment drop box posted under the Assignments tool.  Assignments must be submitted using a drop box (not emailed) for grade consideration.

You can send questions to , as long as your email doesn't include any zip attachments.  Please use the subject “Programming Capstone Project Question” so I can tell which emails are questions about the project (and not submissions).

Academic Calendar
HCC Academic Calendar:
Classes Begin: Monday  5/14/2012   (first class meeting, the orientation: Thursday 5/17/2012)
Add-Drop Ends: Friday   5/18/2012
Last Day to Withdraw:  Monday  7/9/2012
Classes End: Friday  8/10/2012
Grades Available:  Monday  8/13/2012 (from Florida Virutal Campus (Formerly or HawkNet)
HCC is closed on: Sunday  5/27/2012 (Memorial Day),
Wednesday  7/4/2012 (Independence Day)

Consequences of Dropping or Withdrawing

Dropping or withdrawing may have an impact on financial aid, veteran’s benefits, or international student visa status.  Students are encouraged to consult with a financial aid, the VA certifying official, or the international student advisor, as appropriate, prior to dropping or withdrawing from class.

Requests For Accommodations

Any student whose disability falls within the American Disabilities Act (ADA) and requires accommodations should contact the Office of Services for Students with Disabilities (OSSD).  The OSSD works with students and faculty members to identify reasonable accommodations and academic adjustments.  If you anticipate or experience any barriers to learning in your courses, please discuss your concerns with your instructor and with the OSSD office on your campus to develop an implementation plan together.

We highly encourage you to submit your accommodation requests within the first two weeks of the semester because the accommodations are not applied retroactively.  With that in mind, you are encouraged to seek assistance from the OSSD as soon as possible, and to present any accommodations/academic adjustment letter you receive to your instructor immediately upon receiving it.

Contact information:
Website: Office of Services to Students with Disabilities
Location: Dale Mabry campus: Student Services Building (DSTU) Room 102
Voice phone: (813) 259–6035

You can directly contact Dale Mabry OSSD staff via email: Veronica Lugo at or Ana Barrera at

HCC has a religious observance policy that accommodates the religious observance, practices, and beliefs of students.  Should students need to miss class or postpone examinations and assignments due to religious observances, they must notify their instructor at least one week prior to a religious observance.

If, to participate in this course, you require an accommodation due to a physical disability or learning impairment, you must contact the Office of Services to Students with Disabilities, Dale Mabry campus: Student Services Building (DSTU) Room 102, voice phone: (813) 259–6035,  FAX: (813) 253–7336.

HCC has a religious observance policy that accommodates the religious observance, practices, and beliefs of students.  Should students need to miss class or postpone examinations and assignments due to religious observances, they must notify their instructor at least one week prior to a religious observance.


Quotes on learning
Quotes:         Tell me and I'll listen.
Show me and I'll understand.
Involve me and I'll learn.
    — Lakota Indian saying
        Learning is not a spectator sport!     — Chickering & Gamson



Class Resources
Computer and Programming Overview Background information review     Soft Skills Discusses certifications, job interviewing tips, and required non-technical skills needed to find and keep a job Good site for basic math and algebra tutorials (something all technology workers need to know) Salary and other information on computer programming careers.  (See also Why Choose CSE?.)
Software Engineering Code of Ethics Joint ACM and IEEE code of ethics and professional conduct  (See also BCS Code of Conduct)     SWEBOK 2004 edition The Software Engineering Body Of Knowledge defines what every software engineer should know (design, testing, and similar topics)
ACM (Association for Computing Machinery) Well-recognized professional society with many benefits, especially for students     IEEE Computer Society Also a well-recognized professional society with many benefits
Programming Language Comparisons Describes how to solve a simple problem in a variety of programming languages     ISO 9000 An important standard for quality software development processes, required by many organizations throughout the world.  See also ISO 12207 (which is similar) and ISO 9126
TIOBE programming language popularity index The TIOBE index is based on the number of hits that are returned from the search query “+"<language> programming"” into the Google, Blogger, Wikipedia, YouTube, Baidu, Yahoo, Bing, and Amazon search engines     PYPL PopularitY of Programming Language index Google's PYPL index is based on the relative number of search queries for programming tutorials in each of the languages
Open Source Licenses A comparison, listing, and description of most licenses from Open Source Initiative  See also and, for “at-a-glance” license info     GNU/FSF Open Source License Comparison A comparison of many licenses to the GNU GPL, including the CDDL used by OpenSolaris
Articles on open source licenses from ACM Queue Magazine From the May 2004 Issue:  There's No Such Thing as a Free (Software) Lunch, Is Open Source Right for You?, and Open Source to the Core     FLOSS Chart 1 Compares licenses from free as in beer viewpoint. FLOSS project evaluation; shows codebase statistics, number of contributors, reviews, and other information you can use to compare and evaluate projects (formerly,     FLOSS Chart 2 Compares licenses from free as in freedom viewpoint.
    Oasis Open Standards Certifies some standards as open  (Other sources of open standards include RFCs, ANSI, and ISO)
A Concise Introduction to Free and Open Source Software An overview and history A good resource for copyright and licensing issues  (For example, this Copyright Overview and FAQ)
Five Things Every Software Developer Should Know About Intellectual Property A short overview     Copyright quiz Informative and fun, and includes the answers
User Guide to EULAs A consumer guide from the EFF  (See also this EULA cautionary video)     Copyright Crash Course An overview of copyright and licensing
Git home The Git version control system  (See also the excellent online “Pro Git” book) Easy to use public (or private) Git repository  (See also GitHub for Windows)
Sample Git repo visualization and log A demo showing a small repo that had two branched (which were merged)     Git for beginners: The definitive practical guide A nice collection of how-to information from
Git From the Ground Up (PDF) A short, readable introduction to Git concepts  (See also the Git tutorial man page)     Everyday Git with 20 Commands or so Brief explanations and examples of the most used Git commands
Git Overview YouTube videos (four of them) teaching VCS     GitHub Overview More YouTube videos for GitHub and Git basics
Use Case Tutorial An overview of creating use cases     SRS template and sample (PDF)
As a Word document
A template for requirements docs, designed by the IEEE, with no graphics (downloaded from
Sample Requirements Documentation A sample software requirements specification (SRS document; download from     Sample Requirements Documentation (2) A sample software requirements specification (SRS document  (download from
CRC Cards The original paper describing the CRC design method.  (Another example.)     Object Categories A guide to finding objects
OOD Guide OOA and OOD Study guide     Design Patterns Tutorials, FAQs, and more A large collection of OO tips, techniques, and design patterns     Synopses of Design Patterns A brief description of many OOD patterns The site for UML standards, tutorials, and more     Software Architecture Guide A good overview of the system architecture (high-level) design  (See also Common Software Architectural Patterns)
UML Resource Center - IBM UML tutorials     Dia Free diagramming tool (for UML and a lot more)
Violet UML Editor Originally written by Cay Horstman, this free Java application (a runnable jar file) is an excellent UML diagram editor     ArgoUML Free UML diagramming tool that can produce code from the diagrams.  (Not well maintained, but there is an Eclipse plug-in for it.)
UML Quick Reference (PDF) A excellent reference card showing one each of everything     UML Reference (PDF) A more complete UML reference
CERT Secure Coding Standards Coding standards for many languages, that if followed, eliminate many vulnerabilities     Secure Coding (of the Software Engineering Institute) secure coding home
Top 25 Errors A list of common security-related coding errors, from and        
NASA Software Safety Guidebook (PDF) Software Engineering best practices for safety critical systems     FindBugs Software that analyzes Java source code to find bugs (free/open source software from
SAMATE Reference Dataset (SRD) The SRD, provided by, provides a set of known bugs and flaws for a wide variety of languages, platforms, and compilers.  This allows consumers to evaluate tools and developers to test their methods.     Secure Coding Guidelines for Java Best security coding practices from Oracle  (See also The CERT Oracle Secure Coding Standard for Java, from CERT's SecureCoding site)
Software Engineering (Wikipedia) This article discusses certifications and legal requirements     SWEBOK The Software Engineering Body Of Knowledge defines what every software engineer should know (design, testing, and similar topics)
Professional Software Engineering Exam information (PDF) The NCEES (the National Council of Examiners for Engineering and Surveying) will start exams in 4/2013 for software engineers; some states will require practitioners to hold this license (10 so far)  (Software PE exam study materials are available from the IEEE)     ISO 9000 (Wikipedia) This standard refers to the process of creating software (certified compliance is required for software sold in the European Union)  (For project management the most widely recognized certification is Project Management Professional (PMP))
ISO 12207 (Wikipedia) A popular ISO standard for software lifecycle processes     IEEE computer Society CSDA certification Based on the SEBOK, the Certified Software Development Associate (or follow-up CSDP) certification is currently the best way to prove your competency
Bad design and its consequences Story about Toyota's killer firmware  (See also for other case studies)     Therac-25 The story of the deadly design flaws in hospital radiation equipment
Code review guidelines Good overview, from     Four Ways to a Practical Code Review Describes the process of code reviews
Security code reviews A free online book (PDF) from     Java Code Review Checklist An article from
Code review example A part of a real code review     Peer Code Review Tips Some great tips from IBM Developerworks
Formal code review A YouTube video showing a part of a formal, face-to-face code review     Code Review Checklist for Java (PDF) A good starting point
Testing Overview Review notes on software testing     Test Case Self-Assessment Attempt to generate sufficient test cases for a simple program
Debug Strategy Excellent advice from Patricia Shanahan on debugging     NUnit Testing Framework A good .net unit testing framework, that can be integrated with Visual Studio (using the VS extension VisualNUnit), and supports all .net languages
csUnit Testing Framework Software and tutorials on using csUnit “.net” unit testing software, a lesser alternative to NUnit     cunit Testing Framework
(original version)
Software and tutorials on using cunit C unit testing software.  There are several C language testing frameworks, but if you are new to this, I suggest something simple suc as Cunit.  Development on this seems to have stopped around 2015, but a newer, compatible fork can be found at  (See also some cunit notes and examples I've put together.) Junit Testing     JUnit API Java docs Online JavaDocs for JUnit API JUnit Tutorial A pretty good JUnit Tutorial     JUnit FAQ Almost a complete tutorial
TDD with Python A simple test-driven development with Python tutorial     TDD with Java Some info on test-driven development in Java with JUnit 5 and other tools
TDD walk-through for realistic Java task Using TDD to design and implement Java code that can parse the query-string part of a URL        
Selenium A tool to automate web browsers via scripts (useful for testing web based applications)     Code Coverage Tools Various tools to show how much of your code was covered during Java unit tests
Database Concepts A brief overview of database concepts, and how to use databases in Java; see also this database overview for system administrators which includes a worked example of normalization)     Squirrel SQL Universial SQL client, useful to view, manage, test and build relational databases
I18N (Internationalization Tutorial from Sun) Tutorial on using I18N, Locales, and Resource Bundles     ISO-216 international paper sizes A clear explanation of A4 and other international standard paper sizes
ISO-639 English (and French) language names, and the standard 2 and 3 letter codes     ISO-3166 Country Codes The official list of two and three letter country codes, used in locales
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets Readable post on     Markdown A style of text that can be easily converted to attractive HTML
Text Concepts An overview of text, fonts, encoding, Unicode, and related matters     Credit Card Processing A brief overview of e-commerce payment processing

[Valid RSS]

RSS iconXML iconRSS feed for this page

What is RSS?