TopCoder Competition Methodology
Where it all begins - The Conceptualization contest works to fully document and define your application & the new process & features.
Mainly text document
with Use-Case Diagrams and Work Flow Diagrams
Wireframes define the "flow" of the application; the members compete to define the data groupings & overall application flow.
Storyboard contests task members with designing the "look and feel" or high level view of the application. Often run after wireframes have defined the "flow".
Just flat image and icons.
Builds a clickable HTML prototype of the application, takes the "look and feel" of the storyboards and the "flow" of the wireframes and build a working model.
Real page.
Specification contests flushes out and documents the application requirements to as much detail necessary to accomplish goal.
Use Case Diagrams Activity Diagrams
The application or module is designed technically based on the functional requirements.
Class Diagram
The majority of code in applications is produced in components; the architectures define what new functionality is required and launch component design and development contests to define and build
In Assembly contests, the module or application is constructed, as the members write the "glue" code to integrate components or modules into work product.
During Testing Scenarios & Cases competitions, the QA Test Plan is developed which will be used to validate that all requirements in the spec have been fully met in the development process
Throughout the whole process, small individual contests can be run to make changes, resolve issues, or assist with deploy tasks.
Posted Bug Races tracked in TopCoder Cockpit
The purpose of this questionnaire is to help TopCoder learn how your new application should operate to best address your need, problem or opportunity. We'll ask you to describe your current process, and identify your main needs or opportunities. We'll also ask questions about the sort of technical environment the new application should expect, and what features the new application should include.
Your responses to this document will be fed into the Pipeline to start the process of creating a prototype and writing a formal Requirements Specification for your application.
What this Document is Not
This Questionnaire is just a starting place – it is not a formal requirements specification. After you or your team complete this document, your Platform Manager will compile responses and post them to competition. The competition includes a lengthy question-and-answer period with you that will flush out details and exceptions. So, don't worry if you miss a few details – there will be many opportunities to fill in the gaps later!
What You Need To Do
Please answer the questions below to the best of your knowledge. If you would like to include drawings or diagrams to make your point better or easier, please feel free. Screenshots of the current application are always helpful too. You can answer questions directly in this document, or include attachments with your responses if you need more space.
Some questions are more important than others. Please do your best to answer questions marked with the red asterisk. If you cannot provide an answer, please include a few remarks about the reason.
When you're done, please email the Questionnaire to your Platform Manager.
| Q. | Please describe the chief goal(s) you wish to achieve by developing this application. |
| A. | TopCoder is looking to put more structure around the copilot process. At this initial phase, we'd like to define the whole copilot process on document such as how people are selected, what data a copilot profile should contain, how to determine copilot payments, the scope of copilot's work, and how copilot communicates with the client. We also like to • Build a module in TopCoder's new Direct application to support the whole copilot process defined above. • Have a copilot profile page integrated into current TopCoder site. |
| Q. | If you are planning to replace an existing application or business process, please describe the process below. Or, if you are creating an application to take advantage of an opportunity, please describe it here as well. If you wish, include a diagram that illustrates the steps and systems that are involved in the process. In this section, you are "telling the story." |
| A. | Over the past years, TopCoder have posted copilot opportunities where members were
selected to manage some parts of the TopCoder Software Development process. The
opportunities varied in size and scope, from managing the build of an overall
project to managing bug races and merges. TopCoder PMs post new copilot opportunities to a Project called Copilot Opportunities in Jira (TopCoder's bug traker system): https://www.topcoder.com/bugs/browse/COPILOT Any member who is interested in certain copilot opportunities can vote and put comments in the corresponding tickets. Which member is chosen as copilot is at TopCoder PM's discretion. After the copilot is chosen, he must perform the required tasks, an overview of the copilot can be viewed here: http://www.topcoder.com/wiki/display/tc/Copilot+Overview |
| Q. | Broadly speaking, who is involved with the data or application? (Please briefly describe the roles of people who will be involved or affected and the information that they will provide or receive.) |
| A. | • TopCoder PM: who posts copilot opportunity, defines the payment and work scope of
the copilot, and chooses the copilot(s) from voted members. • TopCoder members: who votes to copilot opportunity ticket in Jira, he/she can ask questions and leave comments about the copilot opportunity. • Copilot: The TopCoder member(s) who is chosen as the copilot by TopCoder PM. He/she will perform copilot's duties according to requirements defined by PM. |
| Q. | What information do you need to feed into the system to complete the process (system input)? For example, do you need to key in customer account numbers or names? Is there a list of shopping cart items? |
| A. | TopCoder PM will put the following information into the copilot opportunity
ticket: • General introduction on the project. • Payment structure for each contest type. • Specific responsibilities of the copilot. o Tasks before the contest launch o Tasks after the contest launch o Tasks after the contest completion The members vote and leave comments in copilot opportunity ticket. |
| Q. | What are the outputs of the system? For example, does the application charge the customer and print a receipt? Does it update another system? |
| A. | The final choice of the copilot by PM. |
| Q. | Does the application or process depend on other systems, documents or people? If so, name and briefly describe them here. |
| A. | TopCoder Jira (bug tracker) – the place where TopCoder PM posts copilot
opportunities, where members vote for the opportunities. TopCoder Direct – The application the copilots use to create contests for the projects they manage. TopCoder Wiki – The place where copilot put contest specifications. TopCoder Online Review – The central place to monitor and manage contests after the creation of them. |
| Q. | Are there shortcomings to the current system? If so please list and describe them here. |
| A. | • There are no historical data like completed projects, completed contests,
fulfillment percentage and real-time data like current project occupations
maintained for copilots. So when choosing copilot, there is no quantitative metrics
mentioned above for reference. • There is no initial discussion between TopCoder platform manager/client before the copilot is chosen. So copilots might not get enough information on the project to tell whether they are qualified for the required tasks. • The copilot payment is based on contests number, which is not optimized. • Current copilot process does not take the situation that the client PM directly manages the project into account. • There isn't a copilot pool defined yet (like our review board for each competition track), every member can vote for the opportunity, which increases the difficulty of choosing a good / qualified copilot. • Our current proposal for payment is a standard fee per managed contest, but the downsides to that is it provides greater incentives for the copilots to run more contests. It also doesn't address the situation where a more qualified copilot should earn more than a newer copilot. |
| Q. | If your system or process is comprised of different sub-applications, please briefly describe them here. For example, does/will the system integrate tightly with a 3rd party system? Is that system in scope or out? Are there tools that are used solely for user administration? Or a tool for managing home page content? |
| A. | Not Applicable |
| Q. | Please list any mission-critical reports that are produced by the system. |
| A. | Not Applicable |
| Q. | Is there anything else about the application that you'd like people to know? This is the place to address any functionality, problems, opportunities, risks, etc. that didn't "fit" in earlier questions. |
| A. | Not Applicable |
| Q. | Why are you taking the time to build this application? What are the expected benefits? What features will indicate success? |
| A. | We want to improve our current copilot process by defining a more structural one,
and build tools to support the new process. The chief goals of this initial phase of Copilot Revamp project are:
• Creating Copilot Profile pages that will contain copilot stats around the
number of contests managed, fulfillment %, number of opportunities managed,
etc
• Make Copilot Opportunities followed by a contest format where copilots will submit GamePlans and Development Strategy documents based on discussions with the platform managers and/or clients about the scope of work • Only having authorized pre-approved members be part of the copilot pool that will have access to these opportunities • Bringing copilots and customers/partners one step closer together in the overall management of the TopCoder Platform. • Increased incentives/disincentives around submitting on these opportunities and the subsequent management of them • Make the whole copilot process more structural, and propose new copilot payment mechanisms more suitable to the new copilot process. |
| Q. | What will the inputs to the system be? For example, what data or resources do the users or the system need in order to start the process? |
| A. | Not defined yet. |
| Q. | What are the expected outputs from the system? (Outputs can include printed reports, receipts, modified displays, electronic data feeds to external systems, etc) |
| A. | Not defined yet. |
| Q. | Please describe the ideal task flow of the new application; how should it work? Begin with the inputs and end with the outputs. In this section, you should exclude the exceptions that might occur. |
| A. | Below is a high-level process flow of the intended process:
|
| Q. | If possible, please describe the reasons why the path above can fail (or fails today). This could include time or resource limitations, problems with data relationships, other glitches, etc. |
| A. | Not Applicable |
| Q. | Is this a new system, or an upgrade to an older one? |
| A. | It's a upgrade to current system |
| Q. | Approximately how many users will be using the application? |
| A. | All the TopCoder platform managers, clients, and the members in copilot pool |
| Q. | How many users will be on the application concurrently? |
| A. | Not Applicable |
| Q. | Will any users be using the system from different timezones? |
| A. | Yes |
| Q. | Will the system need to receive feeds from external systems? If so, please name them, if possible. Include a description of the data that must be transferred, and the form it must be transferred in (e.g. email, paper, electronic feed, etc). |
| A. | No defined yet |
| Q. | Will the system need to send feeds to external systems? If so, please name them, if possible. Include a description of the data that must be transferred, and the form it must be transferred in (e.g. email, paper, electronic feed, etc). |
| A. | No defined yet |
| Q. | Is the system expected to send or receive email? Under which conditions? |
| A. | No defined yet |
| Q. | Is the system expected to operate with any peripheral devices besides a printer? For example, will the application be required to support fingerprint scanners, barcode guns, touchscreens, tablets, RFID, etc. |
| A. | No |
| Q. | Please describe the computer resources the designers should expect of the users. For example, will every user have a PC, or should the application be a "green-screen" app? Do users have keyboards and mice? Will users have internet access? |
| A. | Web application accessed by PC |
| Q. | Do users have specific GUI needs of the application? For example, should the application support "heads-down" or "cash register" style usage? |
| A. | Not Applicable |
| Q. | Please describe some new features that you would like to see the system include. |
| A. | Not Applicable |
| Q. | Should the system require the user to log in? |
| A. | Yes |
| Q. | Is there a "central authority" that manages user's accounts that this system should "talk" to? If so, please name or describe it if possible. |
| A. | Based on current system of TopCoder |
| Q. | Are there special auditing needs for user's activity on this application? |
| A. | Not Applicable |
| Q. | Will the user be working directly with financial or other protected information, like health records and classified data? |
| A. | No |
| Q. | Should the application be networked or stand-alone? Browser-based or thick-client? |
| A. | Browser based |
| Q. | Is there a particular language or platform on which the system must be built? |
| A. | The system is built as part of TopCoder platform |
Topcoder Copilot Revamp project is intended to improve current copilot process of TopCoder. It will define a more structural copilot process and build tools on current TopCoder platform to support the new Copilot process.
In this conceptualization contest, we'd like to address the following requirements:
• Define the whole copilot process as what is outlined in this high-level copilot process diagram. The process should be defined from :
° TopCoder's viewpoint
° Copilot's viewpiont
° Client's viewpoint
It's expected that there're high-level workflow diagrams for each viewpiont and a step by step process description.
• Define requirements of the copilot page which will contain copilot
statistics around the number of contests managed, fullfillment %, number of opportunities
managed, etc.
• Define requirements of tool which will be used to support the new
copilot process (this tool will be part of the TopCoder's new Direct application)
•
Define the contest format which is used to choose copilot. In this contest, copilots will
submit Gameplans and Development strategy documents based on dicussions with the platform
managers and/or clients about the scope of work. The Gameplan template and draft Development
Strategy Document Template will be provided for this conceptualization contest, you are
required to ask questions and post your feedbacks on these two templates, and polish these
two documents with the information in the forum.
• Propose different copilot payment
mechanisms (i.e. copilot compsensation approach) other than current one, the new payment
mechannisms should all be under the context of gettting to a deployed application. Our
current proposal for payment is a standard fee per managed contest, but the downsides to
that is it provides greater incentives for the copilots to run more contests. It also
doesn't address the situation where a more qualified copilot should earn more than a newer
copilot.
Tips for success
° Asking questions early and getting PM's feedback is very
important for the success of this conceptualization competition.
° There is a round
forum post which is used to discuss this copilot revamp project, try getting important
information and feedbacks from there: http://forums.topcoder.com/?module=Thread&threadID=672895
° This conceptualization requires a more detailed step by step process description than
the typical conceptualization workflow description. Make sure you remember that!
°
Submit milestone submission and get valuable feedbacks from PM.
One Round Contest
This Conceptualization Contest uses the One Round
format. Read carefully ALL SECTIONS of this contest specification to ensure you
understand the contest. You may use the "Contact PM" to clarify any contest
rules.
1. This competition will consist of a SINGLE ONE (1) round with a milestone.
2. This contest will be scored against a new scorecard located here:
http://www.topcoder.com/wiki/display/tc/Conceptualization+Changes
Competitors will be responsible for submitting the FINAL DELIVERABLE specifiied in section
1.2. The MILESTONE DELIVERABLE is optional. Ensure you are understand the difference and
what is being asked of you with the Milestone vs. Final Submission.
This contest will
follow a single one round format with a milestone deliverable. The milestone deliverable is a subset of the final document outlined in section 1.2.2. Competitors are allowed to submit before the specificed deadline in section 1.5 to earn a prize. The milestone will be judged solely by the client. The client will pick the top two submissions and rank them according to their own preference. The client is NOT obligated to award prizes if they feel the submissions are lacking in effort or scope.
After determining the top two winners, the client will share feedback about use cases,
scope, and process flows.
The milestone submission deliverable will consist of a subset
of the Conceptulization Document. Please refer to refer to section 1.2
The milestone submission deliverable consists of the following sections of the Conceptulization Document.
• Section 1.1 Overivew
• Section 3.1 Proposed Overview
• Section 3.3 High Level
Workflows
• Seciton 3.4 Use Case Diagrams
• Section 4.4 Task Requirements - draft
descriptions for the use cases identified in section 3.4
Your final deliverable will consist of the following. A contest distribution will be available in the forum for you
• Conceptualization Document -
° a fully complete conceptulization document. The contest distribution will be provided to you in the forums
• A .tcuml file for the use case diagrams
• All original
artifacts referenced in your conceptualization document such as visio diagrams.
•
Polished Development Strategy Document template
The following documentation is provided as input:
| Document Name | Document Description |
|---|---|
| BRD Submission Template | This is the Conceptualization Document template. Fill it out and submit it both for the Milestone and Final Submission. |
| Questionnaire | Questionnaire. You should analzye this document and post questions to the forum to engage with the client. |
| Copilot Gameplan template | The copilot gameplan template. |
| Draft Copilot Development Strategy Template | The draft copilot Development Strategy Document Template |
Registration Phase Duration (days): 3 days
Submission Phase Duration (days) 6 days
• Milestone submission 3 days
• Milestone Review: 1 day
• Final Deliverable 2 days
The milestone review is scheduled for 24 hours. You may continue working and posting questions during the milestone review.
This competition will be run as a single Online Review project.
For the milestone, the top two (2) submissions will be chosen and ranked by the client. Read below carefully......
1. The winners are completely at the client's discretion.
2. For this contest, you must
upload your milestone to Online Review. The timestamp of your submission will be used to
determine if you are eligible for a milestone review and prize. The milestone deadline will
be posted to the forum. You simply need to upload your milestone submission before the
deadline.
3. If you are selected to win a milestone prize, YOUR FINAL SUBMISSION MUST
PASS SCREENING TO EARN YOUR MILESTONE PRIZE. If you do not pass screening, you will not be
awarded the prize money.
| Place | Prize |
|---|---|
| Milestone 1st | $150 |
| Milestone 2nd | $50 |
The final submission will be determined based on the normal review process against a scorecard.
| Place | Prize |
|---|---|
| Final 1st place | $1000 |
| Final 2nd place | $500 |
The TopCoder Website will be updated with the following new and updated request processors:
These request processors will delegate to the defined copilot services, which will in turn use the copilot DAOs to manage the data in the database.
The copilot services will also be reused in the TC Direct site in the future to manage the copilot pool, launch copilot project, and associate contest to copilot project etc.
The data update, create and delete operations to the database need to be transactional.
Spring declarative transaction approach is used to annotate the transactional methods.
The defined copilot services and DAOs are expected to be called from multiple threads simultaneously, so they have to be thread-safe.
The TopCoder Website will create new request processors to process the incoming user requests, so they don’t need to be thread-safe.
Spring framework is used to load the configuration. Refer to the specific component for more details about what should be configured.
Some base exceptions have already been defined for the copilot services and DAOs.
The request processors should redirect to an error page defined in TC Website if exception occurs when processing the requests.
Logging Wrapper will be used to log the invocation details. The method entry and exit information will be logged with DEBUG level, and the exceptions will be logged with ERROR level.
None.
The database tables contain audit fields create_user, create_date, modify_user and modify_date columns), they need to be updated when inserting and updating the data record.
User is able to access the newly added copilot pool, profile, and project pages anonymously.
The copilot profile has an option to show the copilot earnings or not, and the copilot project has an option to show the project name or not. The TC Admin, Customer and owner 鮫f copilot profile or project) will be able to view the copilot earnings and project names always.
This feature will be implemented programmatically in the request processors.
The current reliability calculation utility will be updated to calculate the copilot reliability. And the copilot reliability is stored into the copilot_profile.reliability table column.
TC member is copilot if it has a copilot profile in copilot_profile database table), the CopilotProfileService.create method should be used to add a TC member into copilot pool.
And copilot profile’s status indicates the copilot is active or suspended temporary or permanently). The CopilotProfileService.update method should be used to update the copilot profile’s status, and the CopilotProfile.activateDate attribute should be set if the copilot is temporarily suspended.
After a copilot is selected for a TC Direct project, a CopilotProject should be created for the copilot. The copilot project has a wholeProject attribute, if it’s true, it indicates all the contests in the whole TC Direct Project will be managed by the copilot; otherwise, only the associated contests will be managed by the copilot.
In the former case, all the contests launched in the same TC Direct project are automatically managed by the copilot. In the latter case, the launched contest should be associated with specific copilot project.
Customer and PM are also able to add feedback about the copilot’s performance on the project; it’s done by updating the CopilotProject’s customerFeedback, customerRating, pmFeedback and pmRating fields through the CopilotProfileService.update method.
The tables defined in this module will be created in the tcs_catalog database.
The copilot_profile_status will contain the following values:
1 – Active
?– Temporary Suspended
3 – Permanently Suspended
The copilot_project_status will contain the following values:
1 – Active
?– Finished successful)
3 – InComplete failed)
copilot_profile.user_id - common_oltp.user.user_id
copilot_project.tc_direct_project_id - the same as tcs_catalog.project.tc_direct_project_id
planned_contest.project_category_id – tcs_catalog.project_category_lu.project_category_id
These two database tables will be used to store additional attributes for the copilot_project and copilot_profile. They are not used for now, and they are added for extensibility only.
The copilot_project_info_type and copilot_profile_info_type database tables define the metrics e.g. name) of the additional attributes.
The ProjectManager from project management component) contains a “ProjectCategory[] getAllProjectCategories?” method to return all the contest types.
The mapping between the tc-direct-project and copilot-project is always one-to-one. The online review contests in the tc-direct-project will have a copilot resource role to indicate which copilot the contest belongs to.
The request processors will be merged into the existing TC Website, and then the TC Website should be re-compiled and re-deployed into JBoss Application Server.
The request processors will be merged into the existing TC Website, and then the TC Website should be re-compiled and re-deployed into JBoss Application Server.
The copilot services and DAOs will be packaged into jar files and added to the TC Website library directory.
The component design and development solutions must adhere to the guidelines as outlined in the TopCoder Software Component Guidelines.
See the TCUML file.
The TC Website is updated with the new and updated request processors.
The UI is implemented using JSP and Google charts visualization.
None.
TopCoder is implementing a more structural copilot process. With this new process, they will build a copilot pool – only authorized pre-approved members will be part of the copilot pool that will have access to future copilot opportunities and each copilot will have a copilot profile page to show his/her copilot performance statistics such as number of contests managed, number of opportunities managed and current occupation etc. The clients, TopCoder members, TopCoder admins can access the copilot profiles to view the performance of the related copilots and some information about their projects. The information about copilot profiles will be provided through the TopCoder web-site.
In this document, we will specify the detailed requirements of the copilot pool and copilot profile pages from the wireframes.
Important: There are two user roles, related to copilots:
Please note, this specification does not cover project management actions of the CoPilot user role, so the functionality of the CoPilot Pool Member user role is specified, but the functionality specific to the CoPilot is out of scope.
This specification slightly changes the confusing messages from the wireframes, like “No of ...” was changed to “Number of ...”.
The pool management use cases were added for additional clarity, but they are quite general, because of absent wireframes.
The objectives of the entire copilot application are:
ROI metrics (though ROI metrics cannot be completely defined, but some thoughts for the return of investment can be provided) for the entire copilot application are:
General Capacity Metrics:
General Usability Metrics:
The limitations of the entire copilot application are listed below:
Assumptions for the entire copilot application are listed below:
Use case diagram is shown below:
All the users, registered to the TC web-site, can view the profiles of the CoPilot Pool Members. The profile will show the status, earnings, suspensions, reliability and overall projects/contests statistics for the related CoPilot Pool Member. The information will be displayed in visually attractive and intuitive tabular, pie/bar charts and textual formats. Not all the information will be displayed for all the users. The access rights are as following:
Wireframes page: “CoPilot Profile”.
| Copilot Statistics |
| Copilot Profile |
| Data Element | Description | Format | Possibly From | R? |
| <Member Handle> | The TC handle of the CoPilot Pool Member | String, max 15 chars, non empty | From TC web-site user accounts | Y |
| Status | The current status of the CoPilot Pool Member – says if Co-Pilot account is active or suspended due to reliability issues. If account is suspended, the activation date must be shown. |
String, max 10 chars, non empty. It can be Active, or Suspended. It will be colored: Active – green, Suspended – red. |
This application data | Y |
| Activation Date | The date when the suspended CoPilot Pool Member will be able to get any CoPilot opportunity (i.e. when he/she become active). | String, date format like “MM/DD/YYYY”, it will be absent if Status is “Active” | This application data | N |
| Earnings | The amount of money earned as Co-Pilot. This will be hidden from other TC Members if member decided to hide. If earnings were hidden, then it will be displayed |
Positive number, or 0. It will be money value. By default it is displayed in whole dollars, but will also
display cents if cents are non-zero. It will have “$” prefix. ?comma separator for thousands and
millions of dollars is needed. If earnings were hidden, then it will be displayed like String “<<HIDDEN>>” |
TC Web-site PAcTs, TC Direct | Y |
| Suspension | Shows count of suspensions – i.e. how many times the CoPilot Pool Member was suspended. Must be 0 for good Co-Pilot | Positive integer or 0. | This application data | Y |
| Reliability | The percentage of the CoPilot Pool Member reliability – how many his/her projects were successfully finished by him/her. |
1) If the reliability was already calculated for the CoPilot Pool Member, then Positive floating point
number with up-to two digits after point – like “?.67%”. ?whole numbers will be displayed
as integers – like “100%”, “0%”. The “%” postfix is needed. ? Else (no data on the CoPilot Pool Member reliability is present) it will be “n/a” String message. |
This application data | Y |
| Data Element | Description | Format | Possibly From | R? |
| # of Projects | Number of projects run (all projects – finished, active, incomplete). Clickable, leads to project history page. | Positive integer, or 0. | This application data, Online Review Tool, TC Direct | Y |
| # of Contests | Number of contests from all projects. Includes number of contests that succeeded (if the contest was reposted, it is counted only once) | Y | ||
| # of Reposts | The number of contest reposts for all the projects of the CoPilot Pool Member without changing prize/scope of the contest | Y | ||
| # of Failures | The number of contest failures for all the projects of the CoPilot Pool Member. Failed contest is defined as contest, which either was not reposted at all or prize/scope for it was changed after repost. | Y | ||
| # of Bug Races | Total number of bug races in all projects for all the projects of the CoPilot Pool Member | This application data, Online Review Tool, TC Direct, JIR?/td> | Y |
| Data Element | Description | Format | Possibly From | R? |
| Number of Current Projects | Number of projects in which Co-Pilot is involved currently | Positive integer, or 0. | This application data, Online Review Tool, TC Direct | Y |
| Number of Current Contests | Number of contests, which were posted by CoPilot, but are not finished yet | Y |
| Contest Statistics |
| Data Element | Description | Format | Possibly From | R? |
| <Real Number of Contests> | Number of contests (run in reality) of the type related to the pie for all the projects of the CoPilot Pool Member | Positive integer, greater than 0. | This application data, Online Review Tool, TC Direct | Y |
| Data Element | Description | Format | Possibly From | R? |
| <Contest type> | The type of the contest (including the sub-type for the Studio) | String, max 50 chars, non empty | Online Review Tool, TC Direct | Y |
| Data Element | Description | Format | Possibly From | R? |
| Planned Number of Contests | Number of contests of the chosen type planned by Game Plan for all the projects of the CoPilot Pool Member | Positive integer number, greater than 0, at least two digits are shown. | This application data, Online Review Tool, TC Direct | Y |
| Real Number of Contests | Number of contests of the chosen type that run in reality for all the projects of the CoPilot Pool Member | Y | ||
| Number of Reposts | The number of contest (of chosen type) reposts for all the projects of the CoPilot Pool Member without changing prize/scope of the contest | Positive integer number, or 0, at least two digits are shown. | Y | |
| Number of Failures | The number of contest (of chosen type) failures for all the projects of the CoPilot Pool Member. Failed contest is defined as contest, which either was not reposted at all or prize/scope for it was changed after repost. | Y |
| Data Element | Description | Format | Possibly From | R? |
| Planned Contests | Number of contests of the chosen type planned by Game Plan for all the projects of the CoPilot Pool Member | Positive integer number, greater than 0. | This application data, Online Review Tool, TC Direct | Y |
| Real Contests | Number of contests of the chosen type that run in reality for all the projects of the CoPilot Pool Member | Y | ||
| Reposts | The number of contest (of chosen type) reposts for all the projects of the CoPilot Pool Member without changing prize/scope of the contest | Positive integer number, or 0. | Y | |
| Failures | The number of contest (of chosen type) failures for all the projects of the CoPilot Pool Member. Failed contest is defined as contest, which either was not reposted at all or prize/scope for it was changed after repost. | Y |
| Number of contests |
| Data Element | Description | Format | Possibly From | R? |
| Planned Number of Contests | Number of contests of the chosen type planned by Game Plan for all the projects of the CoPilot Pool Member | Positive integer number, greater than 0, at least two digits are shown. | This application data, Online Review Tool, TC Direct | Y |
| Real Number of Contests | Number of contests of the chosen type that run in reality for all the projects of the CoPilot Pool Member | Y | ||
| Number of Reposts | The number of contest (of chosen type) reposts for all the projects of the CoPilot Pool Member without changing prize/scope of the contest | Positive integer number, or 0, at least two digits are shown. | Y | |
| Number of Failures | The number of contest (of chosen type) failures for all the projects of the CoPilot Pool Member. Failed contest is defined as contest, which either was not reposted at all or prize/scope for it was changed after repost. | Y |
| Field Name | Help Message |
| # of Projects | This shows the number of Projects successfully completed by the member |
| # of Contests | This shows the number of Contests successfully completed by the member |
| # of Reposts | This shows the number of Reposts done in order to successfully complete a contest |
| # of Failures | This shows the number of Contests that had failed to complete |
| # of Bug Races | This shows the number of bugs created in order to complete a project |
| Contest Statistics | The Graph below shows the statistics by different contest types |
It is possible to contact the related CoPilot Pool Member from his/her profile. This use case extends “View CoPilot Profile” use case – so the user can open the profile of some CoPilot Pool Member and contact him/her by pressing “Contact Co-Pilot” hyperlink. Actual contacting will be performed externally (like TC Member contact works on the TC web-site – sending a message to the member) – this future is fully re-used and is out of scope for this specification.
Wireframes page: “Contact Co-Pilot” hyperlink on the “CoPilot Profile” page.
The registered user can get access to the history of the projects, managed by the CoPilot, from that CoPilot Pool Member profile. This use case extends “View CoPilot Profile” use case. The user will view the page-able table of the expanded information on the CoPilot Pool Member projects – finished, active and incomplete. Not all the information will be displayed for all the users. The access rights are as following:
Wireframes page: “Project History”.
| Project History |
| Copilot Profile |
| Data Element | Description | Format | Possibly From | R? |
| Member: | The TC handle of the CoPilot Pool Member. It will be a hyperlink to view the CoPilot Pool Member profile | String, max 15 chars, non empty | From TC web-site user accounts | Y |
| Data Element | Description | Format | Possibly From | R? | |
| Project Name |
The name of the project, managed by the CoPilot Pool Member. It can be hidden according to the user
settings, or because of the project settings. It will be clickable to view the project details |
String, max chars, non empty. If hidden it will be displayed as “<<HIDDEN>>” String. |
This application data, Online Review Tool, TC Direct | Y | |
| Status | The current status of the project: Finished (means the successfully completed project), Active (means currently running project), Incomplete (means failed project) |
String, max 10 chars, non empty. It can be Finished, Active, Incomplete. It will be colored: Finished – green, Active – yellow, Incomplete – red. |
This application data, Online Review Tool, TC Direct | Y | |
| # of contests | Planned | Number of contests planned by Game Plan for the project | Positive integer number, or 0, at least two digits are shown. | Y | |
| Real | Number of contests of that run in reality for the project | Y | |||
| Duration | Planned | Shown planned project duration (in days) according to Game Plan | Positive integer or 0 in days, at least two digits are shown, it will have “ days” postfix, like “1 days”. | Y | |
| Real | Shown actual project duration (in days) | Y | |||
| # of reposts | The number of contest reposts without changing prize/scope of the contest for the project | Positive integer number, or 0, at least two digits are shown. | Y | ||
| # of failures | The number of contest failures for the project. Failed contest is defined as contest, which either was not reposted at all or prize/scope for it was changed after repost. | Y | |||
| * Click project name to view statistic details |
The registered user can get access to the details of the project, managed by the CoPilot, from the history of projects for that CoPilot Pool Member profile. This use case extends “View History of CoPilot Projects” use case. The user will view the overall statistics on the project contests, the breakdown of that statistics by the contest types, the bar chart diagrams on the planned vs. real schedules/contests for that project. Not all the information will be displayed for all the users. The access rights are as following:
Wireframes page: “Project Detail”.
| Project Details |
| Copilot Profile |
| Project History |
| Data Element | Description | Format | Possibly From | R? |
| Project Name | The name of the project, managed by the CoPilot Pool Member. It can be hidden according to the user settings, or because of the project settings. |
String, max chars, non empty. If hidden it will be displayed as “<<HIDDEN>>” String. |
This application data, Online Review Tool, TC Direct | Y |
| Status | The current status of the project: Finished (means the successfully completed project), Active (means currently running project), Incomplete (means failed project) |
String, max 10 chars, non empty. It can be Finished, Active, Incomplete. It will be colored: Finished – green, Active – yellow, Incomplete – red. |
This application data, Online Review Tool, TC Direct | Y |
| Data Element | Description | Format | Possibly From | R? |
| Member: | The TC handle of the CoPilot Pool Member. It will be a hyperlink to view the CoPilot Pool Member profile | String, max 15 chars, non empty | From TC web-site user accounts | Y |
| * Click project name to view statistic details |
The registered user can get access to the details of the project, managed by the CoPilot, from the history of projects for that CoPilot Pool Member profile. This use case extends “View History of CoPilot Projects” use case. The user will view the overall statistics on the project contests, the breakdown of that statistics by the contest types, the bar chart diagrams on the planned vs. real schedules/contests for that project. Not all the information will be displayed for all the users. The access rights are as following:
Wireframes page: “Project Detail”.
| Project Details |
| Copilot Profile |
| Project History |
| Data Element | Description | Format | Possibly From | R? |
| Project Name | The name of the project, managed by the CoPilot Pool Member. It can be hidden according to the user settings, or because of the project settings. |
String, max ?5 chars, non empty. If hidden it will be displayed as “<<HIDDEN>>” String. |
This application data, Online Review Tool, TC Direct | Y |
| Status | The current status of the project: Finished means the successfully completed project), Active means currently running project), Incomplete means failed project) |
String, max 10 chars, non empty. It can be Finished, Active, Incomplete. It will be colored: Finished – green, Active – yellow, Incomplete – red. |
This application data, Online Review Tool, TC Direct | Y |
| Data Element | Description | Format | Possibly From | R? |
| Member: | The TC handle of the CoPilot Pool Member. It will be a hyperlink to view the CoPilot Pool Member profile | String, max 15 chars, non empty | From TC web-site user accounts | Y |
| Project Details |
| Data Element | Description | Format | Possibly From | R? |
| Planned Number of Contests | Number of all contests planned by Game Plan for the currently chosen project of the CoPilot Pool Member | Positive integer number, greater than 0, at least two digits are shown. | This application data, Online Review Tool, TC Direct | Y |
| Real Number of Contests | Number of all contests that run in reality for the currently chosen project of the CoPilot Pool Member | Y | ||
| Number of Reposts | The number of all contest reposts for the currently chosen project of the CoPilot Pool Member without changing prize/scope of the contest | Positive integer number, or 0, at least two digits are shown. | Y | |
| Number of Failures | The number of all contest failures for the currently chosen project of the CoPilot Pool Member. Failed contest is defined as contest, which either was not reposted at all or prize/scope for it was changed after repost. | Y | ||
| Planned Duration | Shown planned project duration in days) according to Game Plan | Positive integer or 0 in days, at least two digits are shown, it will have “ days” postfix, like “1?days”. | This application data, Online Review Tool, TC Direct | Y |
| Real Duration | Shown actual project duration in days) | Y | ||
| Planned Number of Bugraces | Planned number of bugraces for the currently chosen project according to Game Plan | Positive integer number, or 0, at least two digits are shown. | This application data, TC Direct, JIRA | Y |
| Real Number of Bugraces | Shows real number of bugraces required for the currently chosen project. | Y | ||
| Customer Feedback | This will be a feedback on the currently chosen project from customer. It will be pre-moderated by TopCoder PM and contain some textual information about Co-Pilot work. | String, max 4096 chars, can be empty | This application data, TC Direct | N |
| PM Feedback | This will be a feedback from PM on the currently chosen project. | String, max 4096 chars, can be empty | N |
| Data Element | Description | Format | Possibly From | R? |
| <Contest type> | The type of the contest including the sub-type for the Studio) | String, max 50 chars, non empty | Online Review Tool, TC Direct | Y |
| Data Element | Description | Format | Possibly From | R? |
| Planned Number of Contests | Number of contests of the chosen type planned by Game Plan for the currently chosen project of the CoPilot Pool Member | Positive integer number, greater than 0, at least two digits are shown. | This application data, Online Review Tool, TC Direct | Y |
| Real Number of Contests | Number of contests of the chosen type that run in reality for the currently chosen project of the CoPilot Pool Member | Y | ||
| Number of Reposts | The number of contest of chosen type) reposts for the currently chosen project of the CoPilot Pool Member without changing prize/scope of the contest | Positive integer number, or 0, at least two digits are shown. | Y | |
| Number of Failures | The number of contest of chosen type) failures for the currently chosen project of the CoPilot Pool Member. Failed contest is defined as contest, which either was not reposted at all or prize/scope for it was changed after repost. | Y |
| Project Statistics |
| Data Element | Description | Format | Possibly From | R? |
| Planned Contests | Number of all contests planned by Game Plan for the currently chosen project of the CoPilot Pool Member | Positive integer number, greater than 0. | This application data, Online Review Tool, TC Direct | Y |
| Real Contests | Number of all contests that run in reality for the currently chosen project of the CoPilot Pool Member | Y | ||
| Planned Bug Races | Planned number of bugraces for the currently chosen project according to Game Plan | Positive integer number, or 0, at least two digits are shown. | This application data, TC Direct, JIRA | Y |
| Real Bug Races | Shows real number of bugraces required for the currently chosen project. | Y |
| Data Element | Description | Format | Possibly From | R? |
| Planned Duration | Shown planned project duration in days) according to Game Plan | Positive integer or 0 in days | This application data, Online Review Tool, TC Direct | Y |
| Real Duration | Shown actual project duration in days) | Y |
| Data Element | Description | Format | Possibly From | R? |
| Project Name | The name of the project, managed by the CoPilot Pool Member. It can be hidden according to the user settings, or because of the project settings. |
String, max ?5 chars, non empty. If hidden it will be displayed as “<<HIDDEN>>” String. |
This application data, Online Review Tool, TC Direct | Y |
| Data Element | Description | Format | Possibly From | R? |
| Planned Contests | Number of all contests of planned by Game Plan for the currently chosen project of the CoPilot Pool Member | Positive integer number, greater than 0. | This application data, Online Review Tool, TC Direct | Y |
| Real Contests | Number of all contests that run in reality for the currently chosen project of the CoPilot Pool Member | Y | ||
| Reposts | The number of all contest reposts for the currently chosen project of the CoPilot Pool Member without changing prize/scope of the contest | Positive integer number, or 0. | Y | |
| Failures | The number of all contest failures for the currently chosen project of the CoPilot Pool Member. Failed contest is defined as contest, which either was not reposted at all or prize/scope for it was changed after repost. | Y |
| Number of contests |
| Data Element | Description | Format | Possibly From | R? |
| Planned Number of Contests | Number of contests of the chosen type planned by Game Plan for the currently chosen project of the CoPilot Pool Member | Positive integer number, or greater than 0, at least two digits are shown. | This application data, Online Review Tool, TC Direct | Y |
| Real Number of Contests | Number of contests of the chosen type that run in reality for the currently chosen project of the CoPilot Pool Member | Y | ||
| Number of Reposts | The number of contest if chosen type) reposts for the currently chosen project of the CoPilot Pool Member without changing prize/scope of the contest | Positive integer number, or 0, at least two digits are shown. | Y | |
| Number of Failures | The number of contest if chosen type) failures for the currently chosen project of the CoPilot Pool Member. Failed contest is defined as contest, which either was not reposted at all or prize/scope for it was changed after repost. | Y |
The registered user can freely navigate to all the pages, related to the CoPilot Pool Members: CoPilot Profile page, Project History page, Project details page. The navigation can be performed through the left navigation bar iut of scope for this specification), or through the links of the mentioned pages itself.
Wireframes page: “CoPilot Profile”, “Project History”, “Project Details”.
The CoPilot Pool Member can choose whether to display his/her earnings for other TC Members and CoPilots or not. In TopCoder profile there will be a separate setting – hide Co-Pilot earnings. This will be separate from usual Payments number hiding option of the TC community users.
The customer and the TC Admin can provide textual feedback for the project. That feedback will be stored to the profile of the CoPilot Pool Member, managed that project. That action will be performed externally out of scope for this specification).
After the project finish or fail), the customer can write Co-Pilot review. It will be moderated by TC Admin and shown on Co-Pilot’s related to that project) profile page. Reading these reviews can help customer to select Co-Pilot for their needs.
The TC Admin can write his/her own review of Co-Pilot work after the project finish or fail). It will be also seen at Co-Pilot profile.
There will be ability for the TC Member to request for membership in the CoPilot Pool. Each request will be processed manually by TC Admins and they will decide whether to place applied TC Member to the CoPilot Pool or not. This use case will be especially useful at the initial phase of the application usage, when the CoPilot Pool have small amount of members.
TC Admins will be responsible for populating CoPilot Pool with new members in case of manual filling of the CoPilot Pool on the initial phase of the application usage). TC Members can be added using common rules defined above, or, at Manager discretion 鮤e/she knows that this member is qualified well).
TC Admin will be able to temporarily remove the CoPilot Pool Member from the CoPilot Pool in cases of the low quality job or reliability issues. The application will notify TC Admins about such cases, but the last decision will be made by the TC Admin.
TC Admin will be able to permanently remove the CoPilot Pool Member from the CoPilot Pool in cases of the extremely low quality job or full violation of the reliability. The application will notify TC Admins about such cases, but the last decision will be made by the TC Admin.
The TC Admin can freely configure application options and settings. It will be performed externally – like through configuration files, TC members accounts, customer accounts in the TC Direct, customers’ project entries in the Online Review tool and TC Direct, etc. TC Admin can choose which project names will be hidden i.e. private), and which – are not. He/she can also configure access rights to customers and other users – whether they can view names of projects in this application or not. The TC Admin can define types of the contests as well.
The application will maintain several rules for copilots – this use case is just a set of such rules. There will be rules for TC Members to qualify for the CoPilot Pool. The rules for suspension / removal of CoPilot Pool Members from the CoPilot Pool are also defined. There are many other rules for CoPilots, CoPilot Pool Member, Customers and TC Admins, defined in this use case – all of them relate to the copilot functionality of the application.
The copilot-related data will be stored for each member in the CoPilot Pool – this use case just lists the data, needed for the copilots. All the needed data for the CoPilot Pool Member is listed here.
| Data Element | Description | Format | Possibly From | R? |
| <Member Handle> | The TC handle of the CoPilot Pool Member | String, max 15 chars, non empty | From TC web-site user accounts | Y |
| Status | The current status of the CoPilot Pool Member – says if Co-Pilot account is active or suspended due to reliability issues. If account is suspended, the activation date must be shown. |
String, max 10 chars, non empty. It can be Active, or Suspended. It will be colored: Active – green, Suspended – red. |
This application data | Y |
| Activation Date | The date when the suspended CoPilot Pool Member will be able to get any CoPilot opportunity i.e. when he/she become active). | String, date format like “MM/DD/YYYY”, it will be absent if Status is “Active” | This application data | N |
| Earnings | The amount of money earned as Co-Pilot. This will be hidden from other TC Members if member decided to hide. If earnings were hidden, then it will be displayed |
Positive number, or 0. It will be money value. By default it is displayed in whole dollars, but will also
display cents if cents are non-zero. It will have “$” prefix. A comma separator for thousands
and millions of dollars is needed. If earnings were hidden, then it will be displayed like String “<<HIDDEN>>” |
TC Web-site PACTs, TC Direct | Y |
| Suspension | Shows count of suspensions – i.e. how many times the CoPilot Pool Member was suspended. Must be 0 for good Co-Pilot | Positive integer or 0. | This application data | Y |
| Reliability | The percentage of the CoPilot Pool Member reliability – how many his/her projects were successfully finished by him/her. |
1) If the reliability was already calculated for the CoPilot Pool Member, then Positive floating point
number with up-to two digits after point – like “?.67%”. A whole numbers will be displayed
as integers – like “100%”, “0%”. The “%” postfix is needed. ? Else no data on the CoPilot Pool Member reliability is present) it will be “n/a” String message. |
This application data | Y |
| Data Element | Description | Format | Possibly From | R? |
| # of Projects | Number of projects run all projects – finished, active, incomplete). Clickable, leads to project history page. | Positive integer, or 0. | This application data, Online Review Tool, TC Direct | Y |
| # of Contests | Number of contests from all projects. Includes number of contests that succeeded if the contest was reposted, it is counted only once) | Y | ||
| # of Reposts | The number of contest reposts for all the projects of the CoPilot Pool Member without changing prize/scope of the contest | Y | ||
| # of Failures | The number of contest failures for all the projects of the CoPilot Pool Member. Failed contest is defined as contest, which either was not reposted at all or prize/scope for it was changed after repost. | Y | ||
| # of Bug Races | Total number of bug races in all projects for all the projects of the CoPilot Pool Member | This application data, Online Review Tool, TC Direct, JIRA | Y | |
| Number of Current Projects | Number of projects in which Co-Pilot is involved currently | Positive integer, or 0. | This application data, Online Review Tool, TC Direct | Y |
| Number of Current Contests | Number of contests, which were posted by CoPilot, but are not finished yet | Y |
| Data Element | Description | Format | Possibly From | R? |
| Project Name | The name of the project, managed by the CoPilot Pool Member. It can be hidden according to the user settings, or because of the project settings. |
String, max ?5 chars, non empty. If hidden it will be displayed as “<<HIDDEN>>” String. |
This application data, Online Review Tool, TC Direct | Y |
| Project Status | The current status of the project: Finished means the successfully completed project), Active means currently running project), Incomplete means failed project) |
String, max 10 chars, non empty. It can be Finished, Active, Incomplete. It will be colored: Finished – green, Active – yellow, Incomplete – red. |
This application data, Online Review Tool, TC Direct | Y |
| <Contest type> | The type of each contest including the sub-type for the Studio) |
String, max 50 chars, non empty. Please refer chapter ?1.1.3 for possible values. |
Online Review Tool, TC Direct | Y |
| Planned Number of Contests | Number of contests of the chosen type planned by Game Plan for each project of the CoPilot Pool Member | Positive integer number, greater than 0, at least two digits are shown. | This application data, Online Review Tool, TC Direct | Y |
| Real Number of Contests | Number of contests of the chosen type that run in reality for each project of the CoPilot Pool Member | Y | ||
| Number of Reposts | The number of contest if chosen type) reposts for each project of the CoPilot Pool Member without changing prize/scope of the contest | Positive integer number, or 0, at least two digits are shown. | Y | |
| Number of Failures | The number of contest if chosen type) failures for each project of the CoPilot Pool Member. Failed contest is defined as contest, which either was not reposted at all or prize/scope for it was changed after repost. | Y | ||
| Planned Duration | The planned duration in days) for each project according to Game Plan | Positive integer or 0 in days, at least two digits are shown, it will have “ days” postfix, like “1?days”. | This application data, Online Review Tool, TC Direct | Y |
| Real Duration | The actual duration in days) of each project | Y | ||
| Planned Number of Bugraces | Planned number of bugraces for the currently chosen project according to Game Plan | Positive integer number, or 0, at least two digits are shown. | This application data, TC Direct, JIRA | Y |
| Real Number of Bugraces | Shows real number of bugraces required for the currently chosen project. | Y | ||
| Customer Feedback | This will be a feedback on the currently chosen project from customer. It will be pre-moderated by TopCoder PM and contain some textual information about Co-Pilot work. | String, max 4096 chars, can be empty | This application data, TC Direct | N |
| PM Feedback | This will be a feedback from PM on the currently chosen project. | String, max 4096 chars, can be empty | N |
| Data Element | Description | Format | Possibly From | R? |
| Copilot Earnings Privacy Configuration | The CoPilot Pool Member can choose whether to display his/her earnings for other TC Members and CoPilots or not | Boolean, Show/Hide | This application data, user account on TC Web-site | Y |
The Customer can configure which his/her projects are private and which are public for the CoPilot profiles. If the project is private, then its name will be NOT shown on the CoPilot profile. The name of the public project will be displayed on the CoPilot account.
Setting up the project privacy will be performed externally – in the TC Direct application.
The GUI needs to be simple and intuitive. Using the application should be mostly self explanatory so that someone can use it without having to be training in the TC process. The GUI will follow the provided wireframes: http://www.topcoder.com/wiki/download/attachments/4觋38501/copilot_profile_pages_wireframes.zip?version=1
Standard resolution requirements for the TC web-site will be used like all screen resolutions of 10? x 768 pixels and above must be supported).
User Metrics Requirements:
Performance Requirements:
All security checks will occur against permissions. Each function in the system will validate a user’s permission against the required permission for the task. The Login/Logout functionality is fully out of scope for this specification.
One or more permissions will be assigned to roles. A user may have more than one role. Regular user can perform all actions with only his/her own projects. The admin can perform all actions on all the projects. Below is a list of roles and permissions. The System role was added for the clarity.
| CoPilot Pool Member | Customer | TC Member | TC Admin | System | |
| View CoPilot Profile | X | X | X | X | |
| Contact CoPilot Pool Member [external] | X | X | X | X | |
| View History of CoPilot Projects | X | X | X | X | |
| View CoPilot Project Details | X | X | X | X | |
| Navigate CoPilot Profile Pages | X | X | X | X | |
| Set up Earnings Privacy Settings [external] | X | ||||
| Write Project Feedback for CoPilot [external] | X | X | |||
| Set up Project Privacy | X | ||||
| Request Membership in CoPilot Pool | X | ||||
| Manage CoPilot Pool Access Requests | X | ||||
| Remove Member from CoPilot Pool Temporarily | X | ||||
| Remove Member from CoPilot Pool Permanently | X | ||||
| Configure Application [external] | X | ||||
| Process CoPilot Rules | X | ||||
| Keep CoPilot Data | X |
Users with the administrator role can view all the data from the Copilot profiles and configure the application.
The same as in the TopCoder web-site. We will fully re-use login/logout from the existing TopCoder web-site.
To implement ratings calculation and displaying for the copilots (like gray, green, blue, yellow, red and the related bounds with formula) when the enough statistics on the copilot data will be present.
| Definition | Description |
| CoPilot Pool Member | TC member which has rights for election to be a CoPilot for projects. TC Member has to achieve good results in other competitions 鮨ike design, architecture, etc. – according to the defined rules) to be placed to the CoPilot Pool. |
| Customer | This user is TopCoder client who wishes to hire a Co-Pilot for his/her project. |
| TC Direct | The TopCoder Direct application, which allows customers to launch and manage competitions on the TopCoder directly |
| TC Online Review Tool | The special TopCoder application for submitting components and manage contests. |
| TC Admin | TopCoder staff use TopCoder Direct to monitor contests and view statistics. They also can launch their own contests. The user, which can perform all actions on all the projects in the system. |
| TC Member | This is TopCoder member who is not added to Co-Pilot pool. He can become a Co-Pilot pool member after achieving the needed conditions 鮮ating, experience, etc.). |
| Definition | Description |
| JIRA | Bug-tracking software, used by TC |
| PACTs | Payment tracking pages on TC web-site: http://www.topcoder.com/PactsMemberServlet?module=PaymentHistory |
| TC | TopCoder |
The client of this application is DARPA. They asked TopCoder to make a modern web-portal for education in Science, Technology, Engineering, Math (STEM) and especially focused on Computer Science (CS) education. That CS-STEM web-site will be dedicated to middle and high school students in USA and allow them to learn a lot of interesting topics in a user-friendly environment, which at the same time is productive and professional.
CS-STEM portal will be like a new entire TC website, but specially dedicated to the education of middle- high students (ages of 13...18).
This specification will cover the student and parent registration-related portions of the web-site. The detailed information about how students/parents will register to the application and various approvals will be provided. The specification describes students' restrictions to participation in activities, how the Student requests for parent authorization and how the Student get approved by the parent. There will be details about how users can get approved as Parents, how parents receive and process authorization requests from their children, how parents perform parental control and share activities with their children on the application. It will be also described how the System Admin will process student approvals from their parents as well.
The following use cases of the "CS-STEM Education Project Hosting Platform" conceptualization are in scope. Please note, they will be slightly renamed and extended in the specification document, but references to those original use cases are also provided.
The objectives of the entire CS-STEM education hosting platform application are as following (this specification covers just a small part (student and parent registration-related) of that main application).
Project Return on Investment (ROI Metrics) of the entire CS-STEM education hosting platform application are as following:
General Capacity Metrics:
General Usability Metrics:
The limitations of the entire CS-STEM education hosting platform application are listed below:
Assumptions critical to the success of the entire CS-STEM education hosting platform application are listed below:
Environment and technology requirements:
Use case diagram is shown below:
The application will allow non-registered users to register to it as a Student, or as a Parent (etc.). This use case is specially focused on Student and Parent registration. The user will choose his/her role in the application, provide credentials and (optionally) more contacts/personal information. Registration will require properly entered CAPTCHA code and e-mail activation. The notification e-mail is also sent to the newly registered Student (or Parent, etc.) user on the successful activation. If the Student registered to the application, then his/her account will be created as non-authorized yet by his/her parent. If the Parent registered to the application, then his/her account will be created as non-approved yet by the System Admin. This use case includes "Send E-mail Notifications" use case 2.14. Please note, Liferay Portal doesn’t have a registration page, so that registration page needs to be added as a portlet. Reference to initial use case in conceptualization: "4.4.12".
| Data Element | Description | Format | R? |
| Handle | The unique username (handle) for the account on the application | The handle is in two parts: (1) a minimum 4 maximum 8 character handle (no spaces) (2) a “last name” selected from a drop-down of options The two part name is merged as a single handle in the database. A space separates the two names. |
Y |
| Password | The password of the user | String, min 6 chars, max 10 chars, case sensitive, any combination of ASCII characters. Displayed with ‘*’ chars when entering | Y |
| The e-mail address of the user. This is optional. | String, max 100 chars, must be a valid e-mail, non empty | N | |
| CAPTCHA code | The picture with CAPTCHA code to be entered by the user for validation that he/she is a human | A picture (dimensions are up-to the Studio designer) having a String, 6 chars, non empty. | Y |
| Data Element | Description | Format | R? |
| First Name | The first name of the user | String, max 50 chars, can be empty | N |
| Last Name | The last name of the user | String, max 50 chars, can be empty | N |
| City | The city of the user | String, max 100 chars, can be empty. It will be an auto-complete field to user input with a possible selection from the existing data in the auto-complete list or by entering a new data by the user | N |
| State | The US state of the user | String, max 2 chars, can be empty. One of the USA state or DC. It will be an auto-complete field to user input with a possible selection from the existing data in the auto-complete list. |
N |
| ZIP | A ZIP code of the user | String, max 5 chars, each char is a digit from [0-9], can be empty. It will be an auto-complete field to user input with a possible selection from the existing data in the auto-complete list or by entering a new data by the user | N |
| Country | Name of the user’s country. | Autocomplete. If US is selected, the address fields with asterisks above are required. If non-US, they are not. | |
| School Name | The name of the school for the user (for all user roles, except Parent) | String, max 100 chars, can be empty. It will be an auto-complete field to user input with a possible selection from the existing data in the auto-complete list or by entering a new data by the user | N |
| Grade | The grade of the Student | Positive integer from 6 to 12. Can be absent (if the user is not a Student). It will be an auto-complete field to user input with a possible selection from the existing data in the auto-complete list or by entering a new data by the user. | N |
| Gender | The sex of the user | String, one of the following values: Male, Female, I decline to respond to this question. Can be empty. |
N |
| Date of Birth | The date of birth of the user | String, Date format like YYYY-MM-DD, can be empty. | N |
The application will allow the Student and Parent to unregister from it. This use case is specially focused on Student and Parent un-registration. The user will confirm his/her decision and the application will remove the user account, profile, and the related data. The user cannot re-register once more without an approval from the System Admin. This use case includes “Send E-mail Notifications” use case 2.14. Please note, Liferay Portal doesn’t have a un-registration page, so that un-registration page needs to be added as a portlet. The Liferay User Profile can be re-used and customized to properly show user un-registration status on profiles of other related users. The Liferay Permissions Model can be re-used and customized to properly change the Student's permissions to not authorized after his/her Parent has unregistered. The Liferay Survey portlet (http://www.liferay.com/downloads/liferay-portal/community-plugins/-/software_catalog/products/6943201) can be re-used for submitting surveys by the user. Reference to initial use case in conceptualization: “4.4.26”.
| Data Element | Description | Format | R? |
| Title | The name of the survey | String, max 50 chars, non empty | Y |
| Description | The description of the survey | String, max 200 chars, non empty | Y |
| <set of questions> | The description of the survey | ||
| Data Element | Description | Format | R? |
| Question | Text of the survey question | String, max 50 chars, non empty | Y |
| Answer 1 | Text of the 1st answer choice for the question | String, max 100 chars, non empty | Y |
| Answer 2 | Same for 2nd answer choice for the survey question | String, max 100 chars, can be empty if the question is absent | N |
| Answer 3 | Same for 3rd answer choice for the survey question | String, max 100 chars, can be empty if the question is absent | N |
| … etc. answers | … | ||
| Data Element | Description | Format | R? |
| Student's handle | The unique username (handle) of the child Student in the CS-STEM application | String, max 50 chars, non empty | Y |
| Student's e-mail | The e-mail address for the child Student | String, max 100 chars, must be a valid e-mail, non empty | Y |
| Unregistered On | The date when the child Student was unregistered from CS-STEM application | String, short date format like MM/DD/YYYY, non empty | Y |
| Data Element | Description | Format | R? |
| Parent's handle | The unique username (handle) of the Parent in the CS-STEM application | String, max 50 chars, non empty | Y |
| Parent's e-mail | The e-mail address for the Parent | String, max 100 chars, must be a valid e-mail, non empty | Y |
| Unregistered On | The date when the Parent was unregistered from CS-STEM application | String, short date format like MM/DD/YYYY, non empty | Y |
| Student’s Approval Status | The authorization approval status of the child Student | Empty String value – it means the child Student is not authorized yet and can get just the read-only and practice-only access to CS-STEM activities | Y |
The application will allow System Admins to apply results from mailed parent approvals to the profiles of the
related child students in the system. There will be a special web-page where the System Admin can mark students'
accounts as approved or denied to access CS-STEM application activities according to decision of their parents
(please note, the approval form will have just one permission value per student - a boolean like “Permitted” or
“Restricted”). The System Admin can also place some own remarks (like comments) to the student approval or
rejection data and notify student and his/her parent about approval results. This use case includes use case 2.7
"Get Approved by Parent". This use case also includes “Send E-mail Notifications” use case 2.14. Please note, we
can re-use Liferay User Profile – It provides the profile functionality. It needs to be customized to support
the approval/rejection status fields in our application.
Reference to initial use case in
conceptualization: “4.4.39”.
| Data Element | Description | Format | R? |
| Signed On | The date when the approval form was signed by the parent | String, short date format like MM/DD/YYYY, non empty. It will be chosen from the date picker control and, therefore, no validation is needed. | Y |
| Parent Handle | The unique username (handle) of the Parent, filled the approval form | Single item selection list with auto-complete feature. Each item in the list is String, max 50 chars, can be empty if the Parent is not registered to CS-STEM application. | N |
| Parent E-mail | The e-mail address of the Parent, filled the approval form | Single item selection list of the Parent e-mail addresses, entered by the child Student when requesting the parent authorization or retrieved by Parent handle lookup. Each item is String, max 100 chars, non empty, must be a valid e-mail | Y |
| Data Element | Description | Format | R? |
| <Remarks> | The remarks text data for the parent approval status | String, max 200 chars, can be empty. No validation is needed - just the limited maximum possible count of characters will be automatically supported by the Remarks field on the web-page. | N |
There will be an ability for System Admin to file parent approval documents to the system. Regularly, the parent will mail the signed approval form for his/her student to the System Admin by mail. The System Admin can scan that document (manually, not in this application) and attach scanned document to the application. That document will be accessible for the System Admin later and can be found by the System Admin through the Student's or Parent's account. Please note, we can re-use Liferay User Profile – It provides the profile functionality. It needs to be customized to support attaching of parent approval forms in our application. Reference to initial use case in conceptualization: “4.4.39”.
| Data Element | Description | Format | R? |
| Student's handle | The unique username (handle) of the Student in the CS-STEM application | String, max 50 chars, non empty | Y |
| Student's e-mail | The e-mail address for the Student | String, max 100 chars, must be a valid e-mail, non empty | Y |
| Parent handle | The unique username (handle) for the parent of the Student in the CS-STEM application | String, max 50 chars, can be empty | N, but at least one entry is required |
| Parent e-mail | The e-mail address for the parent of the Student | String, max 100 chars, must be a valid e-mail if non empty, can be empty | |
| Approval Status | The approval status, assigned to the approval form by the Parent for his/her child Student | String, max 10 chars, non empty, the following values are possible: Permitted, Restricted. |
Y |
| Signed On | The date when the approval form was signed by the parent | String, short date format like MM/DD/YYYY, non empty | Y |
| Sign | The sign of the Parent | Handwriting of the parent sign, non empty | Y |
| Data Element | Description | Format | R? |
| Activity Name | The name of CS-STEM application activity | String, max 50 chars, non empty | Y |
| Activity Status | It will be "Allowed" for all rows on this list if the "Approved" value was set for the parent approval form. Or it will be "Restricted" for all rows on this list if the "Rejected" value was set for the parent approval form | String, max 10 chars, non empty, the following values are possible: Allowed, Restricted. |
Y |
The Student will be initially restricted to perform activities on CS-STEM application until getting an approval from his/her parents. The Student's permissions can be also managed later by his/her Parent - like through parental control (please refer chapter 2.10 "Perform Parental Control for Child Student"). Just a few activities (like practicing in TC Arena) will be allowed without the Parent allowance. The application will provide the list of allowed and restricted activities on the Student's profile. Please note, the Permission Model from Liferay portal can be re-used to support user's restrictions. The student’s activities will also be restricted in various portlets. The Liferay User Profile can be re-used and customized to view the Student's permissions on his/her profile. This use case is included by the use case 2.7 "Get Approved by Parent". Reference to initial use case in conceptualization: “4.4.56”.
The application will allow the Student to perform an authorization request to his/her parents. The Student will ask his/her parents to approve his/her access to the CS-STEM application activities. That request will be performed through this application. The application will send the notification e-mail to the parent with his/her student request. The parent will be asked to authorize his/her child student on the application. This use case includes use case 2.8 "Get Authorization Request from Child Student". The Liferay User Profile can be re-used and customized to allow students to enter their parent contacts data and ask the application to send parent authorization request. This use case also includes “Send E-mail Notifications” use case 2.14. Reference to initial use case in conceptualization: “4.4.57”.
| Data Element | Description | Format | R? |
| 1st Parent Username | The unique username (handle) for the first parent (i.e. Dad) of the Student in the CS-STEM application | String, max 50 chars, can be empty | N, but at least one entry is required |
| 1st Parent E-mail address | The e-mail address for the first parent (i.e. Dad) of the Student | String, max 100 chars, must be a valid e-mail if non empty, can be empty | |
| 2nd Parent Username | The unique username (handle) for the second parent (i.e. Mom) of the Student in the CS-STEM application | String, max 50 chars, can be empty | |
| 2nd Parent E-mail address | The e-mail address for the second parent (i.e. Mom) of the Student | String, max 100 chars, must be a valid e-mail if non empty, can be empty |
There will be a possibility for the Student to get approved by his/her Parent to get access to CS-STEM application activities. The Student will get the notification e-mail from the application when get approved (or denied) by his/her Parent. After approval the Student will get CONTROLLED access to the application (please refer chapter 2.10 "Perform Parental Control for Child Student"). This use case is included by use case 2.3 "Process Parent Approvals for Child Students". This use case includes “Send E-mail Notifications” use case 2.14. Please note, this use case includes the use case 2.5 "Get Restricted to Activities Participation". The Permission Model from Liferay portal can be re-used to support user's restrictions. The student’s activities will also be restricted in various portlets. The Liferay User Profile can be re-used and customized to view the Student's permissions on his/her profile. Reference to initial use case in conceptualization: “4.4.58”.
| Data Element | Description | Format | R? |
| Activity Name | The name of CS-STEM application activity | String, max 50 chars, non empty | Y |
| Activity Status | It will be "Allowed" for all rows on this list if the "Approved" value was set for the parent approval form. Or it will be "Restricted" for all rows on this list if the "Rejected" value was set for the parent approval form | String, max 10 chars, non empty, the following values are possible: Allowed, Restricted. |
Y |
The application will deliver the authorization request to the Parent from his/her child students. The Parent will
be informed that their children are going to participate in CS-STEM application activities. The authorization
request will be sent to the Parent by e-mail from the CS-STEM application and the Parent can follow the
hyperlink in that e-mail to download the approval form for further manual filling and signing. This use case is
included by use case 2.6 "Request Parent Authorization". This use case includes “Send E-mail Notifications” use
case 2.14.
Reference to initial use case in conceptualization: “4.4.60”.
| Data Element | Description | Format | R? |
| Student's handle | The unique username (handle) of the Student in the CS-STEM application | String, max 50 chars, non empty | Y |
| Student's e-mail | The e-mail address for the Student | String, max 100 chars, must be a valid e-mail, non empty | Y |
| Parent handle | The unique username (handle) for the parent of the Student in the CS-STEM application | String, max 50 chars, can be empty | N, but at least one entry is required |
| Parent e-mail | The e-mail address for the parent of the Student | String, max 100 chars, must be a valid e-mail if non empty, can be empty | |
| Approval Status | The approval status, to be assigned to the approval form by the Parent for his/her child Student | Empty string, the Parent has to manually write the following data to that field: String, max 10
chars, non empty, the following values are possible: Permitted, Restricted. |
Y |
| Signed On | The date when the approval form was signed by the Parent | Empty string, the Parent has to manually write the following data to that field: String, short date format like MM/DD/YYYY, non empty | Y |
| Sign | The sign of the Parent | Empty field, the Parent has to manually write the following data to that field: Handwriting of the parent sign, non empty | Y |
| Data Element | Description | Format | R? |
| Activity Name | The name of CS-STEM application activity | String, max 50 chars, non empty | Y |
| Data Element | Description | Format | R? |
| Signed On | The date when the approval form was signed by the parent | String, short date format like MM/DD/YYYY, non empty | Y |
| Sign | The sign of the Parent | Handwriting of the parent sign, non empty | Y |
It will be possible that the Parent can be SOMETIMES verified by the System Admin. It is needed to be fully sure
that the approval form was actually sent by the Parent of the related Student. Verification will be manual and
outside the application, but the verification results will be available in the application on the verified
parent's profile. It will be like "approved" or "rejected" mark. If the parent was rejected (i.e. some cheating
was found), then his/her profile will be disabled together with his/her child students. They can not access
CS-STEM application anymore. This use case includes “Send E-mail Notifications” use case 2.14. Please note, the
Liferay User Profile can be re-used and customized to set approved/rejected statuses to the Parent profiles and
to disable profiles of cheating parents and/or students).
Reference to initial use case in
conceptualization: “4.4.62”.
| Data Element | Description | Format | R? |
| Approval Status | The approval status, assigned to the Parent by the System Admin | String, max 8 chars, non empty, it will have the following value for the approved Parent: Approved. It will be set through single item selection list and, therefore, no validation is needed. | Y |
| Approved On | The date when the Parent approval was performed by the System Admin | String, short date format like MM/DD/YYYY, non empty. It will be set through the date picker control and, therefore, no validation is needed. | Y |
| Data Element | Description | Format | R? |
| Approval Status | The approval status, assigned to the Parent by the System Admin | String, max 8 chars, non empty, it will have the following value for the rejected Parent: Rejected. It will be set through single item selection list and, therefore, no validation is needed. | Y |
| Reason | The reason why the Parent was rejected | String, max 200 chars, can be empty | N |
| Rejected On | The date when the Parent approval actions were performed by the System Admin | String, short date format like MM/DD/YYYY, non empty. It will be set through the date picker control and, therefore, no validation is needed. | Y |
The application will allow Parents to perform parental control of his/her child students’ activity on the CS-STEM
application. There will be a web-page with the list of all the possible features of the CS-STEM application and
the Parent can mark any of them as approved or denied for his/her child Student. The Parent can apply changes to
the application and the child Student permissions will be accordingly turned on or off, and the changes to the
student's permissions become effective within CS-STEM application. The Liferay User Profile can be re-used and
customized for proper managing of the child student's permissions on the profile of that Student. The Liferay
Permissions Model can be re-used and customized to properly support various permissions for the students. This
use case includes “Send E-mail Notifications” use case 2.14.
Reference to initial use case in
conceptualization: “4.4.63”.
| Data Element | Description | Format | R? |
| Activity Name | The name of CS-STEM application activity | String, max 50 chars, non empty | Y |
| Activity Status | The status of the activity permission (i.e. allowed or restricted) | String, max 10 chars, non empty, the following values are possible: Allowed, Restricted. |
Y |
| Activity Type | The type of each individual activity | String, max 50 chars, non empty | Y |
| Content Track | The track of the each individual activity (like Robotics, Health, Ecology, Economics, etc.) | String, max 50 chars, non empty | Y |
| Grade/curriculum type | The grade or the curriculum for the activity | Positive integer from 6 to 12, non empty. | Y |
| Messaging by type | The type of the messaging for the Student | Boolean values: Facebook yes/no, Twitter yes/no, private contact yes/no, etc | Y |
| <Flexible Data> | This feature needs to be flexible and pluggable (i.e. if new features are added to CS-STEM application, then an ability to permit/deny them have to arrive on the Parental Control web-page | Flexible String value, like max 50 chars, can be empty | N |
The Parent will be possible to share all the activities with his/her child Student within CS-STEM application. The Parent can get access to all places, where his/her child Student can go in CS-STEM application and view is happening there. The Parent can mark some content on CS-STEM application to be recommended for his/her child student (like displayed on that student's profile). The achievements of students will be e-mail to their parents by the application. This use case includes “Send E-mail Notifications” use case 2.14. Please note, the Liferay Permissions Model can be re-used and customized to properly allow the Parent and his/her child Students to get access to the same activities. The Liferay User Profile can be re-used and customized to show Parent's recommendations and comments on the child Student's profile. Reference to initial use case in conceptualization: “4.4.64”.
| Data Element | Description | Format | R? |
| <Username> | The unique username (handle) of the Parent, recommended that content | String, max 50 chars, non empty. | Y |
| <Date/TimePosting> | The date/time stamp when the recommendation was posted by the Parent | String, full Date/Time format – like "MM/DD/YYYY hh:mm:ss AM/PM"; non empty. | Y |
| <Hyperlink> | The hyperlink to the recommended content | String, max 1024 chars, non empty, must be a valid URL. | Y |
| <Name> | The name of the recommended content | String, max 100 chars, non empty. |
The application will audit all create/edit and removal actions from the users. The audit data will be persisted
and can be used for the further maintenance of the application. There is Audit Service in the Liferay portlet.
It will be used for performing actual auditing. This use case is included by most of other use cases.
Reference to initial use case in conceptualization: “4.4.32”.
The system will automatically log all the errors, exceptions, warnings and debug information during the
application execution. There is a logging utility in the Liferay portal, so it will be re-used for this use
case. This use case is included by most of other use cases.
Reference to initial use case in
conceptualization: “4.4.33”.
The system will automatically send various e-mail notifications to various users in several events during the
application execution. This specification covers all the notifications on student and parent registration-related
functionality. The user can turn on/off receiving notification e-mails and the System Admin can configure format of
notification e-mails, but it is out of scope for this specification. This use case is included by most of other use
cases.
Reference to initial use case in conceptualization: “4.4.35”.
| Data Element | Description | Format | R? |
| <Signed On> | The date when the approval form was signed by the parent | String, short date format like MM/DD/YYYY, non empty. | Y |
|
|
The unique username (handle) of the Parent, filled the approval form | String, max 50 chars, non empty. | N |
| <Parent E-mail> | The e-mail address of the Parent, filled the approval form | String, max 100 chars, non empty, must be a valid e-mail | Y |
| <Remarks> | The remarks text data for the parent approval status | String, max 200 chars, can be empty. | N |
| Data Element | Description | Format | R? |
| 1st Parent E-mail address | The e-mail address for the first parent (i.e. Dad) of the Student | String, max 100 chars, must be a valid e-mail if non empty, can be empty | N, but at least one entry is required |
| 2nd Parent E-mail address | The e-mail address for the second parent (i.e. Mom) of the Student | String, max 100 chars, must be a valid e-mail if non empty, can be empty |
| Data Element | Description | Format | R? |
| <ActivityName> | The name of CS-STEM application activity | String, max 50 chars, non empty | Y |
| <ActivityType> | The type of each individual activity | String, max 50 chars, non empty | Y |
| <ContentTrack> | The track of the each individual activity (like Robotics, Health, Ecology, Economics, etc.) | String, max 50 chars, non empty | Y |
| <ParentalControlHyperlink> | The hyperlink to parental control web-page in the CS-STEM application (please refer chapter 2.10) | String, max 1024 chars, non empty, must be a valid URL | Y |
| Data Element | Description | Format | R? |
| <StudentHandle> | is the username/handle of the child student | String, max 50 chars, non empty | Y |
| <Title> | The title of the achievement/award | String, max 50 chars, non empty | Y |
| <Description> | The description of the achievement/award | String, max 200 chars, non empty. | Y |
| <Date> | The date when the child student got the achievement/award | String, short date format like MM/DD/YYYY, non empty | Y |
| <ProfileHyperlink> | The hyperlink to child Student’s profile web-page on the CS-STEM application | String, max 1024 chars, non empty, must be a valid URL | Y |
The new application will be specially designed for students of 13…18 years old. GUI, problems, education content, communication will be adopted for the middle-high school students. GUI has to be attractive, user friendly and fun. It will contain more graphics than previous TC web-site. In Liferay Portal (re-used by this application), the user interface is built with JSP pages.
There are no storyboards/wireframes specially designed for this specification (i.e. for teacher and student-related functionality), but the following old storyboards can be re-used as an example of the navigation and menus on the web-site: http://www.topcoder.com/wiki/display/docs/CS-Stem+Student+and+Parent+Registration+Specification
The wireframes will be built after this specification contest will be done. Those wireframes will be based on the specification details. And it will be iterative approach - once the wireframes are completed, they will be presented to potential users and other stakeholders and determine what screens, features, controls, permissions (etc.) need to be modified, added, or deleted.
The application has to support 1024x768 minimal resolution.
Because the application will in the future support iOS, it must avoid Flash technology.
All security checks will occur against permissions. Each function in the system will validate a user’s permission against the required permission for the task. Non-registered users will have read-only access to the application (like viewing forums and public blogs). The permission model from Liferay Portal will be reused in our application. The account model from Liferay portal will be reused in our application (not in scope for this specification). The blog/wiki/forum models from the corresponding portlets in Liferay Portal will be reused to address the requirements from our application.
The authentication and authorization is already implemented in the Liferay portal through the JAAS (refer to the installation guide here). The authorization details are defined in the permission model.
| Non-registered User | System Admin | Student | Parent | System | |
| Register to Application | X | ||||
| Unregister from Application | X | X | X | ||
| Process Parent Approvals for Child Students | X | ||||
| File Parent Approval Documents | X | ||||
| Get Restricted to Activities Participation | X | ||||
| Request Parent Authorization | X | ||||
| Get Approved by Parent | X | ||||
| Get Authorization Request from Child Student | X | ||||
| Get Approved as Parent | X | ||||
| Perform Parental Control for Child Student | X | ||||
| Share Child Student Activities | X | ||||
| Perform Auditing | X | ||||
| Perform Logging | X | ||||
| Send E-mail Notifications | X |
Users with the System Admin role can process student approvals from their parents.
For security reasons passwords must meet a minimum criteria. To be consistent with standards the following rules for passwords have been defined.
No password expiration is required.
Passwords stored in the data store must be encrypted (like stored as hashed in the database). This will prevent unauthorized users from viewing the passwords.
Users frequently forget their passwords. A user can enter their username and have password resetting e-mail sent to them.
None at this time.
None at this time.
| Definition | Description |
| Non-registered User | This is a user, which did not register to the application. He/she will have an ability to register to the application (like to register as a Student, or as a Parent) |
| Registered User | This is an abstract user role, which described additional allowed features for the users after they register to the application - like an ability to unregister from the application |
| Student | A student participating in CS-STEM activities. He/she will register to the application, request approval from his/her parent and get approved (or denied) by his/her parent for participation in CS-STEM application activities. |
| Parent | The parent of the Student. He/she will register to the application and approve/deny his/her students to participate in CS-STEM application activities, perform parental control and share activities with his/her children |
| System Admin | The manager in the CS-STEM application. He/she will process student approvals from their parents |
| Definition | Description |
| CAPTCHA | Completely Automated Public Turing test to tell Computers and Humans Apart |
| CMS | Content Management System |
| CS | Computer Science |
| DARPA | Defense Advanced Research Projects Agency |
| DOC | MS Word Document format |
| GIF | Graphics Interchange Format, a format of graphic files |
| GUI | Graphical User Interface |
| HTML | HyperText Markup Language |
| JAAS | Java Authentication and Authorization Service |
| JPEG | Joint Photographic Experts Group, a format of graphic files |
| NSA | National Security Agency |
| Adobe Portable Document Format | |
| PNG | Portable network graphics, a format of graphic files |
| RSS | Really Simple Syndication |
| SSO | Single Sign-On |
| STEM | Science, Technology, Engineering, Math |
| TC | TopCoder |
| URL | Uniform Resource Locator |
| XLS | MS Excel Document format |
| ZIP | Postal code |
The folHighing types of testing will be performed by TopCoder for quality assurance on the application.
| Test Type | Definition |
| Unit Test | Unit tests are built by developers during coding to ensure that an individual module meets its requirements. |
| Integration Test | Tests the application from a system functionality standpoint, including inputs and outputs, according to the business and design specifications. |
| Functional Test | Test the application correctly implements all logical requirements identified during specification. |
| GUI Test | Verifies GUI features and elements. |
| Regression Test | Verifies that changes to the application are correct and have not (re)introduced errors to other areas of the application. |
| Performance Test | Tests the application in a production setting for normal and worst-case situations against performance requirements identified during specification and architecture. |
| Acceptance Test | Verifies that the application meets the initial objectives and users’ expectations. |
Quality assurance provides a means for mitigating and assessing risks associated with release of software at any point in time. Quality assurance does not provide a 100% guarantee of zero defects.
The list of limitations is as folHighing:
Gateways provide a means for ensuring the application is at a mature enough state from a QA perspective to begin work on the next phase of the application lifecycle. All tasks listed in the gateway will be complete before moving to the next phase. If changes occur to a deliverable from a previous phase then the application should “re-pass” the gateway.
Test scenarios are used to probe the application in a specific area. All test scenarios created should have the folHighing information identified:
Test Scenario Number – Used to reference that scenario.
Test Description – Brief
description of purpose.
Test Type – Identifies the type of testing this scenario is part of.
Project
Phase – When the test should be carried out, what phase of the project.
Pre-Condition – Describe any
pre-conditions that must be met before carrying out the test.
Tools – Enumerate any tools to be used carry
out the test.
Detailed Steps – Describes each step necessary to complete test at a reasonable level of
detail.
Expected Results – Describes the success criteria.
Software Version – Defines version of
application being tested.
Test run – If test is run multiple times identifies an individual test run.
Actual Result – Filled out during testing to describe the result.
Outcome – Pass or Fail. In the case of
Fail tester should add any additional available information.
Test scenarios will be completed prior to the completion of architecture and stored in a separate document. Prior to certification detailed testing steps will be added to the test scenarios.
Unit tests are developed to provide functional coverage of all modules and built in to the developed code. Integration, Functional, GUI, and Performance tests are implemented using test scenarios. Each requirement will map to one or more test scenarios. Regression testing and acceptance testing activities are described in the appendixes of this document.
TopCoder utilizes a component based development methodology that results in a high amount of code reuse. All components built for TopCoder by its members use unit testing frameworks that include unit, accuracy, performance, and error testing at the component level. These tests form the basis of the unit testing that will be used to test the application. Additional unit tests will be constructed to test the application level code. All unit tests must pass successfully.
Any defect that is traced to a specific piece of software will result in that software being fixed and a new unit test being created to ensure that defect does not get reintroduced.
Test scenarios will be developed that identify the integration points of the application and ensure the application as a whole behaves properly based on the states of its dependant modules. Integration testing ensures that independently developed aspects of the system work together properly.
Appendix A includes a mapping of various requirements to integration test scenarios.
In order to ensure application tests accurately cover all requirements of the application it is first necessary to ensure that all requirements are stated in a testable manner. Any requirement that is not testable must be restated. For example, a requirement that the application have “good performance” would be restated as “all pages in application load under 1.5 seconds.”
Appendix A includes a mapping of logical requirements to functional test scenarios.
The user interface will be tested to ensure conformity with the prototype developed and approved during the Specification phase. Additionally, technical GUI requirements such as browser support, color palette, and screen resolution will be tested.
Appendix A includes a mapping of GUI requirements to GUI test scenarios.
Regression testing at the application level is enabled by the detailed set of test cases developed for integration, functional, GUI, and performance testing. When a change is introduced to the system, these test cases can be used in whole or in part to re-test the entire application or part of the application. The more automation that is provided in the test cases, the less effort that will be required to perform regression testing.
Smoke tests will be created for the test cases with priority level of “high” and will be executed after every change to quickly ensure major functionality. Smoke tests will also be executed after every build of the application.
Appendix B includes a description of the actors and activities associated with regression testing for this application.
Although performance testing is an integral part of the component development process, it is important that the performance of the system as a whole is tested. Performance requirements are included in Appendix A. Appropriate tools will be used to measure the performance for each test case.
Appendix A includes mappings of performance requirements to performance test scenarios.
Appendix C includes a description of the actors and activities associated with acceptance testing for this application.
As determined by client’s specifications.
Please refer to the Preference_Center_Admin_Test_Scenario_Inventory.xls which contains an itemized list of the various Integration, Functional, GUI, and Performance Test Cases to be performed
| Test Case Number | Corresponding Application Requirement ID | Description of Test Case | Priority |
| Integration Testing | |||
| 1 | Generic | Verify that the application gets integrated with Database (MySQL 5.1) | High |
| 2 | Generic | Verify that the application gets integrated with Web Server (Jboss 5.1) and Application Server | High |
| 3 | Generic | Verify that the application gets integrated with Email Server | High |
| 4 | Generic | Verify that the application gets integrated with Liferay 6.0.5 | High |
| Test Case Number | Corresponding Application Requirement ID | Description of Test Case | Priority |
| Performance Testing | |||
| 1 | 3.2 | Verify maximum expected count of users will be several thousands until the end of the year | High |
| 2 | 3.2 | Verify 500 concurrent students are expected for the application | High |
| 3 | 3.2 | Verify the high availability of the system | High |
| 4 | 3.2 | Verify the high response speed of the application | High |
| Test Case Number | Corresponding Application Requirement ID | Description of Test Case | Priority |
| GUI Testing | |||
| 1 | 3.1.1/3.1.2 | Verify that the application works well in 1024x768 resolution | High |
| 2 | 3.1.1 | Verify the appearance of the application is correct | High |
| Test Case Number | Corresponding Application Requirement ID | Description of Test Case | Priority |
| Functional Testing | |||
| 1 | Generic | Verify user's profile page can be displayed | High |
| 2 | Generic | Verify user's account management page can be displayed | High |
| 3 | Generic | Verify user's email can be modified successfully | High |
| 4 | Generic | Verify form validation on account management page works well (empty email) | High |
| 5 | Generic | Verify form validation on account management page works well (invalid email) | High |
| 6 | Generic | Verify form validation on account management page works well (empty password/confirm password) | High |
| 7 | Generic | Verify form validation on account management page works well (unmatched password and confirm password) | High |
| 8 | Generic | Verify user's password can be modified successfully | High |
| 9 | Generic | Verify user's "My Profile" page can be displayed | High |
| 10 | Generic | Verify user's profile can be updated from "My Profile" page | High |
| 11 | Generic | Verify user's profile will not be updated if pressing "Cancel" | High |
| 12 | Generic | Verify form validation works well on "My Profile" page (Invalid First Name) | High |
| 13 | Generic | Verify form validation works well on "My Profile" page (Invalid Last Name) | High |
| 14 | Generic | Verify form validation works well on "My Profile" page (Invalid City) | High |
| 15 | Generic | Verify form validation works well on "My Profile" page (Invalid ZIP) | High |
| 16 | Generic | Verify form validation works well on "My Profile" page (Invalid Date of Birth) | High |
| 17 | 2.1.1.1/ 2.1.1.2/ 2.1.1.3/ 2.1.1.4/ 2.1.1.6 | Verify valid credentials can successfully register to the application | High |
| 18 | 2.1.1.1 | Verify the password is masked with asterisk | High |
| 19 | 2.1.1.1 | Verify all the values in "Role" dropdown list are displayed | High |
| 20 | 2.1.1.1 | Verify CAPTCHA is displayed with 6 chars | High |
| 21 | 2.1.1.1 | Verify CAPTCHA is randomly generated | High |
| 22 | 2.1.1.1 | Verify all the values in "Gender" dropdown list are displayed | High |
| 23 | 2.1.1.2 | Verify "Terms & Conditions" can be clicked in the registration form | High |
| 24 | 2.1.1.2 | Verify "Terms & Conditions" can be clicked in the homepage footer | High |
| 25 | 2.1.1.1/ 2.1.1.2/ 2.1.1.4/ 2.1.1.5 | Verify registration form validation works well (invalid handle) | High |
| 26 | 2.1.1.1/ 2.1.1.2/ 2.1.1.4/ 2.1.1.5 | Verify registration form validation works well (last name of handle non selected) | High |
| 27 | 2.1.1.1/ 2.1.1.2/ 2.1.1.4/ 2.1.1.5 | Verify registration form validation works well (invalid password) | High |
| 28 | 2.1.1.1/ 2.1.1.2/ 2.1.1.4/ 2.1.1.5 | Verify registration form validation works well (invalid email) | High |
| 29 | 2.1.1.1/ 2.1.1.2/ 2.1.1.4/ 2.1.1.5 | Verify registration form validation works well (user role not selected) | High |
| 30 | 2.1.1.1/ 2.1.1.2/ 2.1.1.3/ 2.1.1.4/ 2.1.1.5 | Verify registration form validation works well (Terms & Conditions checkbox not checked) | High |
| 31 | 2.1.1.1/ 2.1.1.2/ 2.1.1.3/ 2.1.1.4/ 2.1.1.5 | Verify email is mandatory to register a new account | High |
| 32 | 2.1.1.1/ 2.1.1.2/ 2.1.1.3/ 2.1.1.4/ 2.1.1.6/ 2.1.1.7/ 2.1.1.8/ 2.1.1.9 | Verify valid credentials can successfully create a new account | High |
| 33 | 2.1.1.1/ 2.1.1.2/ 2.1.1.3/ 2.1.1.4/ 2.1.1.6/ 2.1.1.7/ 2.1.1.8/ 2.1.1.9/ 2.1.1.10 | Verify new account is non approved when registered | High |
| 34 | 2.1.1.1/ 2.1.1.2/ 2.1.1.3/ 2.1.1.4/ 2.1.1.6/ 2.1.1.7/ 2.1.1.8/ 2.1.1.9/ 2.1.1.12/ 2.1.1.13 | Verify new account is automatically logged into the application and welcome message is displayed | High |
| 35 | 2.1.1.1/ 2.1.1.2/ 2.1.1.3/ 2.1.1.4/ 2.1.1.6/ 2.1.1.7/ 2.1.1.8/ 2.1.1.9/ 2.1.1.12/ 2.1.1.13/ 2.1.1.14 | Verify new account user can receive the account creation success email | High |
| 36 | 2.1.1.1/ 2.1.1.2/ 2.1.1.3/ 2.1.1.4/ 2.1.1.6/ 2.1.1.7/ 2.1.1.8/ 2.1.1.9/ 2.1.1.12/ 2.1.1.13/ 2.1.1.14 | Verify system will not send out the account creation success email if user's email address is not provided | High |
| 37 | 2.2.1.1/ 2.2.1.2/ 2.2.1.4/ 2.2.1.5/ 2.2.1.7/ 2.2.1.8/ 2.2.1.9/ 2.2.1.11/ 2.2.1.14/ 2.2.1.15 | Verify parent user can successfully unregister from the application | High |
| 38 | 2.2.1.1/ 2.2.1.2/ 2.2.1.3 | Verify student will not be unregistered from the application if answering "No" | High |
| 39 | 2.2.1.1/ 2.2.1.2/ 2.2.1.3/ 2.2.1.4 | Verify un-registration survey will be shown to authorized user | High |
| 40 | 2.2.1.1/ 2.2.1.2/ 2.2.1.3/ 2.2.1.4 | Verify un-registration survey will not be submitted if pressing "Cancel" | High |
| 41 | 2.2.1.1/ 2.2.1.2/ 2.2.1.3/ 2.2.1.4/ 2.2.1.5/ 2.2.1.6 | Verify validation for un-registration survey works well (radio buttons) | High |
| 42 | 2.2.1.1/ 2.2.1.2/ 2.2.1.3/ 2.2.1.4/ 2.2.1.5/ 2.2.1.6 | Verify validation for un-registration survey works well (text field) | High |
| 43 | 2.2.1.1/ 2.2.1.2/ 2.2.1.3/ 2.2.1.4 | Verify un-registration survey will not be shown to unauthorized user | High |
| 44 | 2.2.1.1/ 2.2.1.2/ 2.2.1.4/ 2.2.1.7/ 2.2.1.8/ 2.2.1.9/ 2.2.1.10 | Verify parent will be informed on file about child student's unregistration | High |
| 45 | 2.2.1.1/ 2.2.1.2/ 2.2.1.4/ 2.2.1.7/ 2.2.1.8/ 2.2.1.9/ 2.2.1.10/ 2.2.1.11 | Verify parent will receive e-mail notifications about child student's unregistration | High |
| 46 | 2.2.1.12 | Verify parent's unregistration will lead to student's unauthorization | High |
| 47 | 2.2.1.12/ 2.2.1.13 | Verify student gets notified on parent's unregistration | High |
| 48 | 2.2.1.1 | Verify there will be a special button on the user's unregistered profile | High |
| 49 | 2.2.1.1 | Verify there will be a hyperlink in the email after the user is unregistered | High |
| 50 | 2.2.1.1 | Verify answer 1 is required to fill for unregistering the profile | High |
| 53 | 2.2.2.1/ 2.2.2.2/ 2.2.2.5/ 2.2.2.6/ 2.2.2.7 | Verify parent can re-register account successfully | High |
| 54 | 2.2.2.1/ 2.2.2.2/ 2.2.2.3/ 2.2.2.4 | Verify it is possible for student to re-register account unsuccessfully | High |
| 55 | 2.3.1.1/ 2.3.1.2/ 2.3.1.3/ 2.3.1.4/ 2.3.1.5/ 2.3.1.6 | Verify parent gets notified on process results of approval form (Approved status) | High |
| 56 | 2.3.1.1/ 2.3.1.2/ 2.3.1.3/ 2.3.1.4/ 2.3.1.5/ 2.3.1.6 | Verify parent gets notified on process results of approval form (Rejected status) | High |
| 57 | 2.5.1.1 | Verify unauthorized student gets restricted to most activities | High |
| 58 | 2.5.1.2 | Verify authorized student gets access to most activities | High |
| 59 | 2.5.1.3 | Verify student access to activities is controlled by parents | High |
| 60 | 2.5.1.4 | Verify student's permissions on the profile can be viewed by the student | High |
| 61 | 2.7.1.1 | Verify student's profile can be viewed by system admin after request for authorization | High |
| 62 | 2.7.1.2 | Verify system will resend the request to parent user if the request is not handled within a period of time | High |
| 63 | 2.7.1.3 | Verify student can receive approval mail on the authorization | High |
| 64 | 2.7.1.3 | Verify student can receive rejection mail on the authorization | High |
| 65 | 2.7.1.3/ 2.7.1.4 | Verify Student's Approval/Rejection Status on the Profile can be viewed | High |
| 66 | 2.7.1.5 | Verify authorized student can also get restricted to activities by parents control | High |
| 67 | 2.8.1.1 | Verify parent user can receive notification e-mail with parent authorization request | High |
| 68 | 2.8.1.1/ 2.8.1.2 | Verify parent user can cancel any parent authorization request | High |
| 69 | 2.8.1.1/ 2.8.1.3 | Verify parent user can download parent approval form for the parent's child student | High |
| 70 | 2.9.1.1/ 2.9.1.2/ 2.9.1.3 | Verify reject reason can not exceed 200 chars | High |
| 71 | 2.9.1.4 | Verify system admin can disable profile of cheating parent | High |
| 72 | 2.9.1.5 | Verify system admin can disable profiles of cheating child Students for the cheating Parent | High |
| 73 | 2.8.1.1/ 2.8.1.3/ 2.8.1.4/ 2.8.1.5/ 2.8.1.6 | Verify parent user can download parent approval form, sign and mail it to system admin | High |
| 74 | 2.9.1.1/ 2.9.1.2/ 2.9.1.6/ 2.9.1.7 | Verify parent user can get approved by system admin | High |
| 75 | 2.9.1.1/ 2.9.1.3/ 2.9.1.4/ 2.9.1.5/ 2.9.1.7 | Verify parent user can get rejected by system admin | High |
| 76 | 2.9.1.1/ 2.9.1.3/ 2.9.1.4/ 2.9.1.5/ 2.9.1.7 | Verify student user gets notified if parent user's approval form gets rejected by system admin | High |
| 77 | 2.10.1.1 | Verify list of student's permissions on his/her Profile can be viewed by parent (Activities data) | High |
| 78 | 2.10.1.1 | Verify list of student's permissions on his/her Profile can be viewed by parent (Forums data) | High |
| 79 | 2.10.1.1 | Verify list of student's permissions on his/her Profile can be viewed by parent (Blog data) | High |
| 80 | 2.10.1.1 | Verify list of student's permissions on his/her Profile can be viewed by parent (Private Messages data) | High |
| 81 | 2.10.1.1 | Verify pagination works well on the list of student's permissions on his/her Profile (Activities Data) | High |
| 82 | 2.10.1.1 | Verify pagination works well on the list of student's permissions on his/her Profile (Forums Data) | High |
| 83 | 2.10.1.1 | Verify pagination works well on the list of student's permissions on his/her Profile (Blog Data) | High |
| 84 | 2.10.1.1 | Verify pagination works well on the list of student's permissions on his/her Profile (Private Messages Data) | High |
| 85 | 2.10.1.1/ 2.10.1.2 | Verify filter works well on the list of student's permissions on his/her Profile (Activity Type) | High |
| 86 | 2.10.1.1/ 2.10.1.2 | Verify filter works well on the list of student's permissions on his/her Profile (Content Track) | High |
| 87 | 2.10.1.1/ 2.10.1.2 | Verify filter works well on the list of student's permissions on his/her Profile (Grade/curriculum type) | High |
| 88 | 2.10.1.1/ 2.10.1.2 | Verify filter works well on the list of student's permissions on his/her Profile (Facebook) | High |
| 89 | 2.10.1.1/ 2.10.1.2 | Verify filter works well on the list of student's permissions on his/her Profile (Twitter) | High |
| 90 | 2.10.1.1/ 2.10.1.2 | Verify multiple filters work well on the list of student's permissions on his/her Profile (Content Track and Activity Type) | High |
| 91 | 2.10.1.1/ 2.10.1.2 | Verify multiple filters work well on the list of student's permissions on his/her Profile (Content Track and Twitter) | High |
| 92 | 2.10.1.1/ 2.10.1.2 | Verify multiple filters work well on the list of student's permissions on his/her Profile (Grade/curriculum and Facebook) | High |
| 93 | 2.10.1.1/ 2.10.1.3 | Verify notification e-mail on new activity can be sent to parents | High |
| 94 | 2.10.1.1/ 2.10.1.4/ 2.10.1.6/ 2.10.1.7 | Verify activities can be marked as allowed for students by parent | High |
| 95 | 2.10.1.1/ 2.10.1.4/ 2.10.1.6/ 2.10.1.7 | Verify activities can be marked as restricted for students by parent | High |
| 96 | 2.10.1.1/ 2.10.1.4/ 2.10.1.5/ 2.10.1.7 | Verify permission for activities can be cancelled by parent | High |
| 97 | 2.11.1.1 | Verify great results notification e-mail can be sent to parent when student gets an award | High |
| 98 | 2.11.1.1 | Verify great results notification e-mail can be sent to parent when student finishes some tracks | High |
| 99 | 2.11.1.2 | Verify parent can get access to child student's activities (read-only access to ALL places) | High |
| 100 | 2.11.1.2 | Verify parent can get access to child student's activities (write access to some activities) | High |
| 101 | 2.11.1.2 | Verify parent can get access to child student's activities (unable to join in activity) | High |
| 102 | 2.11.1.3 | Verify parent can recommend some content to child student | High |
| 103 | 2.11.1.4 | Verify parent can comment content to child student | High |
| 104 | 2.12.1.1 | Verify perform auditing works well (Register to the application) | High |
| 105 | 2.12.1.1 | Verify perform auditing works well (Automatic login of registered user) | High |
| 106 | 2.12.1.1 | Verify perform auditing works well (Unregister from the application) | High |
| 107 | 2.12.1.1 | Verify perform auditing works well (Submitting an un-registration survey) | High |
| 108 | 2.12.1.1 | Verify perform auditing works well (Automatic logout of the unregistered user) | High |
| 109 | 2.12.1.1 | Verify perform auditing works well (Reverting child student to non-authorized state after his/her Parent was unregistered) | High |
| 110 | 2.12.1.1 | Verify perform auditing works well (Process parent approval form) | High |
| 111 | 2.12.1.1 | Verify perform auditing works well (Entering System Admin remarks for parent approval status) | High |
| 112 | 2.12.1.1 | Verify perform auditing works well (Request parent authorization) | High |
| 113 | 2.12.1.1 | Verify perform auditing works well (Resending of the parent authorization request) | High |
| 114 | 2.12.1.1 | Verify perform auditing works well (Get approved by parent) | High |
| 115 | 2.12.1.1 | Verify perform auditing works well (Perform parental control for child students) | High |
| 116 | 2.12.1.1 | Verify perform auditing works well (Parent performs writing of data in shared activities with his/her child) | High |
| 117 | 2.12.1.1 | Verify perform auditing works well (Recommend content for child students) | High |
| 118 | 2.12.1.1 | Verify perform auditing works well ( Perform commenting for child students) | High |
| 119 | 2.13.1.1 | Verify perform logging works well | High |
| 119 | 2.14.1.1 | Verify sending e-mail notifications works well (Send Account Activation E-mail) | High |
| 120 | 2.14.1.2 | Verify sending e-mail notifications works well (Send Account Creation Success E-mail) | High |
| 121 | 2.14.1.3 | Verify sending e-mail notifications works well (Send Success E-mail on Child Student Un-registration to Parent) | High |
| 122 | 2.14.1.4 | Verify sending e-mail notifications works well (Send Success E-mail on Parent Un-registration to Child Student) | High |
| 123 | 2.14.1.5 | Verify sending e-mail notifications works well (Send Account Un-registration Success E-mail) | High |
| 124 | 2.14.1.9 | Verify sending e-mail notifications works well (Send Parent Approval Status Notification E-mail) | High |
| 125 | 2.14.1.10 | Verify sending e-mail notifications works well (Send Notification E-mail with Parent Authorization Request) | High |
| 126 | 2.14.1.11 | Verify sending e-mail notifications works well (Send Notification E-mail on Parent Approval Rejected Results) | High |
| 127 | 2.14.1.12 | Verify sending e-mail notifications works well (Send Notification E-mail on New Activity to Parents) | High |
| 128 | 2.14.1.13 | Verify sending e-mail notifications works well (Send Great Results Notification E-mail to the Student's Parent) | High |
;){kind=link}