CS 499 | Senior Project

CS 499 - Course Information and Syllabus

Welcome to Senior Project!

This is an exciting time because it represents that you have arrived at the level of completing a major capstone project. This course is designed to be very much an independent, student-driven process. In a nutshell, you decide what you want to learn and build, and then go do it.

The role of the instructor in this course is simply to help mentor you through the project and ensure that you complete what you planned.

There obviously have to be some guidelines in place, but these are designed to be as minimal as possible. This document will outline the steps you need to complete.

Outcomes and Expectations

The outcomes of the senior project course are:

• Learn something new not covered in the curriculum.
• Demonstrate newly learned topic by applying that topic to a completed significant project.
• Present formally on newly learned topic
• Completion and presentation of significant project

You will be expected

• to learn something new, use software principles and foundational course background
• either with your, team project, or company sponsored idea,
• by doing a full semester worth of work in a completed and professionally presented project,
• that is resume worth, using team work, being customer oriented and
• solve an interesting real world problem.

Learn Something New

As a part of your senior project, you are expected to learn a new computer science topic that you don't currently know.

The ability to be a self-reliant learner, where you can learn new concepts without an instructor teaching it to you, or providing a textbook, etc., is a critical outcome of our degree and of the university's mission.

Expectation and Perception:
This is not a free for all class, you will be required to produce full academic, skill, and capability performance. More so than any other class you have taken. This is considered the capstone class of your degree. You are expected to apply the majority of your newly learned skills and knowledge, and in addition learn something new in a produce a workable product at a professional level.

A Significant Project

The expectation is that significant projects:

• SMART Project
• Specific
• Have potential real-world impact. Your project should solve a real-world problem or address a real need. This could range from a service offering to benefit the disabled or underprivileged, or could be a business idea that you would like to further develop after the course, or anywhere in between. But the idea is that it should provide value.
• Measurable
• Workable Tasks: Can the project be broken down in to smaller workable tasks? Can you come up with a schedule and milestones for completing each task. What are the dependencies?
• Achievable
• Team work. Senior projects can, but are not required to, be completed in teams. This allows you to build something larger and more complete than you could on your own.
• Use existing code wherever possible. As in the real world, you should take advantage of any existing libraries or codebases and bring these together to build something more involved than you could if you started from scratch.
• Realistic
• Able to be Completed. This sounds obvious at the beginning, but many students question it at the end. You will set the expectations for what your project requires and be expected to complete it. This means that you figure out a way to push through challenges, whether they be technical or motivational, along the way, and have something you can be proud of in the end.
• Use Software Principles: You need to be able produced software using principles that you have learn and demonstrate that you have learned them.
• Time Oriented
• Require a full semester’s level of effort. Your senior project should require the level of effort of a 3 credit, senior-level CS course. The university recommends spending 2 hours outside of class for every hour in class, or 9 hours per week devoted to a 3 credit course. With that in mind, each team member should plan to work roughly 126 hours on the project (9 hours multiplied by 14 weeks). Please keep in mind that, while we will track hours spent, completing a great project is the goal, not spending lots of time.

At the end of the project you should be able to summarize your project as a STAR story, that you could report at an interview, at a meeting, or at a conference.

• STAR
• Situation
• What is the situation that this project going to be used? What problem does it solve?
• What is the problem that you are solving?
• Task:
• Can you explain the task in regard to a SMART goal?
• Action
• How are you going to overcome risks? What challenges do you think you might face? What challenges are there?
•  
• Results
• What are you expected results?
• What are the lesson learned

General Notes

• Build your portfolio/resume. You project should be something you can put on your resume that will impress prospective employers.
• Prepare for Graduate Degree: Please note that a research-related project/paper can also be significant, and is a great option for students considering graduate school.
• Represent the School & Department: The project should be a reflection of the school and department.

Participate in Weekly SPED Talks

As you are learning about your new computer science topic, you will also have a chance to teach it.

Senior Project Education Discussion ("SPED Talks") are one of the few chances in this course that we all get to interact with one another. These are designed to be short 5 minute "TED Talk" style presentations where you share with one another what you are learning.

Each person in the course will need to present at some point during the semester, and the instructor will facilitate signing up for these, so that roughly 2-3 people present each week. As an exception, if you are unable to make a video presentation, for whatever reason, you should work with the instructor to come up with an alternative way to present.

The following are the guidelines for these presentations:

• They must be short. There is a hard time limit of 5 minutes. This goes very quickly, so you will have to plan diligently to ensure that you can cover the most important components of the topic in that time period. Points will be taken off for talks that are under or over 5 minutes by 30 seconds. (For example a SPED talk that is 4:29 or 5:31 minutes will be mark down, not necessary 4:30 or 5:29.)

• They should focus on the topic you are learning more than your project itself. Your goal with this talk is to educate the other students in the course on the new computer science topic that you are learning about. You can mention your project and how the topic applies, but your talk should be focus on the new topic, so it is more generally applicable.

• They should be professional. While the hope is that you will not have to spend a lot of time preparing these talks, they should still be professional, and not have the appearance of being thrown together last minute.

When you present, you should add a link to your presentation in the appropriate discussion board. Then, you must also upload a link to the assignment submission for it.

On the weeks that you do not present, you should watch each presentation. This can be a valuable experience for you to learn a little bit about a lot of topics that you may interact with during your career. You are encouraged, but not required, to leave comments, or discuss the topics further with others as you have interest.

One of the components in your weekly status report is to share something interesting you learned from that week's SPED talks.

When you sign up for SPED talk, and you have to re-schedule, there will be a penalty, depending on when you reschedule during the semester, based on the instructor’s digression, time window from original scheduled time and availability. For example, instructor can give you 10% if re-scheduled on the week that you scheduled, except for legit reasons (medical issues or work conflicts), not for poor planning, and an additional 5% for each from the original scheduled week. If there are no times available that next week, that is the risk associated with re-scheduling.

The Process

The senior project is designed to be as independent as possible. However, to help the instructor mentor you through the project, there are a certain steps you need to complete along the way.

1. Choose an idea (and potentially teammates)

2. Submit a project proposal

3. Submit a requirements specification

4. Submit weekly status reports

5. Demonstrate project completion

6. Submit a reflection document

The following sections outline each of these steps in detail.

Choosing an idea (and potentially teammates)

The first step in the senior project process is to come up with an idea. The most important qualification for an idea is that the project is something that you are interested in. The best way to doom a project to failure is to choose an idea that you aren't passionate about. Every project will have challenges that arise along the way, but if you're working on something you are intrinsically excited about, it will be much easier to push through the hard times and be successful.

As you start thinking about your focus and potential applications, you are encouraged to be in contact with your instructor to ensure that the ideas you are pursuing will meet the requirements of the course. There is no assignment or official submission process for this "pre-proposal" stage, please feel free to correspond via email, etc. It is recommended to get your main idea pre-approved before completing your formal proposal.

There are few things that you need to conceder also when choosing your idea.

• You will be formally presenting your project either at the CSEE Project Workshop,   BYU-Idaho’s Research and Creative Works Conference (on-campus) or as a video presentation, depending on location. Beware that you need to have a finished project to report on.
• You will also be automatically registered for the Innovation Society’s Challenge, where you will be eligible to win cash prizes
• Start with an Idea Web or Brain Storming session. Start with an idea or question, then use branches to connect the additional related topics to your idea or questions. If the main topic becomes a branch let it.
• Can I use this on my resume? When an employer looks at your resume, they are going to ask about your capstone project. Can you talk about it.
• Contact companies to see if you can do a project, research, white paper, testing, or QA. It might be a way to get your foot in the door.
• Resources:
• Research and Business Development Center
• Applied Learning Projects (ALPS)
• Handshake
• Any aspect of the Software Life cycle can be considered a project. CONOP to Requirements & Design, Testing, QA, Security, to Maintenance.
• Since it is part of the Degree program, your project is considered a part of the Intellectual Property of BYU-Idaho. Please review the school’s policy, especially Section III: subsection D, “shop rights”. If you plan on selling your project to another company, this will be a factor. Plan your project such that you are researching the technologies, that you will use for your future product. Beware all companies have IP agreements, so you need to be aware and training on how to handle your ideas (This class does not cover it).
• Don’t eat the elephant today. Make sure that your project it small enough to fit in to the class. You have equivalent of 3-man week to complete the class, in other words a full-time person working on it for 3 weeks. Break your idea into do able modules, and only work on one of them.

Project Proposal

Your project proposal is your first chance to formally define what you plan to build. It is understood and expected that you do not know everything about your focus or your application at this point, but you should have completed some preliminary research. You will continue to research and define more specific requirements after this point. However, at this stage of the process, you should have a sufficiently clear understanding of the area to know what you want to do.

At this point, you should be able to clearly articulate your focus and your application and give a 30 second elevator pitch to anyone who says, "What are you doing for your senior project?"

The proposal gives you and your instructor a chance to discuss your project in concrete terms and determine that it can be an acceptable project.

The Proposal Document

The project proposal should have the following sections:

1. Project Name
• Having a name for a project is one of the hardest things to come up with, similar to creating a new password. If you can’t come up with a name, give it a code name (a variable name), something you can reference throughout the rest of the document.
2. Group Size / Contact information
• You list yourself, partner and all team members, if applicable).
3. Abstract/Propose
• Provide the purpose of this project, what is the objective.
• Provide a brief summary of your project. A few sentences should suffice since you will provide details below.
4. Background/Prior Knowledge
• What do you already know about the topic, technology, or subject you will be working in. Do you consider your self a Newbie, Beginner, Novice
• Provide information essential to understanding your project. If applicable, this should include:
• Prior work by others - Are you recreating something that has been done before? Are you building on top of others' work?
• Prior work by you - Have you already done things in this area, and you are adding to it?
• Provide information on what foundational course background got you interested in this subject and how you are going to use that information in your project.
• Provide Initial Research: Spend some time looking through the resources that are already available on your project. (i.e. BYU-Idaho Library, Internet)
• Do a Topic Web or Mind Map: Create a map of your idea, to other ideas and related fields. This will help you understand your audience, purpose, related application of the idea, and potentially other used of your idea.
5. Description
• Provide the details of your project. In particular, make sure to include:
• Why? – Reason for buy – Why should the who use it? More important than the what? Facts Tell, Stories Sell. Having a good story as to why you are creating the application is always a seller. It also gives you a starts the profile building of your users. You can’t be the sole user, make an aviator of yourself and use it.
• What?: A Description - In more detail than your abstract, explain what your will project do. What is the solution/features? Does the solution to your problem already exist? If so how is your solution better? Are you re-inventing the wheel? Think of an Info commercial, present your problem, present know solutions and flaws, and convince me why yours is better. What is the real-world impact of your solution? What will prevent them from going back to the old solution or still have the same problems?
• Who?: Target Audience - Describe the intended audience, customer, user of the project. Yes, there is a difference between the customer, who pays for it, and the user, who uses it. What is your primary audience? Who is going to use your solution/program? Are there other markets you could advertise? Will your solution only be in a certain geographic area? community? age range? etc.
• Where? Platform – Where are you going to develop your solution? Where is it going to be used?
• How? Workflow – How will the who use your solution? How will it work?
• When? SMART Goal - When do you know the project is done? When is good enough, or I have a valid product that I can demo. When do I know I am done with one stage of the project and should move on to the next. This is very similar to Achievable for setting SMART Goals
6. Significance
• Referring back to the expectations for significant projects above, explain how/why your project will be significant.
• Is this something that you can put on your resume, and you would feel would impress prospective employers? Then describe what you would put on your resume, not that it would be a good resume filler.
• Note: There is not free version of this solution, this is not a good reason to create your solution, and should not be a factor unless you have an alternate business solution to cover the costs. Many solutions you must pay for, for good reason, they take resources to provide. Yes, software is invisible, and has no substance, but the hardware & energy it runs isn’t. The people supporting the software need to be paid.  There are many different business models that leverage different levels of free. Remember if you got something for free you were not the intended customer.
7. New Computer Science Concepts
• Another critical part of your senior project is that you demonstrate that you have become a self-reliant learner. Please describe the new things you will need to learn to complete this project. These items should be computer science / software engineering topics.
• Your sole reason should not be to learn a language. Especially if you have already taken a class in it. It should be a new aspect of the language not covered in of the previous classes found in the major.
• You should also include a cool new tool, technology, 3rd party software, or programming concept.
8. Interestingness
• Describe why this project is interesting and exciting to you. Senior projects get hard, hit road-blocks, and cause people to want to quit. If you are excited about your project, this will help you push through.
• Thinking that the language, tools or technology is interesting is not a good enough reason *alone* to justify your project. Too many programming projects have failed, prematurely outdated, or stopped being used because the latest shiny technology was used. You also need to mention why you are interested in the problem domain that your solution falls in. This is where you express your why, different than your audience’s why.
9. Tasks and Schedule
• Course Expectation is that this is full semester effort of 126 hours/person. That is 9 hours per week. Please lay out your schedule, in 8-10 hour estimations. If you are working in a group use the following equation; effort = people*126*90%, where 10% is communication effort involved in working with more than 1 person. For example, 2-person group = 2*126*.9 = 226 hours. Show me the total per person and for the group.
• Divide your project into tasks. Try to make these as meaningful as possible and more detailed than "development." For example, for an OCR project, you might have separate tasks for loading an image into the system, identifying the text region, segmenting into characters, etc.

• For each task, list the deadline and estimated number of hours for the task. Your schedule should include submitting the requirements specification as a milestone. Be sure to consider holidays and other events that may impact your schedule. Be realistic!
• Provide the total estimated number of hours to completion.
• You do not have to specially align with a weekly schedule.

• A typical project lifecycle is 10% Research & Development (R&D)/Concepts of Operations(CONOPS), 20% Requirements Analysis, 30% Implementation, and 40% Test and Integration. Please plan accordingly. If you are learning something new, make sure you have allocated enough time for the rest of the project. Testing will take a lot longer than you think it will. If you have already done this good job.
• Is your schedule to aggressive? Do you have more hours than you have time/resources? Are you spending more time for this project than is needed? If you are planning on working more than 20 hours a week per person on this class, you might have to reduce the scope. Also anything over 200 hours/person also might need to be taken look at, which by the way is equivalent to 2-person group. Prove to me that it won’t go over 200 hours/person.
• How are you going to measure your success and progress? This last year, I starting keeping track of my calorie intake using an app I downloaded. I soon realized with in a day or two what I was eating. Because of the awareness, I started making better choices and higher quality foods, because I was now limiting myself to a budget. From those choices, I started changing my behavior.  How does measurement effect quality? I was once told that just by defining and measuring a process you will see a 70-80% improvement.
• What evidence will you provide that the task is complete for that week? How do you know that it is done?
• Please note that this schedule is for your benefit and not something you will be held to for a grade, but rather something we can refer to, to see if we are on schedule or not.

10. Resources

• List resources needed to complete your project. This may include hardware, software licenses, reference material, etc. Specify the estimated cost for each resource.

• Include hardware, software, compliers, books, websites, mentors, events, and videos associated with languages, tools, and software you need for the project.
• Too many projects die before they even get started, because the infrastructure is not in place for the success of the solution. The dependences are not fully explored, and risk analysis is taken. What are your dependencies for success/failure of your project?
• What are the languages do you need to install? What IDE will you use? What platform (Windows, Mac, Web, Servers) are you going to use? Where are you going to develop and test the solution? How are you going to install & deploy the solution?

• This is to help you recognize if there are things you'll need to buy, and if so, if that is feasible for you. In some cases the department may have limited funds to purchase equipment that can be reused for future projects. But recognize that if the department purchases equipment it will stay with the department.

Proof read your proposal. You should not have any of the previous instructions in the proposal. Please make sure that you are not violating copyright, IP, or patent laws.

When is the proposal due?  You should complete your proposal as soon as possible, ideally within the first week or two of the semester.

When complete, submit your proposal to I-Learn for instructor feedback and approval. Then, you will continue in your research and preliminary work to prepare you to submit your requirements specification.

While you are waiting for feedback on your proposal, please continue forward with your project. When changes need to be made, they are almost always clarifications, minor adjustments, or changes to scope, rather than a change to a completely different project.

Requirements Specification

After your proposal is approved, you will know you are on a good path. You should then continue in research and preliminary work until you are prepared to more formally define the requirements of your project.

The requirements should be functional requirements, meaning that you can demonstrate that the requirement is met by seeing it work, not by having to look at code.

For this requirements specification you need to provide a list of "must have" requirements and a list of "would like to have" requirements. To complete your project you will be required to complete all of your "must have" requirements, so please plan accordingly.

Please note that the IEEE standard is overkill for the CS 499 project requirements specification.

For this document, use the provided outline

• Page 1: Title Page: SRS Project Name. Team Members, Description of project
• Section 1: Introduction: Purpose, Scope, Overview, User Profiles, & Workflows – from proposal
• Include what standards you will be following: Coding, Design, Learning Model, Architecture, Quality Assurance Characteristics and Metrics, Legal & Security Risks.
• Section 2a: Requirements
• Remember that requirement have a key word, “shall”, and additional features have the words “could, should”. A requirement is specific to one purpose, and avoids ambiguity. This mean only the word “shall”, not will, must, should, could, or would. There shall not be the word “shall not” in your requirements. You may sub-bullet additional clarification.
• Requirements are written in 3rd person perspective, in relationship to the applications.
• Success Measurement for that requirement (How do you know that is has been done and met?) Knowing when a job is done is just as important as knowing how to verify the job was done correctly. Requirement success is knowing that you have fulfilled the requirement, let the implementer know when to stop programming, it is the stopping point. The verification is how to test if the requirement was done correctly.
• Section 2b: Stretch Requirements
• Stretch goals are requirements, but can use the words: must, will, should, could, would, etc.
• Section 3: Design Overview of the Product.
• Workflow: A workflow is how the user is going to use the software. The user will start off with X, Y, Z inputs, go through Process A, get outputs. Use those outputs for input to Process B, and so on. Typically, you can map requirements to the different phases of the workflow. A schedule is the time order you will be doing to complete your project. Schedules shall not be in the Requirements document.
• Resources: You listed a series of resources in your proposal, how are you going to use them? Where do they fit in your product? How do all the part interconnect? What 3rd party software, packages, and libraries will be involved in the building, operation and delivery of the software. What tiers will it be using (front end, peer-to-peer, client/server, multi-tier, etc.).
• Data at Rest: How are you going to store user information? Both the user’s profile (login, contact, etc.), along with the data they will generate (application data). Will it be a file, database?
• Data on the Wire: How will the information be saved? Transmitted back to a central location? Where will the process take place?
• Data State: Provide a process flow, state flow diagram or some other design diagram. This goes back to the work flow. This is the map of where the data flow through the system.
• HMI/HCI/GUI: Provide a prototype (drawing, pic, etc) of what the user will see while using the application
• Pictures, Diagrams, tables, etc all are very useful.
• Section 4: Verification: How will the requirements be tested.
• Demo: How are you demonstrate that your application works as designed? What data will you use? What steps will verify the requirements?
• Testing: Each requirements needs to be verified. This is more than just restating the requirements as a “To Do” statement.  I.e. “Verify that App shall allow the user to save input”.  Explain how the requirement will be fulfilled, along with criteria defining the range of acceptability. Also if applicable, define when the requirement is not fulfilled.
• Sources/Citation/Resources Links: You must provide links to sources, citations and resources that you are using as part of your specifications.

Note:

• Format: Being able to read specification is a major component. Properly uses of white space, outline, and use of headers is equivalent to HCI/GUI/UX experience you have will applications. The format must be organized and consistent. This include conforming to the instructor’s directions.

?)

Requirements Changes

You should plan to complete your project as you defined it. However, as you get deeper into your research, if you discover that something is not feasible as you had planned for some reason (note: not "a little harder than anticipated"), you may need to re-negotiate items in your proposal and/or requirements document.

To request a requirements change, you should send an email to the instructor with the following:

1. List of previous requirement(s).

2. Explanation of why it is no long appropriate and why this was not identified earlier.

3. List of proposed requirements to be done in lieu of the previous ones.

4. Justification for why this change will not compromise the integrity of the overall project.

Please note that requirements changes are not made to simply make the project easier. Usually they require more work, because they require you to go in a different direction than originally planned. They are, however, necessary when the project has reached an insurmountable hurtle, so that another course of action can be taken.

As with projects in the real-world, you should do all you can to identify and mitigate high priority risks as early as possible. Then, you can make plans to mitigate the risks and adjust accordingly. Also, as with the real-world, other stake holders will be much more understanding and can much more easily adjust plans the earlier in the process this happens. In other words, for this project you can expect the amount of leniency will be much greater earlier in the project. In addition, requirements cannot be changed in the last week of the semester, you should know what is possible long before that point.

Status Reports

Each week you submit a status report to indicate the progress you're making and list your goals for the upcoming week. Students working in teams must individually submit these status reports to discuss their specific contributions and plans.

The purpose of this report is to help you monitor your own progress and to assist the instructor in mentoring.

For status reports, download the CS 499 Status Report template text file. You should fill out the sections of this text file and submit it to I-Learn. It will have you include the following:

1. Project Title

2. Team members (if applicable)
   • You list yourself and all team members, if applicable).
3. Overall status of the project (on-schedule, behind, ahead)
4. Number of hours A) worked that week, B) total to-date on the project, and C) anticipated total hours needed for completion.

   	Week	1	2	3	4	5	6	7	8	9	10	11	12	13	14
   Worked this Week
   	Too much	20	20	20	20	20	20	20	20	20	20	20	20	20	20
   	Ahead	15	15	15	15	15	15	15	15	15	15	15	15	15	15
   	On-Schedule	9	9	9	9	9	9	9	9	9	9	9	9	9	9
   	Behind	5	5	5	5	5	5	5	5	5	5	5	5	5	5
   Total to-Date		9	18	27	36	45	54	63	72	81	90	99	108	117	126
   	Too much	20	40	60	80	100	120	140	160	180	200	220	240	260	280
   	Far Exceeds	15	30	45	60	75	90	105	120	135	150	165	180	195	210
   	Meets Expectation	9	18	27	36	45	54	63	72	81	90	99	108	117	126
   	Needs Improvements (Less than)	5	10	15	20	25	30	35	40	45	50	55	60	65	70
   Anticipated		126	126	126	126	126	126	126	126	126	126	126	126	126	126

5. Accomplishments (since last status report)
   • This should be based off your proposal
   • What tasks have been completed? What milestones?
6. Challenges encountered (since last status report)
   • What are some problems that you didn’t realize, at the beginning of the semester?
   • How have you overcome them?
7. Plans / Goals for the next week
   • Include upcoming tasks, milestones, goals, and deliverables
8. SPED Talk Insight (Briefly describe an insight or something interesting you learned from the SPED talks this week)
   • Talk 1: Insight
   • Talk 2: Insight (if scheduled)
   • Talk 3: Insight (if scheduled)
9. Other comments for the instructor
   • Ask a question to the instructor. He will collect the questions and answers them and post them as announcement.
   • Ask for clarification on class instructions
   • Provide additional information about your project that the instructor might be able to help with.

You should submit a status report each week, even before you have a proposal in place.

The purpose of a status report is to give an update of where you are at a certain point in time. Because of this, it is not helpful to submit missing reports, late. Therefore, late status reports are not accepted. Because individual status reports do not represent a large portion of the grade, missing one will likely not have an impact on the final grade of the course, but a pattern of missing them is a problem.

The instructor will leave feedback on your status reports, and use that as a means to offer suggestions or answer questions. Please make sure to look for this feedback each week in I-Learn.

Project Completion

Before the end of the semester, you need to demonstrate your project to your instructor via a Roadshow, Conference or Video online depending on your location, or online as defined in your proposal and requirements specification.
This means you need to schedule a time to meet with the instructor (e.g., a video call) before the end of the day on the last regular class day of the semester. This leaves the "final exam" days for you to submit your reflection document and for the instructor to finish the paperwork process.

Definition of Done:

If you are on campus, you should be presenting your project at

• CSEE BYU-Idaho’s Research and Creative Works Conference.
• The CSEE Project Roadshow will allow students to present their project to students and businesses. This will be held the 13th week of the semester.
• “The Research & Creative Works Conference provides the event and venue for students to present original research and creative or artistic works for peers and expert judges. Held every semester at BYU-Idaho, the conference provides opportunities for students to network with professionals from a wide variety of backgrounds and skill sets. Our mission is to foster an environment for students to develop and share their creative and academic achievements for their personal progression and the benefit of others.”

If you are online, you should create a video, be expected to answers questions via discussion board.
For all three mediums, Students will be allowed ten minutes to present their projects and three minutes to answer your questions, or as directed by the CSEE R&CW conference.

.

Peer Evaluation for Team Projects (if applicable)

If you completed your project in a team, at the end of the semester, before your meeting with the instructor, please submit a document that discusses each team member's contribution.

First, list the project name and the name of each team member. Then, for yourself and each member of the team include the following:

1. Describe this person's primary responsibilities

2. Describe how well they fulfilled their tasks.

3. Describe how well they communicated with the team.

4. Describe one thing they could have done better.

Then, finally, please assign each team member a score that defines their overall contribution to the team. These scores must have an average of 10, and cannot all be the same. So, for example, you must have at least one 11 and one 9.

Reflection Document

After completing your project, prepare and submit a reflection document covering the following:

1. Briefly describe your project.

2. How did you meet, exceed, or fall short of your original expectations?

3. What changes were made to your project during the process?

4. What were the most important/interesting lessons learned about the new computer science topics you learned about?

5. What were the most important/interesting lessons learned about the project itself?

6. What were the most important/interesting lessons learned about yourself?

7. Final Thoughts

Grading

With the exception of receiving credit for submitting status reports and your SPED talk presentation, this project is graded holistically at the end of the semester.

The university has defined its grading system to be:

• "A" represents outstanding understanding, application, and integration of subject material and extensive evidence of original thinking, skillful use of concepts, and ability to analyze and solve complex problems. Demonstrates diligent application of Learning Model principles, including initiative in serving other students.

• "B" represents considerable/significant understanding, application, and incorporation of the material that would prepare a student to be successful in next level courses, graduate school, or employment. The student participates in the Learning Model as applied in the course.

• "C" represents sufficient understanding of subject matter. The student demonstrates minimal initiative to be prepared for class. Sequenced courses could be attempted, but mastering new materials might prove challenging. The student participates only marginally in the Learning Model.

• "D" represents poor performance and initiative to learn, understand, and apply course materials. Retaking a course or remediation may be necessary to prepare for additional instruction in this subject matter.

• "F" represents failure in the course.

In accordance with these definitions, the senior project will be evaluated holistically according to the following guidelines.

• A - All "must have" requirements are completed and many of the "nice to have" requirements are also in place.

• B - All "must have" requirements are completed.

• C - Some "must have" requirements are not complete but the general idea of the project is in place and the new computer science topics can be demonstrated to some degree.

• D - Minimal evidence of the requirements is demonstrated.

• F - No evidence of the requirements can be demonstrated.

Late proposals or requirements specifications, or limited number of hours for the senior project will reduce the grade from the scale noted.

In addition, regardless of I-Learn grade calculations or credit received from status reports or SPED talks, you must receive at least a C- on the project completion to pass this course.

CS 499-A and 499-B

For those students enrolled in CS 499-A or CS 499-B, rather than completing the project in one semester, the overall process is the same. However the expected deliverables are:

• CS 499-A (2 credits)

• SPED Talk Presentation

• Roughly 84 hours (2/3 of the overall amount)

• Status Updates

• Proposal

• Requirements Specification

• Peer evaluation, if applicable

• CS 499-B (1 credit)

• SPED Talk Presentation

• Roughly 42 hours (1/3 of the overall amount)

• Status Updates

• Project Completion

• Reflection Document

• Peer evaluation, if applicable

Frequently Asked Questions

Can I start on my senior project before I am registered for the course?

Yes! You are encouraged to get started thinking about and even working on your project before you are enrolled in the course.

Please be aware that you must go through the same process of submitting proposals, status reports, etc. If you are not yet enrolled in the course, these should be submitted via email. Once you have an approved proposal, you are should submit status reports via email whenever you have done about 10 hours of work. You must be enrolled in CS 499 during the semester that you complete the project.

Can I use software written by others?

Yes! Your goal is to build on this code to make something significant. This usually means that you are building on top of existing components.

Can my senior project be something I'm doing at work?

If a project for work meets the necessary requirements, it can potentially be used for a senior project. However, it is important that to go through the process of proposal, requirements document, and status reports before undertaking the project.

Can I use something I have previously done for my senior project?

As a matter of policy, previously completed projects, either for work or personal projects, are not eligible for senior project credit. Regardless of what you have done previously, there is still more to learn. The purpose of the senior project is for you to learn something new--so, even if you have done great things in the past, choose something new and interesting to you and see what you can learn.

You are welcome to add onto previous projects, provided the new work will cause you do learn new computer science concepts and be significant.

Can my senior project be something I'm doing for my internship?

Projects done as part of an internship are being counted as part of that course and are not eligible to double count as senior projects.

What are some possibilities topics for my project?

You need to decide what you are interested in, so it will be a meaningful project for you.

Are there some topics I should avoid?

Games. It is hard to impress a potential employer with a game that you have spent 100 hours on, when they will compare it to polished products that have had thousands and thousands of hours of work.

Lessons Learned by Past Students

I didn't submit my requirements document until later in the semester since I didn't want to commit myself to something that seemed a tall order, if not impossible. But I should have just jumped into it and got it done. I feel like, if I had and I could have spent another 50-100 hours on it, I could have had something a little more complex and interesting.

Please recommend the path of Senior Project A & B to all CS/SE students who need to complete a senior project. It is much less stressful to spread it out over 2 semesters.

Accommodations

Brigham Young University-Idaho is committed to providing a working and learning atmosphere that accommodates qualified persons with disabilities. If you have a disability and require accommodations, please contact the Disability Services Office (208) 496-9210. Reasonable academic accommodations are reviewed for all students who have qualified documented disabilities. Services are coordinated with the students and instructor by the Disability Services Office.

Maintaining a Safe Learning Environment

BYU-Idaho prohibits sex discrimination against any participant in its education programs or activities. Prohibited sex discrimination includes incidents of sexual harassment (including sexual violence), dating violence, domestic violence, sexual assault, and stalking (collectively "sexual misconduct").

As an instructor, one of my responsibilities is to help create a safe learning environment for my students and for the campus as a whole. University policy requires that I report all incidents of sexual misconduct that come to my attention. If you encounter sexual misconduct, please contact the Title IX Coordinator at titleix@byui.edu or 208-496-9209. Additional information about sexual misconduct and available resources can be found at www.byui.edu/titleix.

Revision History