CSC-FPX4900 Computer Science Capstone 1 help

What CSC-FPX4900 actually grades

Nothing here is graded on whether the software works, because at this stage the software does not exist. What is graded is whether a reader could hand your document to another developer and get back roughly the system you had in mind. That one test explains every criterion in the guide. A problem worth solving, stated together with the person who has it. Requirements specific enough to check. A design showing how the parts meet. A schedule with dates that account for the weeks you are going to lose. Risks named while there is still time to do something about them. Everything else in the proposal is presentation wrapped around those five.

Requirements are where most proposals shed marks, and the repair is mechanical. A requirement is testable or it is a wish, and the difference between the two is a number and a condition. The system should be fast and easy to use is a wish. On the test set of five thousand records, the first page of search results appears in under 1.5 seconds at the ninety-fifth percentile on the reference laptop, and a first-time user finishes the search task unaided in under two minutes, is a requirement, because both halves can be checked by somebody who has no reason to be generous. Give every functional requirement an identifier so the second capstone can trace a test back to it, and write the non-functional ones to the same standard. Then draw the boundary. A proposal with no list of things it deliberately will not do has described a subject area rather than defined a project.

The remaining criteria measure how honest the plan is. Scope should be arithmetic instead of optimism, and the arithmetic is available to you. A FlexPath billing session runs twelve weeks flat, so eight working hours a week comes to ninety-six hours, and once a third of that is spent on writing, testing, and the documents themselves, the build has around sixty hours left in it. Sixty hours is one useful feature done properly with two supporting ones behind it, and it is not a platform. Risk gets the same treatment, so each entry carries a likelihood, an impact, a response, and the observable event telling you the response is now needed. Legal and ethical review belongs in the body rather than in an appendix, covering the license on every library you plan to use, where any data comes from and whether you are allowed to hold it, and whether the project touches people in ways a review board would want to know about.

How we help in this course

Proposals from us get built backwards from the demonstration. We start by asking what you intend to show a reader at the end of the second capstone, then cut the scope until that demonstration fits the hours you genuinely have, then write the requirements that make the demonstration checkable. The design section names components and interfaces at a level a reader can follow without a diagram tool open, the schedule carries dependencies and slack instead of a row of evenly spaced dates, and the risk register lists responses one person could actually carry out alone. Tell us the idea, the hours, and the tools you already know, and the proposal is written for that combination rather than for an ideal student.

Studio terms hold in the capstone as everywhere else. A document lands within 24 to 48 hours, aimed at the Distinguished descriptors, and revisions stay free until the guide is met. Eight people work the file, and here the heavy lifting falls to the subject writer who shapes the scope and the scoring-guide reviewer who confirms each criterion is answered somewhere a grader will actually look, with research, an APA and originality pass, and an editor closing the chain. Returned faculty comments re-enter the queue at no cost. Because an attempt takes two business days to evaluate, and a proposal sent back for rework delays every deliverable behind it, the read before submission is the one worth paying attention to.

The assessments, one by one

Assessment 1

Assessment 1 in CSC-FPX4900, Computer Science Capstone 1, is usually where the project gets chosen and cut down: a problem worth solving, the person who has it, the cost of leaving it alone, and a boundary saying what this project deliberately will not do. Read the full Assessment 1 manual.

Assessment 2

Assessment 2 in CSC-FPX4900, Computer Science Capstone 1, is usually where intention becomes specification: numbered requirements each carrying the check that would settle it, a design showing how the parts meet, and a rationale saying why this arrangement rather than the obvious alternative. Read the full Assessment 2 manual.

Assessment 3

Assessment 3 in CSC-FPX4900, Computer Science Capstone 1, is usually where the proposal has to prove it is buildable: hours counted against the work described, milestones that admit what depends on what, slack left for the week you are going to lose, and risks named while there is still time to act on them. Read the full Assessment 3 manual.

How to actually write CSC-FPX4900: where to begin

Begin where every other course begins, with the criteria as headings, then run one test on the idea before writing a word of the proposal. Describe the project in a single sentence naming who uses it, what they do with it, and what they get back. If that sentence needs a comma-linked list of features before it makes sense, the scope is still too wide and every later section will inherit the problem. Narrow it until the sentence is short, then build the problem statement around it. A problem statement earns its criterion by containing a person, a current situation, the cost of leaving that situation alone, and a measurable difference the project intends to make.

Then turn the sentence into requirements and give each one an acceptance check on the same line, because those checks are what the second course will spend its weeks proving. A requirement saying the application must let a user export their records becomes useful once it names the format, the volume, and the time allowed, and once it carries the check that will settle it: export ten thousand records to a comma-separated file, open that file, and confirm the row count and three sampled fields match the source. Number them, group them by feature, and mark each as required for the demonstration or desirable if time allows. That priority column is what protects you in week nine when one task turns out to take three times as long as planned, and it is also the evidence a planning criterion is hunting for, since a plan without priorities is a plan assuming nothing will go wrong.

Finish with the two documents that make a proposal look professional rather than hopeful. The schedule breaks the work into pieces no larger than a week, shows what cannot begin until something else ends, and leaves at least one empty week before the deadline, because that empty week is the whole difference between a plan and a wish. The risk register does the same job for what cannot be scheduled. One worked entry sets the pattern: the public interface the project depends on limits callers to sixty requests a minute, likelihood medium, impact high, the response is to cache every reply locally and develop against recorded data so the build never waits on a live service, and the trigger is the first rejected request. Four fields, a line each, and the risk criterion is answered with something you could act on instead of a paragraph about being careful.

Developing the analysis

The argument that decides a capstone proposal is about size, and students usually take the wrong side of it. Ambition feels like the thing a final project ought to demonstrate, so proposals arrive describing a platform with accounts, payments, messaging, and a recommendation feature, and they are read by somebody who has seen hundreds of them and knows exactly how they end. The competing position, which is the one the criteria quietly reward, is that a complete small system outscores an incomplete large one on every row of the guide, because a finished thing can be tested, measured, demonstrated, and honestly reported. Make that argument on the page rather than leaving it implied. Say what you cut, say why you cut it, and say what the reduced version still proves about your capability. A reader watching a student choose scope deliberately reads engineering judgment, and judgment is what the top column has always been describing.

Citations that survive faculty review

A proposal cites four things and most students remember only one. Requirements and process standards supply the document's shape and vocabulary, so the international standard covering requirements engineering and the recognized bodies of project management practice are where the terms requirement, milestone, and risk should come from. Comparable systems get cited as evidence, meaning the existing tools nearest your idea, named with their own documentation, so a criterion about need is answered by showing what already exists and where it falls short. Every library, framework, and dataset you intend to use is named with its version and its license, because a permissive license and a copyleft one create different obligations and a criterion about legal considerations is checking whether you know the difference. Domain sources through the Capella library carry any claim about the people who would use the system. Then put the list into current APA and confirm that every entry has a citation and every citation an entry.

The mistakes that land Basic instead of Distinguished

• A scope that needs a team. Six months of work for four people is graded by one reader who can do the arithmetic.
• Requirements written as adjectives. Intuitive, robust, and scalable cannot be tested and therefore cannot be delivered.
• No out-of-scope list. Without a boundary, everything unfinished reads as a failure instead of a decision.
• A schedule with no slack. One bad week turns an evenly spaced timeline into an apology in the next course.
• Risks with no response. Naming a danger and then doing nothing about it on paper reads as a formality.

CSC-FPX4900 questions students actually ask

How do I choose a project?

Choose the one you can demonstrate in ten minutes at the end. Work backwards from that demonstration and the remaining decisions get easy, because anything that does not appear in those ten minutes becomes a candidate for the out-of-scope list. Prefer a domain you already understand, since a capstone spent learning a new field and a new stack at once tends to deliver neither. Prefer data you can obtain today over data somebody has promised you for later. Then test the idea against your own hours rather than against your enthusiasm, and when the arithmetic says the build is twice the time available, remove a feature instead of assuming a faster week is on its way.

Do I need a real client or a real organization?

Your scoring guide decides, and the assessments in this course usually accept a described stakeholder where no live client is available. What they do not accept is a project with no user at all. If there is no client, write a stakeholder profile with the seriousness you would give a real one: who they are, what they do now, what that currently costs them, and what they would count as success. Fix their acceptance criteria in advance, because a stakeholder invented halfway through will happily agree with whatever you have already built. If you do have a real client, get the requirements in writing early and record the date, since scope agreed verbally in week two turns into a dispute in week ten.

Can I use frameworks and existing libraries?

Yes, and the criteria expect it, because building from nothing is not evidence of skill in a course about delivering a working system. What matters is that the document is honest about the line between what you wrote and what you configured. List the dependencies with their versions and licenses, say what each contributes, and describe your own contribution as whatever remains once they are taken away. If a borrowed or generated fragment ends up in the code, attribute it in the code and in the report. The habit costs nothing now and protects you in the second capstone, where unattributed work stops being a matter of style and becomes an integrity finding.

Keep going