Scorecard Item Definitions
- Former user (Deleted)
- Former user (Deleted)
- Former user (Deleted)
- Former user (Deleted)
The following scorecard item definitions are proposed.
No. |
Scorecard Item |
Evaluation |
Comments |
|---|---|---|---|
1.0 |
User Experience |
|
|
1.1 |
|
Follows the recommendations for Sakai UI conventions and practices as determined by a checklist. |
Former user (Deleted): Which checklist is this? |
1.2 |
|
Rates the usability of the application by stakeholders (instructors, students, admin, etc.) OR |
Former user (Deleted) Couldn't we use both if both are available? |
1.3 |
|
Follows the recommended practices and support for accessibility as defined by a checklist. |
Former user (Deleted): Which checklist is this? |
1.4 |
|
Support for other languages and cultures. Initially, this is measured by the number of languages supported by this application. Max of 20. |
Former user (Deleted): What is the point of a Max of 20? |
1.5 |
|
Same as usability and same problems. |
Former user (Deleted): I don't understand what is meant here... |
1.6 |
|
Results of hands-on user testing by a formal user testing team (methodology to be defined). |
|
2.0 |
Technical |
|
|
2.1 |
|
Support for web browsers supported by Sakai. Results of browser compatibility tests. |
Former user (Deleted): How do we decide what "browsers supported by Sakai" means? Is the later meant to define the former? |
2.2 |
|
Results of a formal code review team. Code is evaluated against accepted Sakai and industry practices. |
|
2.3 |
|
Unit tests generally are written against application service interfaces and implementations. Measured as percent coverage. |
Former user (Deleted) Unit test coverage? |
2.4 |
|
Functionality regression tests check the functionality of an application to ensure that it continues to function across changes. Results of functionality tests. Requires a written functionality description and test plan. |
|
2.5 |
|
|
|
2.6 |
|
Performance testing ensures that the application will perform well in small, medium, large, and very large environments. Evaluation has two parts: existence of tests, and results. |
Former user (Deleted): whats the definition of a small, medium, etc. environment? |
2.7 |
|
Follows recommended practices for internationalization and localization as defined by a checklist (initially string externalization). |
Former user (Deleted) We have http://confluence.sakaiproject.org/confluence/display/I18N/How+to+write+Internationalized+Tools+in+Sakai which goes further. |
2.8 |
|
License information is required in all code files and certain other places. Percent files labeled scaled to 10 points. |
|
2.9 |
|
Attempts to rate how many open bugs are present. |
Former user (Deleted): Number of Unresolved Bugs? Number of Unresolved Tasks? Weighted by issue Priority? Weighted by lines of code? |
2.10 |
|
Follows recommended practices for Sakai application packaging and naming conventions ad defined by a checklist. |
Former user (Deleted): Which checklist is this? |
2.11 |
|
Static (or automatic) code review checks for certain very common bugs, like swallowed exceptions. Has two parts: inclusion in the test scripts, and results. |
|
2.12 |
|
Follows recommended practices and standards for Sakai applications as defined by a checklist. |
Former user (Deleted): Which checklist is this? |
2.13 |
|
This is the number of databases supported. |
Former user (Deleted) Declared or tested? |
2.14 |
|
Follows recommended practices for database support as defined by a check list. |
Former user (Deleted): Which checklist is this? |
2.15 |
|
Follows recommended Sakai security practices as defined by a check list. |
Former user (Deleted): Which checklist is this? |
2.16 |
|
|
MJN: This is covered by code reviews. |
2.17 |
|
Support for event tracking. |
Former user (Deleted): What does "support" mean in this context? |
3.0 |
Descriptive |
|
|
3.1 |
|
Support for contextual help defined as percent coverage against functional description. |
|
3.2 |
|
(Megan to define) |
|
3.3 |
|
Internal code documentation (javadoc) as a percent of methods defined. |
|
3.4 |
|
Existence and quality of technical documentation including software architecture and design. |
|
3.5 |
|
Confluence documentation (TBD) |
|
3.6 |
|
Existence and quality of instructions for installation and deployment. This could include release conversion notes, too. |
|
3.7 |
|
Existence and quality of user documentation - how to use the application from stakeholder viewpoint. |
|
3.8 |
|
Uses Sakai's Jira to track issues including bugs, features, changes, etc. |
|
3.9 |
|
Documentation of event tracking - event definitions, etc. |
|
3.10 |
|
(see above) |
|
3.11 |
|
Existence and quality of documentation on configuration properties including system (sakai.properties), tool (tool configration), and Spring (components.xml). |
|
4.0 |
Community Support |
|
|
4.1 |
|
Size of the project team measured as the number of regular participants and contributors. Max of 20. |
Former user (Deleted):what is the max of 20 about? |
4.2 |
|
Participation by people with skills other than just programming. These include UX designers, QA support, stakeholder advisors, etc. |
Former user (Deleted) Do we add a new item with "Team institutional diversity" for participation by people from distinct institutions or do we combine both? |
4.3 |
|
Responsiveness of the project team to reported problems. |
|
4.4 |
|
Experience of the development team in terms of longevity, etc. |
|
4.5 |
|
Response to questions, openness, etc. |
|
