|
Project Course Student
Characteristics |
| Category |
"A" Student |
"B" Student |
"C" Student |
"D" Student |
"F" Student |
| Technical
Competence |
Excellent |
Good |
Fair |
Poor |
Unacceptable |
| General |
Demonstrates strong technical
expertise that is key to the project team.
Shows breadth of knowledge that helps the team create and understand
the big picture. Occasionally consults
with or mentors other team members on technical issues. Willing to learn new skills and
techniques. Able to work in all
project areas (requirements, design, coding, testing, planning). |
Generally
demonstrates good competence in several areas. Can work in most project
areas. May have some areas of weakness.
Prefers to work in areas of strength but is usually willing to work in
areas of weakness or to learn new things.
|
Has many areas of weakness. Generally lacks technical strength or
depth in any significant area needed by the team. Not usually willing to learn new things (e.g., programming
language). Work often needs to be
modified by other team members. |
A significant part of his/her
work has little value or has to be redone by other team members. |
Most work has little value or
has to be redone by other team members. |
| Requirements |
Requirements are thoroughly
understood and documented before attempting to design/implement
features. Requirements are accurate
and complete. Understands the
customer's intent for features.
Develops meaningful use cases to support requirements. |
Requirements are generally
understood. Some details may be
overlooked or not documented. Has a
good idea about the customer's intent for features. May develop some use cases for mainline features. |
Some requirements are
understood, but many aren't understood or aren't identified. Unlikely to have developed any meaningful
use cases. |
Really doesn't understand what
the customer needs. Written
requirements are inaccurate and/or incomplete. Many requirements are missing. |
Makes little if any attempt to
contribute to the identification of requirements. |
| Design |
Uses a consistent design process
and design notation to develop and document proposed solution approach. Design is fully elaborated in all area
that require it. Design is validated
against the requirements to ensure completeness. |
Uses a design process and design
notation to develop and document proposed solution approach. Design may not be fully elaborated in some
areas that should be. Design is generally
validated against requirements. |
Little evidence of a systematic
design process. Design documentation
is inadequate. |
No evidence of a design
process. Design is largely
undocumented. Design does not produce
meaningful detail. Unable to validate
the design against the requirements. |
Makes little if any attempt to
contribute to the development of a coherent system design. Lacks an understanding of how designing is different from coding. |
| Code |
Code is efficient, well
structured, and well commented.
Programming standards and conventions are followed. |
Code works as it should but may
not be the most efficient or effective implementation. Code comments may vary in adequacy and
detail. Programming standards and conventions are generally followed. |
Code may be messy and poorly
organized. Not all desired functional
behavior has been implemented and some undesirable side effects may be
present. Internal commenting is inadequate. Programming standards and conventions are
not consistently followed. May
include many undocumented features or undocumented side effects. |
Code written frequently must be
rewritten by other team members.
Little attention is paid to the implementation of defined requirements
and system design. Standards and
conventions aren't consistently followed. |
May not have sufficient skills
to contribute useful code to the project.
Code written is unlikely to function well enough to be included in the
product. Little evidence of applying
programming standards and conventions. |
| Testing |
Code is thoroughly tested
following a comprehensive test strategy.
Testing is performed at several levels including unit and system. A significant portion of tests are automated
when possible. Defects are
consciously identified and documented. |
Code has been tested but not a
thoroughly as it should be. When
possible some test automation is achieved.
Defects are routinely identified and documented. |
Code was inconsistently tested and not tested based
on a predefined strategy. Lacks
understanding of why testing is important. Little if any test automation is
achieved even when easily accomplished.
Defects are sometimes fixed without formally documenting them. |
Code was only superficially
tested and not tested based on a predefined strategy. Little if any test automation is
achieved. Many defects are fixed
without formally documenting them. Fixes aren't thoroughly tested. |
Code has not been tested beyond
a superficial level. Test automation
was not attempted. Defect recording
is at best haphazard. |
| Documentation |
Documentation is well written,
comprehensive and thorough. Always
kept up to date. |
Documentation is generally well
written but may lack important details in some areas. Not always kept up to date. |
Documentation is sketch and
potentially inaccurate. Significant
portions are out of date. |
Documentation is grossly
inadequate. Virtually impossible to tell whether or not it has been updated. |
Rarely documents work. |
| Process
Understanding & Execution |
Recognizes the need to follow a
well-defined an managed software development process. Consistently follows the process even in
times of project difficulty. Looks
for opportunities to improve the process. |
Generally follows the process
but may not have a full appreciation for why the process is important. |
Applies inconsistent effort to
understand and follow development processes. |
Often process-adverse. Tends to work in an ad hoc fashion with
little control or repeatability.
Substantial variation in results are seen. |
Consistently out of control. |
| Project
Management Competence |
Excellent |
Good |
Fair |
Poor |
|
| Leadership |
Operates effectively in the
project lead role |
Generally effective as a project
leader. |
Sometimes effective as project
leader, but has many instances in which he/she fails to provide leadership
when needed. |
Largely ineffective as a project
leader. |
Provides no evidence of
leadership ability. |
| Personal
Attributes |
Excellent |
Good |
Fair |
Poor |
|
| Teamwork |
Understands what others on the
team are doing and what they need.
Works to meet intra-team dependencies. Puts team goals ahead of personal goals. Performs his/her fair share of the
project. |
Works well with others on their
team. Interactions with others are
adequate to do individual tasks.
Usually does his/her fair share. |
Can't consistently work with
others as a peer. May create or
contribute to problems that inhibit effective teamwork. |
Works alone, has trouble sharing
and compromising with others. Creates frequent friction with others. Does not integrate well with rest of
team. Consistently puts personal goals
ahead of team goals. Often does not
contribute as much as other team members |
Openly antagonistic towards
others in the team. May sacrifice
team accomplishment to get even with team member(s). Goes along for the ride. |
| Dependability |
Consistently meets schedule and
quality objectives. Will identify in
advance if a task can't be completed as planned. |
Usually meets schedule and
quality objectives. Does not make
excuses. |
Misses significant schedule and
quality objectives. May not give team
members advanced notice of shortfalls.
Makes excuses for late or inadequate work. |
Frequently misses schedule and
quality objectives. Usually doesn't
give team members advanced notice of shortfalls. Makes excuses for late or inadequate work. |
Undependable. A project
liability. |
| Leadership |
Leads group through personal
example. Gains respect, loyalty and
commitment from team members. Under
his/her leadership, group efforts are usually successful. Relationships are usually win-win. Helps the team create the big picture. |
Is a good follower. Willing to
take a leadership role when the need arises.
Partners with the team leader to further the team's goals. May occasionally volunteer to lead activities
that align with areas of expertise.
Generally successful in leadership role. |
Shows little
interest in taking on leadership role. |
Has minimal interaction with
others on the team. Doesn't communicate status of work. Has difficulty seeing the big
picture. Reluctant to follow group
goals and objectives. May make
personal decisions that are contrary to group decisions. Other team members
often have to assume his/her leadership responsibilities. |
Unable to lead (or follow). |
| Vision |
Understands the purpose and goal
of the project. Understands why the
team is using its development process. |
Generally understands purpose
and goal of the project. At times may
need to be convinced by other team members. |
Does not have a clear
understanding of the project vision. |
Often hostile to direction the
team decides to take. Has a hard time
seeing the vision and other's perspectives. |
Myopic. Doesn't believe that the vision is
correct. Pursues own vision (if there
is one) at the expense of the project. |
| Risk
Taking |
Willing to take reasonable risks
but does so only after making a thorough analysis and assessment of the risk
and potential consequences |
1. Not inclined to take significant risks knowingly, or
2. Takes some risks without properly
assessing the potential consequences |
Often pays the price for not
having considered the risks associated with a particular course of
action. May also be risk adverse. |
Doesn't understand the concept
of risk management. Can't
differentiate between reasonable and unreasonable risks. |
Doesn't understand the concept
of risk management. Out of control. |
| Giving
/ Asking for Help |
Indicates willingness to give
help. Very willing to give help when asked.
Skillful at assisting others without implying superiority. Also quickly realizes when he/she needs help
then asks for it. |
Willing to provide assistance
when asked. Will ask for assistance
when needed. |
Can give assistance in a very
limited range. Usually doesn't
recognize when he/she should ask for help. |
Rarely able to give meaningful
help to other team members. May have
difficulty realizing that he/she needs help. If help is requested it is often
requested after significant time and effort have been wasted. Believes that success is just around the
corner. |
Neither gives nor asks for
help. Would rather sacrifice the
project than ask for help or assist others. |
| Self
Management |
Takes
on a significant role in helping the group plan team activities. Makes good
plans for his/her own work that are consistent with the overall project plan.
|
Helps the group with planning
the team activities. Makes good plans for his/her own work that are
consistent with the overall project plan. May experience some occasional
difficulties in executing according to the plan. |
Is inconsistent in planning
his/her own work. May operate in
panic mode from time to time. |
Not an effective contributor to
the team planning process. Does not
make individual plans. Works in
crisis mode. Frequently late in completing assigned work. Other team members may be required to take
over some assigned activities. |
Demonstrates little control over
life's events. |
| Initiative |
Watches for, proposes and
tackles new tasks that help make the project successful. A self starter. |
Proposes new tasks in their own
area of responsibility, some of which may not be of great project value. Prefers to be a follower. |
Demonstrates some initiative but
is inconsistent in its contribution. |
Must
continually be guided to complete tasks.
Doesn't find and suggest meaningful new tasks in their area of
contribution. |
Shows no initiative. Must be given explicit instructions on
what to do. |
| Flexibility |
Watches for critical tasks in
the project and communicates with other team members to address issues. Willing to switch tasks when needed to
ensure project success. Will work on
anything the team needs done. |
Generally willing to switch
tasks within areas of expertise. May
be a few areas in which he/she prefers not to work. |
Flexible in some areas and
inflexible in others. May be some areas in which he/she refuses to work. |
Not very flexible. Wants only to work on things that are
within his/her area of expertise and comfort zone. May take the "its not my job" position. |
Completely inflexible. |
| Communication
Skills |
Verbal and written
communications are of high quality and effective. Anticipates who will need information and gets it to them. Provides information in a timely fashion. Communicates effectively with project
sponsor. Listens well. Attends virtually all project
meetings. Keeps on top of e-mail. |
Communicates adequately in most
situations. Creates occasional
misunderstandings. Not always willing
to speak up or contribute when needed.
Generally understands what others are saying. Attends most project meetings. Keeps on top of e-mail |
Communication effectiveness is
inconsistent and usually requires clarification by other team members. May miss important team meetings. Doesn't check e-mail frequently enough |
Withdrawn and reticent. Often resists sharing information with
others. Communications are
ineffective. Does not listen to what
others are saying and as a result may waste time and effort. Frequently misses or is late for project
meetings. |
Communications may be incorrect
or disruptive. Does not listen to
what others are saying. Attendance at
project meetings is unpredictable. |
| Project
Reporting |
Consistently and accurately
report his/her contribution to the project.
Communicates both the good and the bad. |
Consistently and accurately
reports his/her contribution. May
occasionally need to be reminded to submit reports. Communicates with an emphasis on positive accomplishments. |
Has extreme difficulty in
submitting reports on time. Generally
does not keep good personal records of time spent. |
Needs to be frequently reminded
to submit reports. May report additional time not worked in order to create
the appearance of participation on the same level as his/her peers. Usually does not volunteer information
particularly on things that aren't going well. |
Either doesn't report or
routinely falsifies reports. |
| Customer
Relationship |
Goes the extra mile for the
customer. Seeks input from them and
tries to achieve results. Keeps the customer well informed, anticipates their
needs, and resolves issues quickly.
Customer feels fully informed about project status and issues. |
Demonstrates general
understanding of customers needs.
Responds to customer issues when prompted. Customer generally feels informed about project status and
issues. |
Generally does not understand
the customer's perspective and issues. Work is done without any real customer
focus. Customer needs and issues are
ignored. Customer doesn't feel
informed and would not want to work with this individual again. |
Does not develop a relationship
with or understanding of the customer. |
Is openly
hostile or antagonistic towards the customer. |
|
|
|
|
|
|
