|
|||||||||||||||||||
|
Association of Information Technology Professionals The students that compete in the National Collegiate Conference programming competitions are among the best in North America. The mission of the AITP is to provide superior leadership and education in Information Technology. With these two concepts in mind, the Java programming competition problem statement will focus on real-world issues. In addition to the overall National Collegiate Conference general rules and guidelines, student contestants need to keep in mind the following Java competition specific rules and guidelines: To win the competition, you MUST complete as much of the problem statement as possible. Correct output holds the most weight - how much more is subject to the judges’ opinion on the problem statement. The Java competition judging consists of four rounds: Round 1: Round 1 is designed to filter out working solutions from non-working solutions. Judges first run the programs before ever looking at a single line of code. I'll say this again: you MUST complete as much as possible. All of the programs are tested to see if they run. If there are at least three programs that run, all programs that do not run will be set aside. A program is defined as running if it can start, process input, produce output, and terminate gracefully. Each team will be provided a set of test data that can be used to test the program while it is being built. This test data will be used for round 1. The judges will follow an action script to exercise each submitted solution against the test data. To make sure that your program runs, you should use an incremental approach.
Round 2: Round 2 evaluates how well each program handles a set of test data that has been specifically prepared for use by the judges (this set of test data will not be made available to the contestants during the competition). The programs that have correct output (properly process the test data using a prepared action script) are sent to round 3 for closer examination. In the event that none of the programs produces correct output, the most complete programs will be selected. Round 2 evaluates how well each program:
Round 2 is designed to test data input and output functionality.
Round 3: Round 3 evaluates each submitted solution that passed Rounds 1 and 2. Scoring is based on how well each team fulfilled the requirements as set forth on the checklist provided in the contest packet and on Java programming style and technical grounds. Specific items that will contribute to the scoring are: Class Structure – How well each class is constructed internally Class Functionality –- Each class should specialize in one area of functionality Class Collaboration Design – How well the classes work together (A single monolithic class solution is NOT a good idea) Java Object-Oriented Architecture – How well the program conforms to Java OO design standards Java documentation standards – How well the program conforms to industry accepted documentation standards (i.e. JavaDoc, Sun’s Java coding standards, and Scott W. Ambler’s Java Coding Standards). JavaDoc comments provide an easy mechanism to pick up points.
Look and feel – The user interface needs to be intuitive and easy to use (Annoying the judges with an obnoxious user interface is NOT a good idea).
Round 4: The scores for each program will be tallied from all of the judges for rounds 2 and 3. The judges will select the top 20 programs ranked by score and any additional programs deemed to have exceptional merit. These programs will be evaluated jointly by all of the judges for Round 4 scoring. Round 4 scoring will take into account: Problem solving approach – How well the program design was implemented as well as creative technical solutions Professionalism – Does the program represent AITP ideals Impact – Does the program “Wow!” the judges Awards: There will be one 1st place, one 2nd place, and one 3rd place program selected. In the event of a tie, the time-stamp will be used as a tie-breaker. Up to 7 honorable mentions will be recognized. The judges will award honorable mentions based on merit and score ranking. Teams that tie for an honorable mention will share the same honorable mention ranking. The scoring system favors teams that complete the requirements and implement solid technical solutions. Concentrate on building the required functionality first – this is where the most points are earned. The Java contest will recognize up to 7 honorable mention programs. Please note that there is no quota to recognize any honorable mentions – teams that earn honorable mention recognition will have earned it. Pay close attention to the directions. Remember in grade school when you were told to simply put your name on your paper and turn it in without doing the problems? It’s much like that, only we have a reason. With over 80 teams and only three judges, it simply takes too long to delve into everyone's project files looking for team numbers, startup form names, etc. The directions help the judges stay on track and ensure you get your project judged! Contest Packet Each team will be provided a packet with a detailed checklist of specific items that the judges will be looking for. This will help you out greatly in determining where to focus your efforts. Always strive to fulfill as many requirements as possible in the time-frame you're given. Judges use the same checklist for the second round of judging. They also have a second list to judge the programs that make it past the functionality stage. This list concerns expected techniques and unique solutions. Remember, though: you can code the greatest sorting algorithm in the world, but if you don't complete at least as many requirements as the other teams, you'll probably not finish where you expect to. Please, work off your checklist sheet. Finally, please understand that judging is very subjective and never a clear science. Programming is a very creative and iterative process, which no two programmers perform alike. While we have tried to make an objective process to give the fairest chance to everyone, the Judges opinions are final. We do, however, look forward to, and appreciate, any comments that you may have (even the negative ones!). Keep in mind that the judges are taking into account soft issues in addition to the purely technical requirements. Program look and feel, internal documentation, problem solving technique, and attention to detail will play a part in the judging process. Since there is a limited amount of time, the checklist requirement sheet carries the most weight. Spend your time wisely – if you get stuck, work on another requirement. Also, do not waste time trying to create a cool interface; the judges are most interested in your technical implementation. To help student contestants prepare for the contest, a list of topics is provided below. It is important to remember that the items on this list may not be in the actual problem statement (and that items not on the list may be included). The items listed below represent Java topics that a first semester student should have a solid working knowledge of:
In addition to the Java topics listed above, contestants need to know how to build a Java application that can interact with a database (Past problem statements have used Microsoft Access). The previous sentence closely resembles a hint indicating what type of problem statement will likely be given. Just in case anyone reading this did not pick up the previously given hint – expect a problem statement dealing with a database. All problem statements will contain database connectivity, user interface, and application logic components. Typically, only one of these components will be chosen for a particular problem statement due to the limited time available for completing the contest. Contestants will need to be familiar with building all three types of components and be familiar with class collaboration (using multiple classes that are working together to deliver a functional solution). In general, basic SQL and class collaboration skills will be essential to solving the problem statement. The scoring system for the Java contest will be weighted as follows:
Each of these four areas will have scoring criteria that will be used by the judges. Contestants will be provided the requirements criteria. A quantitative scoring system will be relied upon as much as possible to provide a fair basis for the judging. This means that each team is essentially trying to collect points. A subjective bonus score will be used by the judges to award "special merit" points to solutions that exceed expectations; however, this subjective evaluation will always be less than 10% of the quantitative score based on the percentage distribution described above (for example, if the maximum quantitative score was worth 100 points, the maximum subjective score would be 9 points or less). Special merit or "wow" points (because the solution "wows" the judges) are rarely awarded since the implementation and problem solving approach as well as the satisfying requirements have usually taken into account the varying techniques that can be used to solve the problem statement. What you can expect: The Java contest is scheduled for 4 hours and consists of two parts: PART 1 Contest Orientation – 30 minute orientation session The problem statement will be introduced and questions will be addressed. Additionally, a working solution will be shown – do not worry about making your solution look exactly like the working solution, the working solution is designed to provide a look and feel (much like a User-Interface Prototype). If you have any questions, now is the time to ask them. Questions will only be answered during the orientation in order to give each team an equal exposure to the information. Questions concerning the problem statement will not be answered once you have left this room. During the walk from the orientation room to the computer lab talking is prohibited. Do not leave the briefing room until you are specifically told to! Each team will be handed a problem statement packet that contains a floppy disk, team scoring-sheet, the problem statement document, a computer workstation assignment, and a debriefing survey. PART 2 Programming Competition – 3.5 hours The programming competition will take place in the computer lab. Team members may talk to each other, but are not allowed to talk with anyone else (except for contest proctors and support staff). Team members may talk to proctors and support personnel as needed. Each team is required to return the problem statement packet. The packet must contain the floppy disk and the team-scoring sheet. Each team is free to keep the problem statement and any notes that were taken. The debriefing survey should be turned into a proctor. Do not place it into the problem statement packet. When you turn in your survey, you may also pick up a solution to the problem statement. Each problem statement is designed to be solved in approximately 3 hours by an "A" student that has passed a well structured Java course led by an instructor that has a high competency in object-oriented methodology and in Java. Many schools are offering 2 semesters of Java so the contest is designed around multiple problem solving approaches. This means that more advanced approaches will earn more points. However, each team needs to keep in mind that 50% of the quantitative score is based on delivering functionality. Teams are advised to not spend too much time on any single issue since this will tend to hurt their overall score. Solve the basics first - then worry about presentation and look and feel issues. General Information Each team should arrive at the announced location and time for the Java contest. Please arrive early! Each team is allowed to bring the following items with them:
Prohibited items The following items are prohibited and will result in immediate disqualification if found in the contest areas:
CD-ROMs and other media that are enclosed in a book must be removed prior to entering the contest area. Please make sure that all prohibited items are taken care of before you arrive for the contest. Taking photographs Many schools like to take pictures of their teams. In order to accommodate this, while minimizing any distraction to the contest participants, the following policy has been adopted: If you want to take photographs, each team will be allowed to have one person not participating in the contest take pictures at two specific times: 1. Briefing Room - When the contestants enter the briefing room, pictures may be taken during the first 5 minutes. All people not associated with the contest must leave prior to the contest packets being opened. 2. Contest Room – When the contestants enter the actual contest room and sit at their assigned workstation, pictures may be taken during the first five minutes. All people not associated with the contest must leave after this time. Pictures may be taken provided that the following three conditions are met:
During the contest, the following situations often arise: Toilet Breaks: If a contestant needs to use the toilet, they need to let a proctor know. The proctor will arrange an escort. Only one student may use the toilet facilities at one time. Talking is not permitted. Water Breaks: If the facility will not allow for water bottles to be brought into the computer lab, we will set up a water bottle and cups outside. If water bottles are allowed inside the computer labs, they must not leak. Talking is not permitted. Computer Malfunction: If a computer malfunctions, contact a proctor immediately (The support team will either attempt to fix the problem or find a replacement computer). If the time allocated for the contest has expired and you experience a computer problem, contact a proctor immediately – we do not want a technical problem to cause a team to lose points or be disqualified (make sure that you do not touch the mouse or keyboard once the time limit has expired). Time remaining announcements will be made at 15-minutes and 5-minutes prior to the contest expiration time. In the event that a serious technical problem occurs, please make sure that the Java Contest Coordinator is notified – you should make sure that this notification takes place before you leave the lab. Questions: Any questions concerning the problem statement must be answered during the orientation. Once you are in the computer lab, no questions concerning the problem statement will be answered. The purpose for the orientation is to make sure that all of the teams get the same (and equal) information. This policy has been adapted since answering one team’s question could provide an unfair advantage if all of the other teams do not get the answer as well. Remember, the problem statement has already been tested and solved.
Source Code: The source code solution for the top three teams will be posted on the Internet. The source code solution example and problem statement will also be posted on the Internet. If there were any additional notable mentions, the judges may decide to post these as well. This information will be posted shortly after the conclusion to the National Collegiate Conference at a web site to be announced (http://www.auldenfire.com). Contest Debriefing A contest debriefing will take place following the award ceremony. All participating teams, faculty, and conference attendees are invited to the debriefing. Each of the placing teams and honorable mention teams will have an opportunity to talk with the Java Contest Coordinator to get feedback on how their solution was evaluated. Teams that would like immediate feedback are invited to bring a floppy disk to get a copy of the judging notes. If you have specific questions, please contact the AITP NCC Java contest coordinator: Don Baldwin AITP National Collegiate Conference Competition General Rules:
Official AITP NCC Competition Event Rules and Procedures The official contest rules are available here.
|
|||||||||||||||||||
|
|
|
||||||||||||||||||
| Copyright © 2001 - 2007 Aurenav LLC - e-mail: info@auldenfire.com | |||||||||||||||||||