代写iterations程序作业、代做Java实验程序

Final Project ~ Fall 2019

Introduction

Your final project will be your focus for the majority of the semester. You will be working with a

team on your own project, developing it over three iterations, each of which will produce an

executable release.

Team formation

You will form your own teams. I strongly recommend that you form teams primarily based

around the times you are available, and secondarily around shared interests. We will form

teams as shown in the course calendar. However, you are welcome to begin discussing the final

project at any time.

Pitch

Each team will give a project pitch to the class as shown on the course calendar. It is recommended

that you review the pitch requirements with the instructor prior to your pitch. The presentation

may be at most five minutes long. Slides are optional, and handouts are encouraged. The

pitch must satisfy the following requirements.

• Share a project summary—one or two sentences that succinctly and accurately describe

the endeavor. Note: Non-trivial games are strongly discouraged due to the fact that they

are deceptively difficult.

• Identify the target audience for the proposed project and the need that it addresses.

Depending on your application, you might need to consider factors such as age, gender,

education level, interests/hobbies, native language, and access to technology. This

identification must be specific enough to allow you to test your project with representatives

from the target audience. For example, “students” is too broad as it includes an enormous

variety of ages and cultures. “Non-traditional students at Ball State University” is a more

reasonable target, since you can unambiguously identify individuals for focus group

discussion or acceptance testing.

• Briefly describe one to three key features of your proposed project.

• State the technology you propose to use to complete this project. Java and IntelliJ IDEA

are strongly recommended but not required; using the object-oriented paradigm and

GitHub are required.

• State the platform on which you will release your product. Desktop applications on the

Java platform are strongly recommended but not required. Attempting to support multiple

platforms is strongly discouraged.

• If the project has a user-interface, provide a sketch or mock-up of it. If not, provide

examples of the use case for your project, such as sample API calls for a library or Web

service.

Pitches will be evaluated using the following rubric.

Requirement Satisfactory (3) Probationary (2) Unsatisfactory (1) Unaddressed (0)

Summary statement

Target audience & need

Key features

Development &

deployment platforms

UI sketch or use case

A team must repeat their pitch if they earn 0 or 1 point in any category or if total points is less than

1. Revised pitches will be scheduled for the next possible class meeting.

Schedule

The project is divided into three iterations, each of which will be a few weeks long, as shown on

the course calendar. During each iteration you will create an increment of your project. Increments

are due before the beginning of class on the day that ends an iteration. See the course schedule for

these specific dates. You will submit these iterations via instructions provided in Canvas.

Project requirements

Technical requirements

• Each project is to be developed by a team of three or four students from the course section,

using an object-oriented approach and following the conventions for your chosen language.

• Your software architecture must separate model from view, as well as the persistence layer

if you have one. This should be done using a domain model—an object-oriented

representation of the concepts and relationships manifest in your problem domain.

• You must follow the principles of Clean Code, including structural principles (such as OOP

and SRP) and process principles (such as TDD and the Boy Scout Rule), although strictly

view-level code does not require automated tests.

• All project dependencies that are not part of the development platform must be either

tracked in the version control system (such as in a lib folder) or automatically resolved

using a dependency management system such as Maven or Gradle.

• All projects will be hosted within the class' organization on GitHub. Each will have a

README.md file in the root of the repository that lists the team members and any special

build or execution instructions.

• Your production code should be in the default repository branch, which is called master.

• Each iteration should produce an executable release, also known as a potentially-shippable

product. That is, your increment should be a usable, stable software system that implements

a subset of your product backlog. The three releases will be tagged using semantic

versioning as 0.1.0, 0.2.0, and 0.3.0, respectively.

• Representatives of the target demographic (who are not also on the project team) must test

each increment. This practice constitutes acceptance testing, and it is done by giving testers

specific tasks to accomplish using your system and observing their interaction with your

system. The tasks should come from your user stories.

Presentation requirements

Iteration review presentations will occur during the class periods at the end of an iteration. Each

review may be no more than ten minutes long and must address the following.

• Demonstrate the executable release.

• Describe the user stories that were completed and any changes that have been made to the

product backlog.

• If this is not the final iteration presentation, indicate which user stories will be

accomplished during the upcoming iteration.

• Describe a critical component of your system that was developed during the previous

iteration. This is an opportunity to share something interesting with your classmates outside

your team. You are expected to show and describe the implementation of this component.

• Summarize the results of acceptance testing.

Individual reflection essay requirements

At the end of each iteration, each team member will write a 300 to 600-word reflective essay on

the previous weeks covering this iteration. This essay should draw upon experiences from the

past iteration to directly and explicitly address one of the course's essential questions. You will

submit these essays confidentially in Canvas; they are not shared within the community, unlike

many of our other artifacts this semester.

Formal Evaluation

You will receive a grade for each of the three iterations of this project. Your grade for a given

iteration is the minimum of two iteration component grades: project, presentation, and individual

reflection essay grade and contribution grade. These two iteration component grades are

described below.

Project, presentation, and individual reflection essay grade

The evaluation for the project, presentation, and individual reflection essay takes place at two

levels of granularity. Your grade is the minimum of Step 1 and Step 2 as described below.

Step 1

The overall project system configuration is evaluated, along with your team’s presentation and

your individual reflection essay, in order to determine a maximum grade, using the following

specifications.

Maximum

Grade Project system configuration criteria

A

Project can be built without warnings or errors, and the rationale for any

suppressed warnings is clearly documented in the source code or README file.

Needed build instructions are provided in a README file. Contains unit tests for

all testable code of the model level.

B

Project contains compiler warnings, suppressed warnings are undocumented or

unjustified, or needed build instructions are not provided in a README file.

Contains unit tests for most testable code of the model level.

C Project can be built. Contains failing unit tests or few unit tests of the model level.

D

Project crashes during routine execution or contains no unit tests of the model

level.

Individual reflection essays will be evaluated holistically according to how clearly you connect

your experiences to the course's essential questions, and the quality of your writing, as described

above.

Presentation quality considers the quality of the presentation itself, based on evidence of having

met the criteria as described above for the following items:

• demonstration of project

• completed user stories

• product backlog

• critical component description

• acceptance testing results

Your maximum grade will be reduced by one letter grade if any of the following are true.

• You do not submit an individual reflection essay in a timely manner

• Your team satisfactorily completes three or fewer of the presentation items

• You submit an unsatisfactory individual reflection essay and your team satisfactorily

completes four or fewer of the presentation items

Step 2

The project source code will be evaluated following criteria from Robert C. Martin's Clean

Code. Keep in mind that Chapter 17 provides a valuable checklist. I also strongly encourage you

to use the Project Checklist provided in Canvas. The individual criteria for source code evaluation

(and their corresponding chapters in Clean Code) are:

• Meaningful Names (Ch. 2)

• Functions (Ch. 3)

• Comments (Ch. 4)

• Formatting (Ch. 5)

• Error Handling (Ch. 7)

• Unit Tests (Ch. 9)

• Classes (Ch. 10)

While I believe the big ideas of Clean Code and Test-Driven Development are holistic and

should be considered together, I also believe a finer granularity is appropriate when evaluation is

resulting in a grade. As such, I have itemized pieces below in the grade specifications.

If your submission includes or does all the following, you will receive a D or better for the

project source code grade. If all the specifications listed for a D are not met, you will receive

an F.

1. Submission will compile, run, and accurately satisfy more conditions of satisfaction of

the user stories than the previous iteration.

1. At least three of the following Clean Code/Test-Driven Development criteria (as

described above) are fully met:

a. Meaningful Names

b. Functions

c. Comments

d. Formatting

e. Error Handling

f. Unit Tests

g. Classes

1. At least three of the following technical requirements (as described above) are fully met:

a. Software architecture separates model from view

b. Project dependencies are tracked or automatically resolved

c. Project is hosted within the course’s organization on GitHub

d. README.md file with appropriate content exists

e. Production code is in the master repository branch

f. Release tagged as 0.1.0, 0.2.0, or 0.3.0, as appropriate

1. At least two commits were made since the last iteration, and the commits were pushed to

the course’s organization on GitHub.

If your submission includes or does all the following, you will receive a C or better for the

project source code grade.

1. All items listed above for a grade of D.
2. Submission will accurately satisfy at least one more user story than the previous iteration.

Additionally, a User Story document exists (in the team’s project folder in the course

Google drive) which documents User Story Names (USN) and their related Conditions of

Satisfaction (CoS). The status of each USN and COS should be indicated in some fashion,

e.g. with a completion date, or release number.

1. At least four of the Clean Code/Test-Driven Development criteria listed for a grade of D

are fully met.

1. At least four of the technical requirements listed for a grade of D are fully met.

If your submission includes or does all the following, you will receive a B or better for the

project source code grade.

1. All items listed above for a grade of C.
2. A few commits were made by many developers since the last iteration, and the commits

were pushed to the course’s organization on GitHub in a timely manner.

1. At least five of the Clean Code/Test-Driven Development criteria listed for a grade of D

are fully met.

1. At least five of the technical requirements listed for a grade of D are fully met.

If your submission includes or does all the following, you will receive an A for the project

source code grade.

1. All items listed above for a grade of B.
2. Many commits were made by the majority of developers since the last iteration, and the

commits were pushed to the course’s organization on GitHub in a timely manner.

1. Submission will accurately satisfy at least two more user stories than the previous

iteration.

1. At least six of the Clean Code/Test-Driven Development criteria listed for a grade of D

are fully met.

Contribution grade

Within twelve hours of your group’s presentation, you must conduct a rubric-based self- and peerevaluation

for each member in your group—including yourself, using the following rubric. A link

to an online form is provided in Canvas. If you do not complete this self- and peer-evaluation

within twelve hours of your presentation, I will reduce the number of requirements you complete

by one, which will result in a lower grade.

Requirement To satisfactorily complete a requirement, all listed items must be met

Commitment

Attended all scheduled group meetings (including group work times

during class) or notified the group in advance of absence. Absence(s) did

not significantly hinder the success of the group.

Participation Contributed to planning, research, implementation, testing, and

presentation.

Communication Clear, timely and accurate reports on what has been accomplished, what

is in progress, and what stands in the way, thereby facilitating progress.

Technical

contributions High quality technical contributions that facilitate success of the group.

Attitude and

Leadership

Listens to, shares with, and supports efforts of others, and actively tries to

keep the group together.

If more than half of your group members’ responses for a given requirement, including your selfevaluation,

are satisfactory, then you complete that requirement. Your contribution grade is

determined by the number of requirements you satisfactorily complete, based on the following

criteria.

Grade earned A B C D F

Number of satisfactorily completed requirements 5 4 3 2 1 or 0

Last revised: 08/14/2019.

因为专业，所以值得信赖。如有需要，请加QQ：99515681 或邮箱：99515681@qq.com 微信：codehelp