...
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. | ~knoopFormer user (Deleted): Which checklist is this? |
1.2 | | Rates the usability of the application by stakeholders (instructors, students, admin, etc.) OR | ~jean-francois.leveque@upmc.fr 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. | ~knoopFormer 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. | ~knoopFormer user (Deleted): What is the point of a Max of 20? |
1.5 | | Same as usability and same problems. | ~knoopFormer 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. | ~knoopFormer 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. | ~jean-francois.leveque@upmc.fr 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. | ~knoopFormer 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). | ~jean-francois.leveque@upmc.fr 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. | ~knoopFormer 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. | ~knoopFormer 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. | ~knoopFormer user (Deleted): Which checklist is this? |
2.13 | | This is the number of databases supported. | ~jean-francois.leveque@upmc.fr Former user (Deleted) Declared or tested? |
2.14 | | Follows recommended practices for database support as defined by a check list. | ~knoopFormer user (Deleted): Which checklist is this? |
2.15 | | Follows recommended Sakai security practices as defined by a check list. | ~knoopFormer user (Deleted): Which checklist is this? |
2.16 | |
| MJN: This is covered by code reviews. |
2.17 | | Support for event tracking. | ~knoopFormer 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. | ~knoopFormer 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. | ~jean-francois.leveque@upmc.fr 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. |
|
