Performance
Indicator
|
1
Poor
|
2
Insufficient
|
3
Satisfactory
|
4
Good
|
5
Excellent
|
|
Requirements Analysis
|
Makes little effort to define requirements before implementation.
|
Defines sketchy requirements, but the required behavior is not clear before implementation. Abstractions are often too vague to be useful.
|
Demonstrates an understanding of what is wanted in the program and how to write the resulting requirements specification.
|
Uses a data model that describes the abstract state of the program but often fails to use the model effectively.
|
Makes effective use of data model to describe the required abstract state of the program and produces rigorous requirements specifications.
|
|
Program
Design
|
Shows virtually no understanding of the use of abstraction mechanisms.
|
Shows some understanding of the use of abstraction mechanisms.
|
Understands the process of object-oriented and functional design.
|
Understands how to write functions that abstract out the essential elements of a function and hide representation and other lower-level issues.
|
Demonstrates the ability to factor out appropriate abstractions in virtually all situations.
|
|
Development Process
|
Does not understand the waterfall development process. Not familiar with the four development phases of Analysis, Design, Implementation, and Test.
|
Requirement reviews and design reviews are carried out, but the relationship between the reviews and implementation is vague.
|
Requirement reviews and design reviews are conducted and the relationship between the reviews and implementation is established.
|
Requirements analysis and design, implementation, and testing are well planned but not well executed.
|
Requirement analysis and design, implementation, and testing are clearly planned and carried out. All requirements defined in the analysis phase are traceable to the design and the eventual implementation. Produces a rigorous development plan and schedule.
|
|
Testing
|
Has no concept of testing. Stubs and drivers are not considered in the development stage. Does not use a testing framework.
|
Understands the concept of testing. Drivers and stubs are used but not well defined. May use a testing framework but only minimally.
|
Aware of the importance of testing. The use of stubs and drivers is considered before implementation. Uses a testing framework consistently.
|
Makes testing plans, and testing is integrated with development. Stubs and drivers are written before further implementation. Writes test cases for a testing framework before writing code.
|
Makes testing plans, and testing is integrated with development. Stubs and drivers are written before further implementation. Writes test cases for a testing framework before writing code. Produces rigorous test reports.
|
|
Design Patterns
|
Design patterns are either unknown or used incorrectly.
|
Some knowledge of design patterns, but makes little use of them.
|
Analysis and design contains the correct use of design patterns, but only a few patterns are known well enough to be employed.
|
A large number of design patterns are known and their use is understood to a large extent.
|
A wide variety of design patterns are correctly used to speed up the design process while creating more reliable and reusable programs.
|